at&t syntax in VS?
Not possible AFAICT. The closest you could get is using build rules to get other compilers (GCC) to compile the source files with AT&T syntax. Syntax highlighting won't work neither, of course.
I've heard some pretty crazy things in my time, but actually wanting to use AT&T syntax? [rolleyes]
The Quake 1 source code includes a utility, gas2masm, that is used to preprocess the files before passing them to MASM to allow each version of Quake to share the same assembly source code. I have no idea how good it is for general purpose use, but it works well enough for Quake (and there's quite a lot of assembly in there).
The Quake 1 source code includes a utility, gas2masm, that is used to preprocess the files before passing them to MASM to allow each version of Quake to share the same assembly source code. I have no idea how good it is for general purpose use, but it works well enough for Quake (and there's quite a lot of assembly in there).
Quote:Original post by benryves
I've heard some pretty crazy things in my time, but actually wanting to use AT&T syntax? [rolleyes]
Why not? It's a lot of fun!
Quote:The Quake 1 source code includes a utility, gas2masm, that is used to preprocess the files before passing them to MASM to allow each version of Quake to share the same assembly source code. I have no idea how good it is for general purpose use, but it works well enough for Quake (and there's quite a lot of assembly in there).
See, even id preferred AT&T syntax!
I prefer AT&T syntax. It's less ambiguous.
Back in 2006 I wrote a draft tutorial about converting Intel syntax to at&t syntax. amodes.zip. YMMV.
And you might find Intel2GAS interesting.
I bet a little searching would turn up a utility that converts AT&T to Intel.
Back in 2006 I wrote a draft tutorial about converting Intel syntax to at&t syntax. amodes.zip. YMMV.
And you might find Intel2GAS interesting.
I bet a little searching would turn up a utility that converts AT&T to Intel.
Quote:Original post by LessBread
I prefer AT&T syntax. It's less ambiguous.
The Intel dialect NASM uses isn't ambigious either. Or did I miss something?
I'm not familiar enough with NASM to say.
Here's a snippet from that tut
When I wrote that lcc-win32 employed a variation of AT&T syntax. I don't know what it uses now.
Here's a snippet from that tut
A more troublesome aspect of converting from Intel syntax is that the addition operator allows for the mixing up the order of the computational elements. For example, each of the following Intel expressions evaluate to the same effective address:
[base+index*scale+displacement][index*scale+base][displacement][index*scale+displacement][base][base+displacement][index*scale][displacement+base][index*scale]displacement[base][index*scale]displacement[index*scale][base]
There is only one equivalent expression using lcc-win32 syntax:
displacement(base,index,scale)
When I wrote that lcc-win32 employed a variation of AT&T syntax. I don't know what it uses now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement