flat assembler
Message board for the users of flat assembler.

Index > Main > 'Numbers in the expression are treated as decimal'

Author
Thread Post new topic Reply to topic
fwd



Joined: 13 Feb 2012
Posts: 8
Location: Canada
fwd 13 Feb 2012, 03:19
From the FASM Manual :
Quote:
"The numbers in the expression are by default treated as a decimal, binary numbers should have the b letter attached at the end, octal number should end with o letter, hexadecimal numbers should begin with 0x characters..."


Is there some way I can get FASM to treat, (either by default, or per project), all numbers as hexadecimal numbers ?

For example, so that 'mov ecx,0000000A' loads 10d into ECX, treats '20' in 'and [edi+ebp*2+20],dl' as 32d, etc., (and doesn't complain about 'invalid name's) ?

Thanks in advance,
fwd.
Post 13 Feb 2012, 03:19
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 13 Feb 2012, 04:44
Yes. You can edit the source code so the the numbers are always interpreted as hex. It is non-standard though so if you upload code to here, or download code from here, then it will assemble differently for everyone else.
Post 13 Feb 2012, 04:44
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 13 Feb 2012, 16:47
fwd wrote:

Is there some way I can get FASM to treat, (either by default, or per project), all numbers as hexadecimal numbers ?

This is not a good idea and will not be compatible to other assemblers.
Interpreting hex values is done by one of three notations (FASM accepts all):

0Ah
0xA
$A

Try to use find&replace like ',0' with ,'0x0' or [0 with [0x0 or something similar. Maybe have to do something by hand but never heard about interpreting hex values as DEFAULT. Rolling Eyes
Post 13 Feb 2012, 16:47
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 13 Feb 2012, 16:58
OP also never stated what syntax to use to change the default hex base to decimal.

Maybe 0x<digits> now becomes decimal?
Post 13 Feb 2012, 16:58
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 13 Feb 2012, 17:16
I believe the OP is looking for the RADIX equivalent of MASM (and TASM?) in fasm. None exists, and using macros and strucs to emulate this would be really hard if not impossible.
Post 13 Feb 2012, 17:16
View user's profile Send private message Reply with quote
fwd



Joined: 13 Feb 2012
Posts: 8
Location: Canada
fwd 13 Feb 2012, 18:04
revolution wrote:
Yes. You can edit the source code so the the numbers are always interpreted as hex. It is non-standard though so if you upload code to here, or download code from here, then it will assemble differently for everyone else.
Can you point me to any examples or resources that would help me do this (in a timely manner) ?
I've looked over \SOURCE\EXPRPARS.INC to find what looks like some functions I'd need to edit (get_number -> get_hex_number, etc.), but this is the first time I've looked at any of the source.

shutdownall wrote:
fwd wrote:
Is there some way I can get FASM to treat, (either by default, or per project), all numbers as hexadecimal numbers ?
This is not a good idea and will not be compatible to other assemblers.

I'm not concerned about portability / compatibility between assemblers.

shutdownall wrote:
Try to use find&replace like ',0' with ,'0x0' or [0 with [0x0 or something similar. Maybe have to do something by hand but never heard about interpreting hex values as DEFAULT. Rolling Eyes

Finding & replacing is less feasible than editing FASM's source - less desirable, at least.

revolution wrote:
OP also never stated what syntax to use to change the default hex base to decimal.

Maybe 0x<digits> now becomes decimal?

I don't need decimal at all (if it makes the task of editing the source any easier). Razz

LocoDelAssembly wrote:
I believe the OP is looking for the RADIX equivalent of MASM (and TASM?) in fasm. None exists, and using macros and strucs to emulate this would be really hard if not impossible.

I have no idea what that is, so probably not.


Seems to me that loading numbers as hexadecimal would be less work for the assembler than having to convert from decimal to hex first.
I'll poke around the source files more, but if anyone's gone down this path before, or has more expertise than I do (everyone here), I'd appreciate any help.
Post 13 Feb 2012, 18:04
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 13 Feb 2012, 18:36
Quote:
Seems to me that loading numbers as hexadecimal would be less work for the assembler than having to convert from decimal to hex first.
It is true that hex base is easier to deal with than decimal, but I don't follow the decimal to hex part, what would be that for?

About RADIX, it allows you to specify the default base for numbers, so using RADIX 16 at the beginning of the source would do what you want (but this is not available in fasm).
Post 13 Feb 2012, 18:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 13 Feb 2012, 18:52
Hex base is awkward because of the ASCII character layout with the gap between '9' and 'A'. Decimal is simpler with the 0-9 all together and a common x10 factor for each successive digit.

However, it should matter little how much work the assembler has to do to deal with number conversion. Unless you are assembling multi-gigabyte files on a 24/7 basis, and somehow an extra 0.1% performance enhancement is both measurable and vital, then this should be the least of your thoughts.
Post 13 Feb 2012, 18:52
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 13 Feb 2012, 19:25
I'm providing the steps to modify EXPRPARS.INC but YOU MUST STILL TEST IT THOROUGHLY.

The modification I made was the following:
1. Cut from pascal_hex_number to get_oct_number (excluding the latter)
2. Pasted just above get_dec_number
3. Cut from pascal_hex_number to get_hex_number (excluding the latter)
4. Pasted just above bad_number
5. Modified "je bad_number" (from pascal_hex_number) into "jne get_hex_number"

After doing that, this code:
Code:
format pe console
include 'win32ax.inc'

  cinvoke printf, fmt, 12345, 12345
  cinvoke system, cmd
  invoke  ExitProcess, 0

fmt db "Testing default base: %u %x", 0a, 0
cmd db "pause", 0a, 0
align 4 ; Just to be safe
data import 
  library kernel32, 'kernel32.dll',\
          msvcrt,'msvcrt.dll'

  include 'api/kernel32.inc'

  import msvcrt,\
         printf, 'printf',\
         system, 'system'
end data    
Produced this output"
Code:
Testing default base: 74565 12345
Press any key to continue . . .    


revolution: I should have clarified that easier for the processor to deal with.[edit]Ah... I'm forgetting error checking and that IMUL is relatively cheaper nowadays. The one that is easier for the processor (and humans) to deal with is int to hex than int to dec...[/edit]
Post 13 Feb 2012, 19:25
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 14 Feb 2012, 16:49
fwd wrote:

I've looked over \SOURCE\EXPRPARS.INC to find what looks like some functions I'd need to edit (get_number -> get_hex_number, etc.), but this is the first time I've looked at any of the source.


Yes this should be the right place.
Just search label number_begin: and change conditional jump after checking if value ends with "h" (which is marked hex value) and make a unconditional jump of it so that FASM thinks there is a h at the end of every (decimal) value to treat it as hexadecimal. You have to increment esi due to missing character, otherwise last character / digit of number will be "cut".
By the way, the number is treated backwards from last digit to first digit in this routine.

Code:
       cmp     al,'h'
;   je      get_hex_number
        inc     esi
        jmp   get_hex_number
    



I think this is more easy than the suggested changes of Loco.
But there must be a leading zero if number starts with a character.

mov al,12 will put 12h into al
mov al,1e is valid
mov al,ff has to be replaced with mov al,0ff


Last edited by shutdownall on 14 Feb 2012, 17:24; edited 3 times in total
Post 14 Feb 2012, 16:49
View user's profile Send private message Send e-mail Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1635
Location: Toronto, Canada
AsmGuru62 14 Feb 2012, 17:18
@fwd: so, you're trying to improve the speed of your code
or the speed of the FASM compiling your code?
Post 14 Feb 2012, 17:18
View user's profile Send private message Send e-mail Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 14 Feb 2012, 18:44
shutdownall, I think your code will perform better than mine since if the number ends with b or d my modification fails to interpret the number as hex. Another modification would be removing all the decimal- and binary-related code since as far as I can see there is no chance for them to be used anymore.
Post 14 Feb 2012, 18:44
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.