On 3/23/23 07:03, Martin Storsjö wrote:
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.
Oh, right, thanks. I pushed with that changed. If we find more
compatibility problems, we can also have configure check, but that
doesn't seem needed at this point.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
