Who is vfmaddrnd231pd?
purplesyringa.moe
purplesyringa.moe
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.
Theory: It was removed due to hardware issue and never worked
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?
Edit: Checked the article and dang... x86
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.
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.
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.
Remains me of an interesting article I read a month ago. About how LLMs can be “anti-meme generators” as in Memetics.
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.
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
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.
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.
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))
Another example, on x64 (IIRC)
a = a + b + 42
d = d + 4 × e
d = 5 × d // equivalent to d = d + 4 × d
a = a + b + c
d = d + 5 × e
d = 7 × d
You can make it easier to write by allowing ‘obvious’ rewrites such as
a = b + c + d
a = b + c
a = a + d
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.
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.
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).
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.