Why FASM doesn't use any prefix for its own macro directives? I'm just curious about this decision. For example, NASM uses % as a prefix for all directives which can be used for writing macroses.

It could open a door for better names of some custom macroses in fasm. For example, if macro directives if, else and endif will be prefixed like #if, #else and #endif, it will allow to write macroses if, else and endif (not .if, .else, .endif) which will control actual execution of the program. Directives load and store also occupy very common and good names which could be used for possible instructions which will work during execution of an application. Maybe even some processor has instructions with such mnemonics, and as the result someone who will write a new set of macroses for this CPU will be forced to use other names for these instructions.

I mean that macro directives are tools for building instructions for writing programs, and maybe it is better when these directives have some prefix which will clearly distinguish them. What do you think?

As for me I, like the way it's implemented in fasmg - witout any prefixes. If prefix is needed, it can be introduced by user in a custom macro. Everyone is happy.

Do you mean that I can easily add prefixes to all standard macro directives and free all original names for using as names of my macroses?

For example, is it possible to rename "while" to "#while", use "#while" everywhere where I need a loop during assembly time, and create my own macro with name "while" which will be also easily used without problems with such name?

Actually, I understand that I can fix it in the source code of the FASM if I don't like it so much. But I'm too lazy to support my own version of FASM It is better to spend this time for writing actual code of my projects using existing syntax even if I disagree with it in some moments.

So, I'm just trying to understand pros of macro directives without a prefix. Ok, you have to type one character less for a macro directive when there are no prefix. But you're writing programs more than you're writing macroses. And it is better when shorter names could be used as names of your macroses, because your macroses will be used during writing of actual programs.

I'm sure this is just a personal preference thing.

I personally hate all those extra %, #, $, & etc. I need to use the shift key and a number key which are hard to type and slows me down. And similarly in C and all the different brackets (){} and colons : and asterisks * and hashes # and stuff that it requires. Easy for a computer to recognise but terrible for a human to type.

BTW: It is usually 'macros' not 'macroses'. I've seen this spelling before and it is usually from Russia, Ukraine and nearby.

Oh, thank you. I thought that "macros" is the singular form of the word, like in Russian language. Next time I will use proper spelling.

Well, basically yes, you can create custom macroses which will mimic behavior of standard directives and redefine existing directives to do something different. But before doing this think about others who will support your code. Creating a completely different syntax may be not that great idea unless you're the only one who intend to use it.

zhak, every time when you're writing some new macros, actually you create a "new assembler" with non-standard instructions, and it will be not easy to support for a random programmer without getting into your project deeply. The same with an upgraded syntax of macros. But in most cases it will not be required to touch code of macros. Usually you have to write actual code. You're writing new macros only when you would like to add a new convenient instruction for writing actual code.

Actually, I am the only person who supports my projects written using FASM, so it doesn't matter. I can use any non-standard things and it is ok. Actually, in the real world, using assembly languages are considered as "not supportable" at all, and it is mostly prohibited to use it (except for some extremely rare cases). But I don't care. I use FASM for my own projects if I wish. And it doesn't matter if someone else thinks that it is not easy to support.

We will try to support you here if we can. But if you use a custom syntax and opcodes etc. then it makes the task of assisting much more difficult.

Yeah, it is clear that when you're using your own syntax, it is not ok to ask something about it here, just because you're using not FASM, but something else

It's not an insistence that it has to be done, it's just a topic to discuss. I understand that Tomasz Grysztar will not do such dramatic change when FASM G is already here. But I'm curious if someone else had been thinking about creation high-level macros (if/else/while/switch/case/etc) which will not look like second-class citizens, but like real high level things, something like C--. Actually, I'm not using such macros now at all. But I've not tried, maybe I will like it And it is a pity that it is not possible to make such macros to look like first-class citizens without breaking compatibility with original FASM because all general names which are usually used for such constructions are reserved for built-in macro directives.

I'm somebody that usually likes prefixes for special symbols like directives, but in FASM, it appears that the general theme is to blur the lines between directives, macros, and real x86 mnemonics to create a mnemonic soup. I think that's agreeable if only for stylistic reasons.

The point of this is that in fasmg actually everything can be overridden and redefined and the line between built-in instructions and macroinstructions is blurred. This is something that was pioneered by fasm 1 to some extent, but fasmg pushed this idea almost to the extreme.