Similar to a comment I made a few hours ago. I find myself expressing a concern that something has been lost when people never interact with something directly.<p>Most of the discussion today is about AI and how that causes this issue, but I have been though this experience a few times now.<p>This instruction is essentially incomprehensible at a glance and requires a mental translation step to fillow. That doesn't affect it's use in a specific case, and compilers just use the instructions that they are programmed to use, so there isn't anything fundamentally wrong with this instruction or it's name other than the fact that it seems to be a key for a lock.<p>If there were more people programming in asm, there would probably be enough minds interacting with the instructions to desire and have the capacity to design a better representation for the instruction set. I do believe that better designs at levels like that help solidify thinking in neighbouring levels. For instance with instruction representations, a better way to think about how the instruction is specified might reduce the cognitive load on chip designers and compiler writers.<p>This kind of thing happens over and over when people move to new methods, there are artifacts that remain that are still useful in a modern context but only exist because they were designed at a time when the principles that underlying them were much more commonly used.<p>Examples of this are music boxes and regular expressions, You can still find new instances for both, and they are good solutions for some tasks, but if anyone were to design something today to fill the niche of either, they would not come up with anything so enduring.<p>It is easier to understand a music box than a regular expression finite automata, but both are wonders of design.<p>It has occurred to me that this specific problem of ideas and methods left unconsidered may not be such a problem in an age of AI. It mY be that the capacity for AI to consider and link so many things that it will draw together elements from all of those domains to apply techniques that humans no longer focus upon onto issues that are currently relevant.<p>I'm not sure if current AI is up to that particular task. It would be an interesting problem to set it.<p>Design an assembler for a machine with a modern complex instruction set so that programming on assembler is a more mentally tractable task.<p>It would be fascinating to see what such an open task would do to a model.
I'm not sure it's so profound at all. The Intel vector ISA has always been filled with instructions with odd semantics and inscrutable names. They probably made a mistake in some deep corner case in their rounding implementation and had a choice between releasing the new instruction with the wrong semantics and pulling the "chicken bit" making the instruction inaccessible for this generation of CPUs, better luck next time.
You're assuming that the asm syntax is targeted at human readability, when it's at least as much to ease the complexity of the assembler and disassembler.<p>If the FMA instruction syntax was designed for readability, then it would have used 4-argument syntax with a requirement for two registers to match instead of using the 1/2/3 encodings. But the reason why it uses those names instead is that it's more consistent with the instruction encoding and the format of most other vector instructions: the register/memory argument is last.<p>Similarly, x86 vector instructions that take an immediate byte cram a bunch of options into that byte, such as shuffle masks or operation options. The assembly syntax does not help constructing this byte at all. But that's because it's meant to map straightforwardly to the instruction encoding, not to be easy to manually read or write.<p>ARM assembly tends to be a bit more consistent, but has some similar quirks. The majority of ARM instructions are dst,src, but store instructions are reversed as src,dst so they have the memory argument second just like load instructions.
>You're assuming that the asm syntax is targeted at human readability, when it's at least as much to ease the complexity of the assembler and disassembler.<p>I think you misunderstand my meaning. I know why things are like this. I was musing on the consequences of that. When the target moved aware from human readability then it also actively discourages human attention, lessening the chance of innovation. In my own work, I have always thought that maximising the general utility of things is better than targeting a 'use case' so that others might come up with ideas for use that I hadn't considered.<p>A worrying thought is that companies might be motivated to discourage innovation outside of their own control.
My symbolasm project[1] is exactly that: an assembler syntax designed to make programming more mentally tractable. I expect it to help for both human and LLM coders. Apologies for the spare repo, I haven't written good readmes yet.<p>In this syntax (though I'm not yet targeting x86_64) it would look something like a = round(fma(a, b, c)) where the variables have the appropriate vector type (and have been placed into registers with @zmm1 syntax when first assigned).<p>The design of the language is entirely by hand, as was the implementation when I started, but lately I have been using AI to speed implementation.<p>[1] <a href="https://github.com/raphlinus/symbolasm" rel="nofollow">https://github.com/raphlinus/symbolasm</a>
> it would look something like a = round(fma(a, b, c))<p>One problem with that is that it makes it look as if the language is more expressive than it is. You might not be able to write, for example<p><pre><code> d = round(fma(a, b, c))
</code></pre>
because the instruction doing that is a three-register one.<p>Another example, on x64 (IIRC)<p><pre><code> a = a + b + 42
d = d + 4 × e
d = 5 × d // equivalent to d = d + 4 × d
</code></pre>
would be valid (being LEA variants), but<p><pre><code> a = a + b + c
d = d + 5 × e
d = 7 × d
</code></pre>
would not. So, this would be more readable, but I’m not sure it would be easier to write.<p>You can make it easier to write by allowing ‘obvious’ rewrites such as<p><pre><code> a = b + c + d
</code></pre>
into<p><pre><code> a = b + c
a = a + d
</code></pre>
but then, you’re on your way towards a generic programming language, and where do you stop?<p>It also soon doesn’t get obvious, as it might be possible to avoid the data dependency in the rewrite or to do another ‘obvious’ thing, and move the instruction following that <i>a = a + d</i> up between the two instructions.
When I made an AVR assembler, I had a play around with a few ideas.<p>My changes were less to do with instruction representation, and more related to macros and reusable code.<p><a href="https://github.com/Lerc/AvrAsm" rel="nofollow">https://github.com/Lerc/AvrAsm</a><p>One example of some of the bits I added, is the macros at<p><a href="https://gist.github.com/Lerc/ad96329670965dc023c5ae740b433ad6#file-defs-kasm-L202" rel="nofollow">https://gist.github.com/Lerc/ad96329670965dc023c5ae740b433ad...</a><p>This provides a blend of macros and snips to allow<p><pre><code> init:
set_stack_pointer RAMEND
load_let_values
call Someroutine
...
...
...
Someroutine:
letb bits_x,62
letb bits_y,56
lds r16,bits_x
lds r17,bits_y
Etc.
</code></pre>
So the letb macro puts the constant parameter into ROM and assigns a RAM symbol for the variable. The load_let_values macro copies the ROM values into the RAM locations (essentially dropping some of requirements for sections)<p>The load_let_values macro manages to copy values that are defined later in the program.<p>I'm not sure if this is a wise use of this feature, but it was a good tricky task to attempt to implement with it.
Happy to see more people thinking about this, there's really no good reason for ASM syntax to be so dreadfully primitive and inaccessible to this day. Even something as trivially simple as namespacing instructions to indicate CPU extensions would be a welcome improvement.
My question with this is about intent. If asm programming really becomes a lost art for humans. The question then becomes who will impart the intent or mission to LLMS to connect this ideas.<p>Remains me of an interesting article I read a month ago. About how LLMs can be “anti-meme generators” as in Memetics.<p><a href="https://www.jernesto.com/articles/anti_meme_explosion" rel="nofollow">https://www.jernesto.com/articles/anti_meme_explosion</a>
x64 is the opposite of designed. Its entire design is evolution and compromises. It's like an apartment that's been painted every year for the last 40 years. Just layers upon layers and you can occasionally peel it back and see the accumulated thickness.
Is your complaint about the binary encoding or the assembler syntax? You can't possibly give every vector instruction a nice binary encoding and retain backwards compatibility - you can start over with a new instruction set, and if successful it will accrue as much cruft as AMD's one has now.
It is neither a complaint, or about the encoding, nor is it really a matter of syntax. It is a consideration of how things are represented. A different syntax could accommodate different ways to represent things, but that is not a domain exclusive to syntax.<p>I don't think the possibility of something better one-day becoming in need of a replacement itself sufficient reason to not consider how we could make better things.