Re:New inline assembly syntax available in Rust nightly
by hyperman1 on Tuesday June 09, 2020 @12:47PM
(#23468230)
The intel syntax has some nice gotchas though as the scale can be 1. I believe there is [eax+ebp] which uses the ds segment, but [ebp+eax] uses ss.
Re:New inline assembly syntax available in Rust nightly
by exmadscientist on Tuesday June 09, 2020 @01:38PM
(#23468829)
The really fun bit is when you explicitly want to force one form or other, for some reason. Usually this is related to instruction length, but occasionally you used to run into times when one form could help avoid a stall.
Keeping tricks like that stable and clearly documented is, uh, not for the faint of heart.
Re:New inline assembly syntax available in Rust nightly
by pwdisswordfish2 on Tuesday June 09, 2020 @12:09PM
(#23467850)
% before register names isn't redundant: it allows you to refer to symbols that would otherwise have the same spelling as register names.
Re:New inline assembly syntax available in Rust nightly
by dmytrish on Tuesday June 09, 2020 @12:16PM
(#23467913)
Yes, that's where AT&T is more logical.
In practice, though, naming a symbol with a register name is error-prone and confusing. I'd rather have a way to escape a symbol when it's really needed than to pay the price of noise for an admittedly bad idea.
Re:New inline assembly syntax available in Rust nightly
by cesarb on Tuesday June 09, 2020 @12:42PM
(#23468184)
New registers are added all the time (for instance, the %zmm registers), so even if a symbol name doesn't conflict now, it might conflict in the future. Having separate namespaces for symbols and registers is a good idea.
Re:New inline assembly syntax available in Rust nightly
by renox on Tuesday June 09, 2020 @10:52PM
(#23473411)
Good point, but I wonder if it shouldn't be the labels which should be prefixed instead of the registers?
Re:New inline assembly syntax available in Rust nightly
by burfog on Wednesday June 10, 2020 @01:43AM
(#23474322)
Yes, ideally the labels would be strings in the style of C source code. That includes using \0 to put NUL bytes in the middle. It also includes wide character strings.
This allows for unusual languages like LISP and FORTH, without mangling the symbols. Symbols could have commas and spaces.
However, I recognize that it's objectively worse for a human coder and contains some syntactic footguns which shoot even a experienced coder regularly:
- `number` (memory displacement/pointer) used instead of literal `$number`. It's an easy automatic mistake even for a person who knows this very well.
- the SIB clauses for x86 (memory addressing with constant Displacement and Scale and Index, Base in registers) look like `D(B, I, S)`: it's possible to remember this, but reading/writing it is not as obvious as `[D + B + I * S]`.
- Intel syntax in general is more similar to high-level languages, even though it's more verbose.
- AT&T syntax has syntactic redundancies like '%' before each register which make code much noisier than needed.