Just a little suggestion (maybe will be implemented in next release?):

The Story:

Recently I wrote a simple boolean symbolic constant (and a simple macro to calculate some offsets for a specific format). The macro had no problems, until I did something like:

BTW: the symbolic constant was named used because it was if a parameter was used or not (I decided at first to use that name).


okay, it seemed to work so cool.. but I had a REAL hard time figuring out a bug. The calc_offsets macro was using (I did not know at first this was the problem) the used directive of Fasm. But it compiled fine without it (I dunno why). But bugs showed up, and I was frustrated where the problem comes from.

Now, my suggestion is: Shouldn't the preprocessor check the symbolic constant names and macro names to see if they are valid or not? For example, here are some invalid names:

Names that are Fasm directives (used, defined, in) or operators (and, shl, or) or registers (eax, ebx, etc) should be invalid, of course (like saying "reserved word used as name"

Names that begin with a digit or a '$' should say "numbers cannot be used as names" or something similar

Names that have the form: "var?00000000", you know the local names shouldn't be accessible. Shouldn't it complain about invalid usage? After all, this is not intended.

For macros the same (invalid names such as 'if'). But 'instruction' names should be allowed, for overloading. if on the other side, should be invalid "reserved word used as name"

I'm pretty sure there are others, or maybe not. But I suggest implementing these, unless a strong reason is behind it.

or at least, even if you don't want this to be always applicable, at least an option in the command line/source code (something like "option ValidNames" or "syntax check" or I don't know.. I leave this to you). If the option is on, then it forbids access to those names. Thus:

Since the other operators '+' '-' are forbidden as names, why shouldn't the other ones be as well? Well, I hope it's not absurd..

In my opinion, it would make Fasm look much better, since it checks for such kind of 'errors'. Please tell me what you think about it (and if you don't always want it, implement it as an option). Thanks

ps: even if you don't want it, at least tell something in the manual about such 'invalid' names or names that SHOULDN'T be used. You know, it will make things clearer. thanks i'm looking forward to your replies

sometimes you WANT to "overload" directive or any special symbol. For example i had to write MASM code, and i wanted []s, so i wanted this: "dword ptr [a]" to beheave as "dword [a]" or "dword ptr a". so i just did "ptr equ" and it was done

yeah, but 'ptr' isn't a directive in Fasm, or is it?

or at least an option to turn it on like I said? well, I wouldn't suggest it if I didn't have that nasty bug that has driven me nuts

yes, it is, AFAIK you can use "mov eax, ptr ebx" instead of "mov eax, [ebx]".

I think, that if you are going to use FASM (you seem to be ), you should know all it's directives and operators.

I still think that problem like this is worth having non-overfeatured but powerful language.
look at C's
#pragma WarningC1234(push)
#pragma WarningC1234 off
... code ...
#pragma WarningC1234(pop)

... code then looks like total mess.

ah, I know fasm much better than any other assembler (it's the only one I got exactly how it processes everything, etc.). but in my previous code, it was hard to exactly remember that the macro used the used directive (of course, I later figured this out). Sometimes I just write code, compile, and then check for my errors or typeo's fasm warns of typeo's, but doesn't on the directives.

Just a helpful suggestion. It's not a new 'feature' or directive, just a simple error checking.. who knows maybe it will be in next release...

btw: at least, if it won't be implemented, tell something in the manual (names that should not be used, or something like that (in an appendix or somesuch). It will be much helpful, especially for people who use other's macros/code, and then do some mistakes with these directives. If it was in manual, maybe they would figure it out easily?


about C: ah, yes I agree. Some feature of C are overbloated (not to mention C++ which has crap: public, pure virtual, virtual, private, private inheritance, public... when will it end )

So: you overrode used with used and then used used but wanted used not used. Haha, sorry I couldn't resist saying that.

Get used to it, that is what makes FASM capable of many great tricks (and traps).

The preprocessor see this: The assembler see this: That is why your code would assemble okay.

revolution: yes I know, but my suggestion was that preprocessor 'warns' the user of such names, if it finds any (in define, equ, macro, whatever). At least a warning and not an error, or make it as an option to enable/disable warnings.

Ah yes, I know many Fasm tricks. In fact, I don't recall an other assembler/compiler had the ability of Fasm's tricks (including match, irps and others)

The preprocessor is something completely separate from the assembler, and it shouldn't actually "know" what and how is processed by the assembler later.

But there are literally thousands of warnings that one can make FASM generate for all sorts of potential problems. eg. pop cs or addsubpd xmm0,xmm1. For both of those you can only do such things on particular processors. FASM would become horribly bloated with warning messages.

pop cs
Warning: 'pop cs' only available on 8086
addsubpd xmm0,xmm1
Warning: 'addsubpd' only available on P4prescott/EM64T/AMD64
lea eax,[ebx]
Warning: 'lea reg1,[reg2]' can be optimised to 'mov reg1,reg2'
Warning: 32 bit registers not supported on 8086/186/286
push 4 -3
Warning: 'push val1 -val2' is ambiguous
Warning: 'push imm' not available on 8086
mov ebx,0x80000001
Warning: addresses above 2Gig not supported in WinNT ring3 code
Warning: addresses above 64K not supported in DOS
Warning: 32 bit registers not supported on 8086/186/286
Warning: using denormalised floats is sub-optimal
shl eax,cl
Warning: count in CL not masked in 8086
Warning: count in CL masked to 5 bits in 186+
Warning: 32 bit registers not supported on 8086/186/286
.end
Warning: some LINUX kernel builds require writeable BSS section
macro or a,b {
Warning: 'or' does not override 'Or', 'oR', or 'OR'
used equ
Warning: 'used' is overridden and may confuse the hell out of you
include 'lost_in_space.inc'
Warning: warning Will Robinson (imagine flailing robot arms)

It isn't hard just to check for some names (not to execute them). In fact, it has only to do with 'define' and other preprocessor directives.

compiling, for example: "a = b + xor" gives an error/warning, and it's ok since using 'xor' here is bad practice (ok, assuming xor is a numerical constant, on which the assembly stage is based).

I was just suggesting that preprocessor should check for such names. Or add some options (enable/disable such checks). It is not necessary part of 'warnings', it's just more checks. I see assembly stage has checks, but preprocessing stage lacks it.

I'm not really sure, but I think it can't be done with macros (since symbol is considered an entity, I can't for example, take the first character and see what it is).

revolution: I know warning can be frustrating, but I didn't necessary employ that this 'checking' I suggest were 'warnings' -- that was only an idea. I was suggesting only 'checking' for that, the rest would be up to Tomasz to implement how he wants it -- be it that he replaces every 'used' there (except in 'ifs') with some other name automatically, or gives errors (like assembly stage), or warnings, or whatever. It's his design, I only made some suggestions.

I didn't know it can be such a silly suggestion, sorry if it was.

It's not about whether it's hard or not to do - it's about the design philosophy. The preprocessor should just processes texts, without investingating what are there.