Hello,

Are there plans to add a "RADIX" directive to FASM?
I like to use base 16, instead of the base 10.

However, I also sugest that FASM´s syntax be different from the other assemblers I know (TASM, MASM) in the following:
1. it should NOT do base overrides using algarisms from any base´s set. E.g., "d" for decimal base; when base 16 is used you would always have to use base overrides for hex numbers terminated with "d", killing the purpose of the radix directive.
2. the base override symbol could be configurable. Maybe its a silly suggestion, I haven´t analysed it in depth. But OTOH you could INCLUDE sources with the silly radix sintax without too much worry...

My sugestion for overrides are:
- "s" for binary. The s is from Second.
- "t" for decimal. The t from Tenth.
- octal and hexadecimal base can have the traditional "o" and "h" symbols.

See you later.

Dedec0

Why do you use all that? Why not stick to the "normal convention" or b for binary and none for decimal?

@roticv: because I like to use base 16 (and I think others might too). And in that case it don´t work or I have to keep eye open for "dangerous numbers". Because in most programs I write there are more big hexadecimal numbers than there are big decimal numbers. And because I think the "normal convention" shouldn´t be normal... And it shouldn´t be hard to implement, with with very few things to add, I think.



And IMHO FASM would be better with this.

Regards,

Dedec0

still can't comprehend what is problem with writing "h" at end of number. There will also be some problems with modules / libraries / includes / macros that use decimal numbers.

Even if it was a good idea, the backward compatibility would still be a priority - fasm is not at the early stage of development when such changes would be considered.

The main idea here is the radix directive being added, not the changes I suggested to traditional radixing, wich brake on a lot of stuff.

In this case, there is no break up with existing files, since the processing of sources will only be changed when (if) the directive is found.

Since there is not many (!) people who are fond of syntax changes in radix, lets drop it.

@vid: I don't like the H letter.

@Privalov: Can a traditional radix directive still be put in, then? =D

Kind regards,

Dedec0

Use 0x or $ and be happy

Today I spended several hours finding why &%$· reason my int13 handler hang my computer, the problem was that I accessed the address 443 instead of 443H to decrement the available base memory and using the resultant address for install the handler...

Why is a bad idea to add radix at this stage of development? I now that even with radix I can make mistakes because I can write a number in a different base and forgot to override the base but since I tipically use hex base for any number on boot codes I prefer radix before using "0x", "$" or "h".

Hope there is something that can do with this, even if it can be achieved with macros

Regards

PS: Tomasz, I solved the problem with "ends" that I had today using equates. When I finish my Int13 hooker I will post it

[edit]Even adding some "base explicit" directive to force the programmer to put the base on any number could be great too, so if I put "10" FASM will tell me "base specifier missing"[/edit]

I was not related to RADIX itself, it was about those other syntax suggestions.

As for the RADIX, I simply dislike it - it breaks the syntax highlighting.

Why radix or some "base explicit" directive breaks the syntax highlighting?

Because it should allow writing things like AB12 with hex mode (well, by the way, early fasm versions were recognizing hexadecimals written like AB12h (case-sensitive!), but then i removed support for this). Well, I see it would break more than just syntax highlighting anyway. As for "base explicit" - well, that's a different thing.

OK, so there should stay the limitation that number should start with digit, then (not counting the $-preceded numbers). But what I still dislike is changing the meaning of basic elements of language. When I look at assembly code, the simple sequence of digits is always decimal and I'm scared by the idea it would mean something different. As for "base explicit" - well, I said already, that's a different thing.

Sorry I'm a little confused, do you like "base explicit" or not?

I'd say: I don't dislike it. It perhaps would only increase unequivocality of the code. It would however have to be preprocessor's feature, and thus would affect the REPT directive... Hmmm... there are some problems from the implementation point of view, however the idea itself doesn't disturb me .

ahahahaha, OK.

About making it a preprocessor's feature, that's really needed? Since "base explicit" is an ASSEMBLER directive the programmer should know that a rept will use a decimal number by default even if "base explicit" is activated or not. Another thing needed is other directive to deactivate "base explicit", some "base implicit" or "base default" or some other without using the word "decimal" because it's not radix.

Regards