An old version of binutils [1] explains what DDS means:
How to encode VEX.vvvv:
0: VEX.vvvv must be 1111b.
1: VEX.NDS. Register-only source is encoded in VEX.vvvv where
the content of source registers will be preserved.
VEX.DDS. The second register operand is encoded in VEX.vvvv
where the content of first source register will be overwritten
by the result.
VEX.NDD2. The second destination register operand is encoded in
VEX.vvvv for instructions with 2 destination register operands.
For assembler, there are no difference between VEX.NDS, VEX.DDS
and VEX.NDD2.
2. VEX.NDD. Register destination is encoded in VEX.vvvv for
instructions with 1 destination register operand.
3. VEX.LWP. Register destination is encoded in VEX.vvvv and one
of the operands can access a memory location.
It only existed in SDM volume 2 revisions 082 to 084. It did not appear in #252046, the changes doc -- so its existence in volume 2 was not intentional.
It is not surprising that Intel contemplated a version of 0F,38,B8 at 0F,3A,B8 to get /Ib for rounding. It is surprising that this briefly appeared in the SDM many years after the AVX512 had settled with SKX and CNL.
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.
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.
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.
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.
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.
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.
It is easier to understand a music box than a regular expression finite automata, but both are wonders of design.
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.
I'm not sure if current AI is up to that particular task. It would be an interesting problem to set it.
Design an assembler for a machine with a modern complex instruction set so that programming on assembler is a more mentally tractable task.
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.
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.
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.
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.
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.
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.
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).
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.
> it would look something like a = round(fma(a, b, c))
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
d = round(fma(a, b, c))
because the instruction doing that is a three-register one.
Another example, on x64 (IIRC)
a = a + b + 42
d = d + 4 × e
d = 5 × d // equivalent to d = d + 4 × d
would be valid (being LEA variants), but
a = a + b + c
d = d + 5 × e
d = 7 × d
would not. So, this would be more readable, but I’m not sure it would be easier to write.
You can make it easier to write by allowing ‘obvious’ rewrites such as
a = b + c + d
into
a = b + c
a = a + d
but then, you’re on your way towards a generic programming language, and where do you stop?
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 a = a + d up between the two instructions.
I don't allow such rewrites, you have to be explicit. If you write something that doesn't have a valid assembler encoding, its rejected at compile time.
It helps that I'm currently targeting ARM (Cortex M33, RP2350 specifically). Old-school x86 would be much less pleasant, as it's got so many arbitrary-seeming rules of what works and what doesn't. One quirk, when optimizing for file size, are the rules for which instructions have 16 bit encodings and which need 32. But again, the plan is to have a tight feedback loop.
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)
The load_let_values macro manages to copy values that are defined later in the program.
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.
Have to be rather careful with such - e.g. an x86 vaddpd or an ARM fadd aren't commutative because of NaN bit patterns (even worse for fma, esp. if you have it automatically choose the operation from which arg it's destructive over).
Perhaps not significant for writing code (though maybe someone does want the NaN bit pattern to be taken from a specific arg!), but is one aspect that can easily go missing in a higher-level assembler (or esp. disassembler).
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.
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.
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.
Remains me of an interesting article I read a month ago. About how LLMs can be “anti-meme generators” as in Memetics.
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.
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.
An old version of binutils [1] explains what DDS means:
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;...[dead]
See https://www.felixcloutier.com/x86/vfmaddrnd231pd
Theory: It was removed due to hardware issue and never worked
It only existed in SDM volume 2 revisions 082 to 084. It did not appear in #252046, the changes doc -- so its existence in volume 2 was not intentional.
It is not surprising that Intel contemplated a version of 0F,38,B8 at 0F,3A,B8 to get /Ib for rounding. It is surprising that this briefly appeared in the SDM many years after the AVX512 had settled with SKX and CNL.
Maybe the sandpile.org guy knows more history?
The instruction was removed when Intel recommitted to AVX-512 on client CPUs (it is available in EVEX form IIRC)
Thanks! Do you have any source for that by any chance? I'd like to update the post.
https://www.phoronix.com/news/Intel-AVX10-Drops-256-Bit
Thanks! I did some more research and updated the post.
Looks like a name for a RISC-V extension
Edit: Checked the article and dang... x86
RISC-V got the absurd names from somewhere.
Fitting username!
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.
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.
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.
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.
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.
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.
It is easier to understand a music box than a regular expression finite automata, but both are wonders of design.
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.
I'm not sure if current AI is up to that particular task. It would be an interesting problem to set it.
Design an assembler for a machine with a modern complex instruction set so that programming on assembler is a more mentally tractable task.
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.
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.
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.
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.
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.
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.
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).
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.
[1] https://github.com/raphlinus/symbolasm
> it would look something like a = round(fma(a, b, c))
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
because the instruction doing that is a three-register one.Another example, on x64 (IIRC)
would be valid (being LEA variants), but would not. So, this would be more readable, but I’m not sure it would be easier to write.You can make it easier to write by allowing ‘obvious’ rewrites such as
into but then, you’re on your way towards a generic programming language, and where do you stop?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 a = a + d up between the two instructions.
I don't allow such rewrites, you have to be explicit. If you write something that doesn't have a valid assembler encoding, its rejected at compile time.
It helps that I'm currently targeting ARM (Cortex M33, RP2350 specifically). Old-school x86 would be much less pleasant, as it's got so many arbitrary-seeming rules of what works and what doesn't. One quirk, when optimizing for file size, are the rules for which instructions have 16 bit encodings and which need 32. But again, the plan is to have a tight feedback loop.
When I made an AVR assembler, I had a play around with a few ideas.
My changes were less to do with instruction representation, and more related to macros and reusable code.
https://github.com/Lerc/AvrAsm
One example of some of the bits I added, is the macros at
https://gist.github.com/Lerc/ad96329670965dc023c5ae740b433ad...
This provides a blend of macros and snips to allow
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)The load_let_values macro manages to copy values that are defined later in the program.
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.
Have to be rather careful with such - e.g. an x86 vaddpd or an ARM fadd aren't commutative because of NaN bit patterns (even worse for fma, esp. if you have it automatically choose the operation from which arg it's destructive over).
Perhaps not significant for writing code (though maybe someone does want the NaN bit pattern to be taken from a specific arg!), but is one aspect that can easily go missing in a higher-level assembler (or esp. disassembler).
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.
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.
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.
Remains me of an interesting article I read a month ago. About how LLMs can be “anti-meme generators” as in Memetics.
https://www.jernesto.com/articles/anti_meme_explosion
Fascism is another type-4 anti-meme.
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.
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.