On Wed, 22 Mar 2023, Jacek Caban wrote:
On 3/22/23 15:21, LIU Hao wrote:
在 2023-03-22 21:07, Jacek Caban 写道:
That's the motivation for this? I can see a point in supporting both
syntaxes in headers (which may be included by users with various
compiler options), but for crt, why isn't supporting a single syntax
understood by all supported compilers enough?
Yes that is the only motivation.
Why? Because AT&T is unofficial, foreign, and awkward.
1. No Intel or AMD doc ever speaks this way. This is already enough
for
being thrown into the dustbin of history.
2. It was designed for PDP originally, and got widespread just
because
Plan 9 dogs couldn't stop barking. Oh please take a look at the Go
assembler, and what they've done to ARM, brilliant.
3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`,
not
the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for
`cmp`.
4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not
`movl 12(%rsi, %rbx, 8), %eax`.
Intel syntax also copes better with other tools - Microsoft compilers,
NASM, IDA, x64dbg, countless assembler and disassemblers - none of them
produce or accept nonstandard AT&T syntax in any way. There have been
enough talks about that [1]; I hope I would not have to repeat myself
[2].
[1] https://outerproduct.net/2021-02-13_att-asm.html
[2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html
I didn't really mean to ask which syntax is better, but what exactly are
we trying to achieve. From GCC thread, my understanding is that you want
to support toolchains that default to Intel syntax. How about the
attached patch?
You need to move the option down into (the weirdly named) CPPFLAGS32 and
CPPFLAGS64; for arm/aarch64 targets, Clang warns and GCC errors if given
the -masm=att parameter.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
