public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Please, really, make `-masm=intel` the default for x86
@ 2022-11-25  6:39 LIU Hao
  2022-11-25  7:37 ` Hi-Angel
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: LIU Hao @ 2022-11-25  6:39 UTC (permalink / raw)
  To: gcc


[-- Attachment #1.1: Type: text/plain, Size: 1083 bytes --]

I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. One 
annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I have 
to do it twice: one in AT&T syntax and one in Intel syntax.


The AT&T syntax is an awkward foreign dialect, designed originally for PDP-11 and spoken by bumpkins 
that knew little about x86 or ARM. No official Intel or AMD documentation ever adopts it. The syntax 
is terrible. Consider:

    movl $1, %eax  ; k; moves $1 into EAX
                   ; but in high-level languages we expect '%eax = $1',
                   ; so it goes awkwardly backwards.

If this looks fine to you, please re-consider:

   cmpl $1, %eax
   jg .L1          ; does this mean 'jump if $1 is greater than %eax'
                   ; or something stupidly reversed?

If CMP still looks fine to you, please consider how to write VFMADD231PD in AT&T syntax, really.


I have been tired of such inconsistency. For God's sake, please deprecate it.


-- 
Best regards,
LIU Hao

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  6:39 Please, really, make `-masm=intel` the default for x86 LIU Hao
@ 2022-11-25  7:37 ` Hi-Angel
  2022-11-25  7:56   ` LIU Hao
  2022-11-25  8:50 ` Marc Glisse
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 13+ messages in thread
From: Hi-Angel @ 2022-11-25  7:37 UTC (permalink / raw)
  To: LIU Hao; +Cc: gcc

On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc <gcc@gcc.gnu.org> wrote:
> One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I
> have to do it twice: one in AT&T syntax and one in Intel syntax.

Why? A default is merely a default. I don't really see why changing
that should help you specifically. A decision "which assembly syntax
to use" is one that makes a project like ones you're contributing to,
not GCC. If they decided to use AT&T syntax, they won't switch to
Intel just because a compiler toolchain has changed their default.

If you care specifically about the projects you are contributing to,
then those are the ones whom you need to convince to switch to "intel"
assembly syntax, not the GCC developers. Because as I said, changing a
default in GCC will hardly make any change to those other projects.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  7:37 ` Hi-Angel
@ 2022-11-25  7:56   ` LIU Hao
  0 siblings, 0 replies; 13+ messages in thread
From: LIU Hao @ 2022-11-25  7:56 UTC (permalink / raw)
  To: Hi-Angel; +Cc: gcc


[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

在 2022/11/25 15:37, Hi-Angel 写道:
> Why? A default is merely a default. I don't really see why changing
> that should help you specifically. A decision "which assembly syntax
> to use" is one that makes a project like ones you're contributing to,
> not GCC. If they decided to use AT&T syntax, they won't switch to
> Intel just because a compiler toolchain has changed their default.
> 

There's a lot more than that. The AT&T syntax usually surprises people; and more importantly, for 
miserable beginners on GCC inline assembly, they can't start learning from official Intel 
documentation, but have to learn from some non-standard, insane and incompatible dialect. That's 
just too unfortunate.

The AT&T syntax should really die out, but if it is kept the default, that is never going to happen.


> If you care specifically about the projects you are contributing to,
> then those are the ones whom you need to convince to switch to "intel"
> assembly syntax, not the GCC developers. Because as I said, changing a
> default in GCC will hardly make any change to those other projects.

That is a poor reason for putting up with a piece of 50-year-old evilness and refusing to move 
forward. Upgrading the compiler is always a big change, and updating sources should be expected, 
when we take `-Werror` into account.


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  6:39 Please, really, make `-masm=intel` the default for x86 LIU Hao
  2022-11-25  7:37 ` Hi-Angel
@ 2022-11-25  8:50 ` Marc Glisse
  2022-11-25  9:11   ` LIU Hao
  2022-11-25  9:32 ` Jakub Jelinek
  2022-11-25 13:31 ` David Brown
  3 siblings, 1 reply; 13+ messages in thread
From: Marc Glisse @ 2022-11-25  8:50 UTC (permalink / raw)
  To: LIU Hao; +Cc: gcc

On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:

> I am a Windows developer and I have been writing x86 and amd64 assembly for 
> more than ten years. One annoying thing about GCC is that, for x86 if I need 
> to write I piece of inline assembly then I have to do it twice: one in AT&T 
> syntax and one in Intel syntax.

The doc for -masm=dialect says:

 	Darwin does not support ‘intel’.

Assuming that's still true, and even with Mac Intel going away, it doesn't 
help.

-- 
Marc Glisse

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  8:50 ` Marc Glisse
@ 2022-11-25  9:11   ` LIU Hao
  2022-11-25  9:30     ` Jonathan Wakely
  2022-11-25  9:56     ` Iain Sandoe
  0 siblings, 2 replies; 13+ messages in thread
From: LIU Hao @ 2022-11-25  9:11 UTC (permalink / raw)
  To: gcc


[-- Attachment #1.1: Type: text/plain, Size: 749 bytes --]

在 2022/11/25 16:50, Marc Glisse 写道:
> On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
> 
>> I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. 
>> One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I 
>> have to do it twice: one in AT&T syntax and one in Intel syntax.
> 
> The doc for -masm=dialect says:
> 
>      Darwin does not support ‘intel’.
> 
> Assuming that's still true, and even with Mac Intel going away, it doesn't help.
> 

Did you mean 'Darwin' instead of 'macOS'?

The first-class C and C++ compiler for macOS is Clang anyway; even the thing named 'gcc' is 
effectively Clang.


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  9:11   ` LIU Hao
@ 2022-11-25  9:30     ` Jonathan Wakely
  2022-11-25  9:56     ` Iain Sandoe
  1 sibling, 0 replies; 13+ messages in thread
From: Jonathan Wakely @ 2022-11-25  9:30 UTC (permalink / raw)
  To: LIU Hao; +Cc: gcc

On Fri, 25 Nov 2022 at 09:16, LIU Hao via Gcc <gcc@gcc.gnu.org> wrote:
>
> 在 2022/11/25 16:50, Marc Glisse 写道:
> > On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
> >
> >> I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years.
> >> One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I
> >> have to do it twice: one in AT&T syntax and one in Intel syntax.
> >
> > The doc for -masm=dialect says:
> >
> >      Darwin does not support ‘intel’.
> >
> > Assuming that's still true, and even with Mac Intel going away, it doesn't help.
> >
>
> Did you mean 'Darwin' instead of 'macOS'?

Darwin is the name used in the GNU target triplet. It's an older name
than macOS, which was previously called OS X.

> The first-class C and C++ compiler for macOS is Clang anyway; even the thing named 'gcc' is
> effectively Clang.

And? GCC still works there. As a Windows developer I'm surprised to
hear you suggesting that only the default system compiler matters.
Should GCC stop supporting Windows?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  6:39 Please, really, make `-masm=intel` the default for x86 LIU Hao
  2022-11-25  7:37 ` Hi-Angel
  2022-11-25  8:50 ` Marc Glisse
@ 2022-11-25  9:32 ` Jakub Jelinek
  2022-11-25 12:01   ` LIU Hao
  2022-11-25 13:31 ` David Brown
  3 siblings, 1 reply; 13+ messages in thread
From: Jakub Jelinek @ 2022-11-25  9:32 UTC (permalink / raw)
  To: LIU Hao; +Cc: gcc

On Fri, Nov 25, 2022 at 02:39:41PM +0800, LIU Hao via Gcc wrote:
> I am a Windows developer and I have been writing x86 and amd64 assembly for
> more than ten years. One annoying thing about GCC is that, for x86 if I need
> to write I piece of inline assembly then I have to do it twice: one in AT&T
> syntax and one in Intel syntax.

So just use -masm=intel yourself and don't force it on others.

Other people are familiar with AT&T syntax rather than Intel syntax,
in fact, as history shows, Intel syntax is a second class citizen that often
takes years to fix up for new instructions.  The memory size prefixes for
certain vector instructions are complete lottery and has been changed by the
assembler over time.

And more importantly, various valid sources aren't really compilable at all
with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details.

	Jakub


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  9:11   ` LIU Hao
  2022-11-25  9:30     ` Jonathan Wakely
@ 2022-11-25  9:56     ` Iain Sandoe
  1 sibling, 0 replies; 13+ messages in thread
From: Iain Sandoe @ 2022-11-25  9:56 UTC (permalink / raw)
  To: LIU Hao; +Cc: GCC Development



> On 25 Nov 2022, at 09:11, LIU Hao via Gcc <gcc@gcc.gnu.org> wrote:
> 
> 在 2022/11/25 16:50, Marc Glisse 写道:
>> On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
>>> I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I have to do it twice: one in AT&T syntax and one in Intel syntax.
>> The doc for -masm=dialect says:
>>     Darwin does not support ‘intel’.
>> Assuming that's still true, and even with Mac Intel going away, it doesn't help.
> 
> Did you mean 'Darwin' instead of 'macOS'?
> 
> The first-class C and C++ compiler for macOS is Clang anyway; even the thing named 'gcc' is effectively Clang.

Darwin, OS X, PureDarwin, macOS (Intel) all default to AT&T
(as does clang on the platform - I am not even sure if Intel syntax is supported for macOS/Darwin there either).
.. we can be 100% sure that any Intel syntax support is (at least almost) completely untested.

NOTE that the GCC gfortran (and Ada) remain the tools of choice on macOS (and they also need the assembler).

It would be pretty difficult to change the default; if GCC changed, I’d only end up patching the Darwin port to default to AT&T .. perhaps a solution for the Windows port is to patch it locally to default to Intel?

Iain

> 
> 
> -- 
> Best regards,
> LIU Hao
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  9:32 ` Jakub Jelinek
@ 2022-11-25 12:01   ` LIU Hao
  2022-11-25 13:00     ` Richard Biener
  0 siblings, 1 reply; 13+ messages in thread
From: LIU Hao @ 2022-11-25 12:01 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc


[-- Attachment #1.1: Type: text/plain, Size: 950 bytes --]

在 2022/11/25 17:32, Jakub Jelinek 写道:
> So just use -masm=intel yourself and don't force it on others.
> 
> Other people are familiar with AT&T syntax rather than Intel syntax,
> in fact, as history shows, Intel syntax is a second class citizen that often
> takes years to fix up for new instructions.  The memory size prefixes for
> certain vector instructions are complete lottery and has been changed by the
> assembler over time.
> 
> And more importantly, various valid sources aren't really compilable at all
> with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details.
> 

Well, if that's your decision, fair enough. I can maintain my own distribution.

Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any issues so far.


[1] 
https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25 12:01   ` LIU Hao
@ 2022-11-25 13:00     ` Richard Biener
  0 siblings, 0 replies; 13+ messages in thread
From: Richard Biener @ 2022-11-25 13:00 UTC (permalink / raw)
  To: LIU Hao; +Cc: Jakub Jelinek, gcc

On Fri, Nov 25, 2022 at 1:03 PM LIU Hao via Gcc <gcc@gcc.gnu.org> wrote:
>
> 在 2022/11/25 17:32, Jakub Jelinek 写道:
> > So just use -masm=intel yourself and don't force it on others.
> >
> > Other people are familiar with AT&T syntax rather than Intel syntax,
> > in fact, as history shows, Intel syntax is a second class citizen that often
> > takes years to fix up for new instructions.  The memory size prefixes for
> > certain vector instructions are complete lottery and has been changed by the
> > assembler over time.
> >
> > And more importantly, various valid sources aren't really compilable at all
> > with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details.
> >
>
> Well, if that's your decision, fair enough. I can maintain my own distribution.
>
> Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any issues so far.

it would be also possible to at a configure time choice, or one driven
by config.gcc (thus
*mingw* could default to intel syntax if they like).

Richard.

>
> [1]
> https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch
>
>
> --
> Best regards,
> LIU Hao
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  6:39 Please, really, make `-masm=intel` the default for x86 LIU Hao
                   ` (2 preceding siblings ...)
  2022-11-25  9:32 ` Jakub Jelinek
@ 2022-11-25 13:31 ` David Brown
  3 siblings, 0 replies; 13+ messages in thread
From: David Brown @ 2022-11-25 13:31 UTC (permalink / raw)
  To: LIU Hao, gcc

On 25/11/2022 07:39, LIU Hao via Gcc wrote:
> I am a Windows developer and I have been writing x86 and amd64 assembly 
> for more than ten years. One annoying thing about GCC is that, for x86 
> if I need to write I piece of inline assembly then I have to do it 
> twice: one in AT&T syntax and one in Intel syntax.
> 
> 
> The AT&T syntax is an awkward foreign dialect, designed originally for 
> PDP-11 and spoken by bumpkins that knew little about x86 or ARM. No 
> official Intel or AMD documentation ever adopts it. The syntax is 
> terrible. Consider:
> 
>     movl $1, %eax  ; k; moves $1 into EAX
>                    ; but in high-level languages we expect '%eax = $1',
>                    ; so it goes awkwardly backwards.
> 
> If this looks fine to you, please re-consider:
> 
>    cmpl $1, %eax
>    jg .L1          ; does this mean 'jump if $1 is greater than %eax'
>                    ; or something stupidly reversed?
> 
> If CMP still looks fine to you, please consider how to write VFMADD231PD 
> in AT&T syntax, really.
> 
> 
> I have been tired of such inconsistency. For God's sake, please 
> deprecate it.
> 
> 

You can have all the personal preferences or prejudices you want, but 
that won't change the fact that AT&T syntax was the standard x86 
assembly from long before Intel thought of making their own syntax, and 
it is here to stay.  No one is going to deprecate it, remove it, or 
change any defaults.


#include <stdio.h>

int main(void)
{
     int temp=0;

     asm
     (   ".intel_syntax noprefix"
         "mov %0, 1"
         ".att_syntax"
         : "=r"(temp)
         :                   /* no input*/
     );
     printf("temp=%d\n", temp);
}


A use feature that could be added to gcc, perhaps, would be a way to let 
the user specify the assembler dialect as part of the "asm" statement:

	asm __attribute__((masm = "intel")) ( ... )

The idea with this is that it would issue the requested ".intel_syntax 
noprefix" or ".att_syntax" at the start of the assembly, and the 
appropriate directive to return to normal syntax at the end - adjusting 
according to the "-masm" setting for the compilation.  This would, I 
think, let people write the assembly once in the syntax they choose, and 
have it work smoothly regardless of which syntax is chosen for compilation.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
  2022-11-25  7:48 Dave Blanchard
@ 2022-11-25  8:03 ` LIU Hao
  0 siblings, 0 replies; 13+ messages in thread
From: LIU Hao @ 2022-11-25  8:03 UTC (permalink / raw)
  To: Dave Blanchard, gcc


[-- Attachment #1.1: Type: text/plain, Size: 869 bytes --]

在 2022/11/25 15:48, Dave Blanchard 写道:
> While I sympathize with the desire to get rid of crud (and I agree that AT&T syntax is crud), as stated above it wouldn't really make a practical difference. For distro maintainers it would likely break some/many older packages which assumed the old default behavior, thus requiring a number of patches. Usually not a big deal in and of itself (though it can be if the build system for that package is particularly junky), but when you consider there are so many packages including GCC always deprecating and changing things, it adds up to a lot of work to keep up with it all.
> 

I hope that, if we decide to make Intel syntax the default since GCC 14, then such crud will be 
eventually got rid of since GCC 24. OTOH, if we don't do that, we would have to live with it forever.


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Please, really, make `-masm=intel` the default for x86
@ 2022-11-25  7:48 Dave Blanchard
  2022-11-25  8:03 ` LIU Hao
  0 siblings, 1 reply; 13+ messages in thread
From: Dave Blanchard @ 2022-11-25  7:48 UTC (permalink / raw)
  To: gcc


On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc <gcc@gcc.gnu.org> wrote:
>> One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I
>> have to do it twice: one in AT&T syntax and one in Intel syntax.

> Why? A default is merely a default. I don't really see why changing
> that should help you specifically. A decision "which assembly syntax
> to use" is one that makes a project like ones you're contributing to,
> not GCC. If they decided to use AT&T syntax, they won't switch to
> Intel just because a compiler toolchain has changed their default.

While I sympathize with the desire to get rid of crud (and I agree that AT&T syntax is crud), as stated above it wouldn't really make a practical difference. For distro maintainers it would likely break some/many older packages which assumed the old default behavior, thus requiring a number of patches. Usually not a big deal in and of itself (though it can be if the build system for that package is particularly junky), but when you consider there are so many packages including GCC always deprecating and changing things, it adds up to a lot of work to keep up with it all.

-- 
Dave Blanchard <dave@killthe.net>

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-11-25 13:32 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-25  6:39 Please, really, make `-masm=intel` the default for x86 LIU Hao
2022-11-25  7:37 ` Hi-Angel
2022-11-25  7:56   ` LIU Hao
2022-11-25  8:50 ` Marc Glisse
2022-11-25  9:11   ` LIU Hao
2022-11-25  9:30     ` Jonathan Wakely
2022-11-25  9:56     ` Iain Sandoe
2022-11-25  9:32 ` Jakub Jelinek
2022-11-25 12:01   ` LIU Hao
2022-11-25 13:00     ` Richard Biener
2022-11-25 13:31 ` David Brown
2022-11-25  7:48 Dave Blanchard
2022-11-25  8:03 ` LIU Hao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).