<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://intellabs.github.io/isa-tools/feed.xml" rel="self" type="application/atom+xml" /><link href="https://intellabs.github.io/isa-tools/" rel="alternate" type="text/html" /><updated>2026-04-17T18:12:02+00:00</updated><id>https://intellabs.github.io/isa-tools/feed.xml</id><title type="html">ISA tools</title><subtitle>A tool for writing clear, precise ISA specifications using the Intel® ISA Specification Language</subtitle><author><name>Intel Labs</name></author><entry><title type="html">Forthcoming language changes</title><link href="https://intellabs.github.io/isa-tools/2025/08/21/language-changes.html" rel="alternate" type="text/html" title="Forthcoming language changes" /><published>2025-08-21T00:00:00+00:00</published><updated>2025-08-21T00:00:00+00:00</updated><id>https://intellabs.github.io/isa-tools/2025/08/21/language-changes</id><content type="html" xml:base="https://intellabs.github.io/isa-tools/2025/08/21/language-changes.html"><![CDATA[<p>Over the last 15 years of work on ISA specifications, my ideas on the ideal ISA
specification language have slowly changed.
I have had a chance to see how language features are used at scale;
how other specification developers use the language;
and which parts of the language people just get and which bits cause confusion.
This has changed how I think about the language and about the priorities
of the language.
Ideas that seemed to work well from the language designer’s or programmer’s perspective
turn out to be confusing from the perspective of somebody reading the specification.
And our expectations about what languages readers are familiar with and that may
color how they read and interpret the specification change.</p>

<p>Working on the (forthcoming) specification of the Intel® Architecture has
provided both fresh insight into the problems of existing specification
languages and also an opportunity to fix some of the issues that we have been
experiencing.</p>

<p>We had been attempting to solve these problems through a number of small extensions
but we were limited in the changes we could make by our increasingly unsuccessful
attempts to preserve consistency with the Arm’s Architecture Specification Language
which was evolving to better meet the needs of the Arm architectures and customers.</p>

<p>We have decided to drop our goal of source-level consistency with Arm’s
Architecture Specification Language and make some more significant changes to
the language.
The new ISA specification language will maintain the same goals as before of
readability, ease of understanding, difficulty of confusion, executability, etc.
but it will have a new grammar, type-system, foreign-function interface, module-system, etc.</p>

<p>Most of the new language design is complete and has been tested at scale (by converting
a large specification to the new language) but we are still fine-tuning a few details
as we build experience with the new language.</p>

<p>The <a href="https://github.com/IntelLabs/isa-tools">ASLi tool</a> will continue to exist but
it will change to support our new ISA specification language and it will
be renamed to <a href="https://github.com/IntelLabs/isa-tools">ISA tools</a>.</p>

<hr />

<p><em>[This post has been updated to point at the new repository – April 2026]</em></p>]]></content><author><name>Intel Labs</name></author><category term="plans" /><summary type="html"><![CDATA[Over the last 15 years of work on ISA specifications, my ideas on the ideal ISA specification language have slowly changed. I have had a chance to see how language features are used at scale; how other specification developers use the language; and which parts of the language people just get and which bits cause confusion. This has changed how I think about the language and about the priorities of the language. Ideas that seemed to work well from the language designer’s or programmer’s perspective turn out to be confusing from the perspective of somebody reading the specification. And our expectations about what languages readers are familiar with and that may color how they read and interpret the specification change.]]></summary></entry></feed>