It's not about beautiful looking code. It's about semantics. People created textual symbols and symbolic languages because they didn't want to get confused with similar-looking patterns which proven to be error-prone by the past machine coders.

It's like naming your kid as Tyrone, and his kids as Tyrone, and their next kids as all Tyrone. Is it wrong? No but it creates a very confusing semantics. Imagine the family name....

Sorry for going off-topic. (Perhaps this and my last post should be split off into the Heap.)

There's a lot that could be said on this, even though I'm no expert. Redundancy is bad when you're trying to be exact, but that's why there are many ways of identifying something, and context matters a lot. Generally speaking, the smaller number of reserved words, the better. But a lot of times "reserved", even in traditional programming languages, only applies to certain sections of the grammar. So you can't necessarily use "if" as a variable in C, but you can make a structure member (or indeed several, since C89 or MASMv6) named that. (Example omitted because it's pointless.)

I think there are case-sensivity and dotted string features for dealing with similar-looking identifiers (if such necessity ever arises at all, which I doubt it). A good-compiler / language should be able to separate the idea of reserved words, keywords, directives and identifiers as far apart as possible from each other. It should be more strict with an assembler because the reserved words are already and clearly defined in the Manuals.

That's not true. Things are clearly defined at the point you start the code, but not in the future, and that's the issue. Instructions and "reserved keywords" can be added. Look at the mess C++ is in.

The C++ Committee hates adding new keywords for the reason that they are "reserved" (which is a bad design to begin with, it should be deducible from context). Do you know "requires" is/will be a keyword in C++ now? It didn't use to be, so if you have any variable or function or struct or whatever called requires, it will fail to compile when you upgrade compilers and switch to new standard.

NASM allows you to use "reserved" keywords and deduce them from context, which is arguably better design, you don't risk of having your code fail to compile if you use a newer version of the assembler, because Intel or whoever decided to add an instruction that just so happens to coincide with a label name you used. It's as simple as that.

PS: Theoretically, you can compile most C code with a C++ compiler, however, you cannot compile the Linux Kernel with a C++ compiler. Because it uses the reserved word "class" and probably others. Imagine if C++ replaced C instead of being a new language. It's not unreasonable to use the word "class" for a variable or label at all. (e.g. class of the data code of your structure)

i remember when crc32 was added to the x86 instruction set. A lot of our code no longer compiled. Fortunately I'm using fasm so I was able to alter the assembler temporarily to get things moving again. And then later I had to go through all the code and change the crc32 label name to something else.

That's not true. Things are clearly defined at the point you start the code, but not in the future, and that's the issue. Instructions and "reserved keywords" can be added. Look at the mess C++ is in.

The C++ Committee hates adding new keywords for the reason that they are "reserved" (which is a bad design to begin with, it should be deducible from context). Do you know "requires" is/will be a keyword in C++ now? It didn't use to be, so if you have any variable or function or struct or whatever called requires, it will fail to compile when you upgrade compilers and switch to new standard.

NASM allows you to use "reserved" keywords and deduce them from context, which is arguably better design, you don't risk of having your code fail to compile if you use a newer version of the assembler, because Intel or whoever decided to add an instruction that just so happens to coincide with a label name you used. It's as simple as that.

PS: Theoretically, you can compile most C code with a C++ compiler, however, you cannot compile the Linux Kernel with a C++ compiler. Because it uses the reserved word "class" and probably others. Imagine if C++ replaced C instead of being a new language. It's not unreasonable to use the word "class" for a variable or label at all. (e.g. class of the data code of your structure)

I don't care about C++. Nobody is talking about C++ here or any other HLL language. C++/C have to come up with their own keywords because they are built from scratch. On the contrary, ASM's keywords are already and clearly defined in the manuals.

When we talk about "syntax", we talk about the human-side of the language, human perceptions, human semantics and rules. Not the machine side. Hence, we call it syntax error rather mnemonics error, because we concern more about the human readers and not the machine.

What is one of the greatest sin in SYNTAX RULES? Using the reserve words to mean something else not intended for its original use and semantics. These rules become conventions and observing it is part of the GOOD PROGRAMMING PRACTICE [GPP]. Surprising to see that NASM breaks this rule considering the fact that it was built on top of strict language such as C.

Things get from bad to worse if you're using AT&T syntax because they completely disregard the suggested keywords in the manuals and just like NASM, they allow such things to happen. I bet you must be a big fan of ATT syntax then, or perhaps the brainfuck! language>

If ASM would ever have to come to that lowest point by whoring up reserved words for other purposes, then you must be happy with BriainFuck language;

On the contrary, ASM's keywords are already and clearly defined in the manuals.

Same with C++ at a certain point in time.

I'm talking about additions to the "language". In the case of asm, this means new instructions which are basically keywords. (in HLLs of course there's no instructions). Instructions that don't exist right now but might in the future. Nobody knows the future.

If you still can't see the point, read revolution's last post about crc32 instruction.

Would you name a label crc32 if it calculated the crc32 before the instruction was available? If so, your code would fail to compile in the future because of name clash with the crc32 instruction.

On the contrary, ASM's keywords are already and clearly defined in the manuals.

Same with C++ at a certain point in time.

I'm talking about additions to the "language". In the case of asm, this means new instructions which are basically keywords. (in HLLs of course there's no instructions). Instructions that don't exist right now but might in the future. Nobody knows the future.

If you still can't see the point, read revolution's last post about crc32 instruction.

Would you name a label crc32 if it calculated the crc32 before the instruction was available? If so, your code would fail to compile in the future because of name clash with the crc32 instruction.

You are one big time-wasting anomaly in life. One time you support NASM blasphemy for allowing reserved words as identifiers but now you oppose such idea of using them as label. You don't have to work that hard to prove that you're a complete incompetence.

So rewind back before crc32 instruction existed (Intel did not create it yet), you have this code:

Code:

callcrc32
crc32:; ...

Code works fine, compiles. Both NASM and FASM compile it. All is good. At this point, your code is perfectly legal.

Years later, Intel add crc32 instruction, FASM makes it "reserved" on new version, now only NASM compiles your perfectly valid code you written, new versions of FASM don't anymore.

In general this is not as simple as you presented it here. Consider a variant where you have a pointer to function (perhaps witch a switchable implementation dependent on an instruction set):

Code:

call [crc32]; ...
crc32dd0

This does not work with modern NASM either, the ambiguity is just too strong.

It works in a similar way in fasmg - there are separate classes of symbols for instructions, labeled instructions and symbols that may be used in the expressions (operands) and you can use the same name in a different class with a different meaning, but this still does not prevent problems when an ambiguity arises. In fasmg, to make things clear, when the name is a first symbol in a line the instruction-class symbol always has a priority over others.

Yeah, NASM isn't ideal design either (what I have in mind), I'm guessing we need a sort of intelligent parser for that (which would make it slower). I don't know FASMG, seems pretty different "goal" than FASM (not just x86 assembler that is), so sorry about that, can it compile all x86 code?

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum