I really don't see any syntax as "official"... everyone has their own flavor... and that shouldn't be pushed onto others.


Well, as Intel developed the instruction set, they certainly have the right to define the "official" syntax. Of course, people do *not* have to adhere or use the official syntax. Indeed, there are good reasons for using a radically different syntax (else why would I have given HLA such a radically different syntax?). But you can't have it both ways -- change the syntax for whatever reason and then try to claim that you're following the official (or Intel) syntax.
Cheers,
Randy Hyde
Posted on 2005-07-29 10:40:53 by rhyde

I think I saw a sentence along the lines of "modelled after the intel {standard,syntax,whatever}" somewhere, sometime, in the NASM documentation. Which would indicate that it's not the `official intel syntax`, but a derivate :)



Largely, what most people think when they use the term "Intel syntax" is (1) the same instruction mnemonics, and (2) the "dest, src" operand ordering. Almost every "Intel Syntax Compatible" assembler (with the exception of MASM) deviates completely in every other sense.

If an assembler follows the "Intel syntax", this says that you can take *any* Intel syntax assembly source file and compile it using that assembler. This just isn't the case with all the so-called "Intel syntax" assemblers out there (technically, it's not even the case with MASM, but MASM comes the closest).

One of the most fundamental features of the "Intel syntax" was typed identifiers. If an assembler cannot figure out that "ThisIdentifier" is a memory variable, constant, or something else, on the basis of information kept in the symbol table, then it's *not* an Intel syntax assembler. That is, if your assembler requires brackets to denote memory addressing, it is *not* an Intel syntax assembler. Similarly, if your assembler doesn't require "offset" to tell the assembler to use a variable's address as a constant in an expression, it is *not* an Intel Syntax assembler. Likewise, if your assembler doesn't use phrases like "byte ptr" or "word ptr" to coerce the size of a memory operand, it is *not* an Intel Syntax assembler. If your assembler doesn't use all the original Intel directives (e.g., "db", "dw", etc., IIRC), it is *not* an Intel Syntax assembler.

Again, there have been no true "Intel Syntax" assemblers since Intel removed ASM386 from the market, but MASM does come pretty close. TASM comes in second (if you ignore "ideal mode"). Everyone else follows way off in the distance.
Cheers,
Randy Hyde
Posted on 2005-07-29 10:47:33 by rhyde
You dont like the term mnemonic sintaxis uh? ;), not intel, not amd sintaxis, but mnemonic.
Posted on 2005-07-29 10:48:33 by rea

You dont like the term mnemonic sintaxis uh? ;), not intel, not amd sintaxis, but mnemonic.


Well, in computer science the phrase "syntax" has a very specific meaning. It means we have a grammar (of some sort) that describes which strings are legal in a language and which are not (a "string", in computer theory, corresponds to a whole program source file in this particular case).

We can certainly define a "grammar" via a set of regular expressions that specify the mnemonics to use. And most so-called "intel-compatible" assemblers would accept that grammar.

However, when one speaks of an "Intel-compatible" syntax, the only reason for the importance of such a term is because someone is asking "if I write my source code in an 'Intel-compatible syntax' mode, how much work is involved in getting the code to compile with a less compliant assembler?"  Sure, not having to change all the mnemonics helps. Likewise, not having to change the order of the instructions helps. But with an assembler like NASM or FASM, you wind up changing a signficant number of lines of source code in order to get it into an Intel compatible format (or convert an Intel compatible format to NASM/FASM).

Source code compatibility is *the* reason we'd like to see Intel Syntax in an assembler. This gives a product (like MASM) a marketing advantage when there is a huge body of Intel Syntax source code laying around. It's also helpful if an assembler uses Intel syntax when reading through the Intel manuals and trying to use that information in your programs.

Alas, like monitor sizes, disk drive sizes, "Intel Inside", and so on, once the "marketing people" get their hands on a term like "Intel Syntax" it gets perverted all to Hell. <<People want "Intel Syntax", so we'll use that term to describe our product even if we're not strictly Intel Syntax compatible>>  You get the idea.

The sad part, as many people know, is that Intel Syntax is not without its blemishes. There are good reasons for producing an assembler that is *not* Intel syntax compatible. Too bad various assembler authors try to hide behind a false claim of "Intel Syntax" rather than celebrating their differences from Intel syntax.  Ultimately, this causes confusion for beginners and achieves very little else.
Cheers,
Randy Hyde
Posted on 2005-07-29 11:04:28 by rhyde
I must admit, I have never seen the differences as anything else than parser dictated considerations based on the authors preferences and how powerful their parser was.

GAS uses AT&T which is a major shift from most x86 assemblers in operand order but the rest have varying degrees of similarity to Intel syntax as defined by the old Intel assemblers. That MASM is the closest to the old Intel syntax probably has something to do with it having been around since 1981 and this produces a massive body of code that is written in this format.

NASM is a portable assembler and it has no reason to be Intel syntax as it can be used on non x86 platforms so I tend to refer to it as NASM syntax. FASM is similar with it bracketing requirements and both follow the TASM ideal mode requirement of bracketing named memory operands.

Randy is certainly correct here in that the actual notation dictates what is the closest to historical Intel syntax and apart from the advertising value, none of the others properly do this as they have their own notation and should claim it that way, not make claims that are not correct.

Regards,

hutch at movsd dot com
Posted on 2005-07-30 12:50:39 by hutch--

NASM is a portable assembler and it has no reason to be Intel syntax as it can be used on non x86 platforms so I tend to refer to it as NASM syntax.

While the assembler is portable to basically any platform with a C compiler, it still only assembles x86 code, though.
Posted on 2005-08-01 08:52:42 by f0dder
I guess if I remember correctly, there was a version not ready?? at all for ARM?? I dont remember exactly wich member of the board point it... Ultrano???? tought I guess he switch to other one... peraphs.
Posted on 2005-08-15 01:31:54 by rea
Yes, there's a NASM port, called "NARM", assembling ARM code. Most funcs of NASM were enabled, but macros were not available. And it did produce wrong code from time to time.
Since my other option was to lose my sanity with GAS, I made a third option - an average-power preprocessor.
Making a custom preprocessor is easy, and has lot and lots of pros. You modify and add to the HLL syntax in the way it's best for you, keep your sanity by staying off the GAS syntax, and if you want some powerful macro - you implement it in the preprocessor's code, not as a script.
The only cons is that if you get an error on some line, its number won't match. The real assembler will say the error is on line 3176, while the error will be at line 1704 on your custom.asm . This is the reason I haven't made a powerful MASM-overlay.
Posted on 2005-08-15 06:14:27 by Ultrano
I remember modificating the preprocesor of nasm for suport directly structs/unions (in some way... lol), can lead to more fast assembling (half time) when you include for example nagoa.inc. I have passed much time figuring what I will do in the future, but best to choose one of the options tha I have now :D...
Posted on 2005-08-15 10:39:29 by rea