flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Bug: operator precedence

Author
Thread Post new topic Reply to topic
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
In the documentation of FASM is a operator precedence announced, 1.2.4 numerical expressions. + and - have higher priority (0) before mod (2). Anyway this calculation is interpreted wrong, as I found in some listing. Please don't ask about sense of this calculation, source code is not from me and happens to my Z80 version but same behaviour in FASM (x86) version 1.69.35

Code:
format binary as "p"

        org 0h
        mov al,labelx+1 mod 100h

        org 1adfh
labelx:
        db 0
        ; some more code  
    


The above code throws "value out of range".
If i put labelx+1 in () then the code works.
Seems that 1 mod 100h is calculated first which shouldn't be.

I can workaround but maybe this can/should be solved in the next release. Wink

This works as it should without ()

Code:
format binary as "p"

        org 0h
        mov al,(labelx+1) mod 100h

        org 1adfh
labelx:
        db 0
        ; some more code  
    
Post 21 Jan 2012, 12:48
View user's profile Send private message Send e-mail Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I think the documentation is wrong, those + and - must be referring to the unary operators which of course must be executed with the maximum priority, but the binary forms are not listed.
Post 21 Jan 2012, 15:27
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
In my opinion it is not a bug. The precedence of mod should be the same as the precedence of division. For example, the expression 2+2/2 = 3 but (2+2)/2 = 2
Post 21 Jan 2012, 15:52
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
JohnFound wrote:
In my opinion it is not a bug. The precedence of mod should be the same as the precedence of division. For example, the expression 2+2/2 = 3 but (2+2)/2 = 2


Maybe you are right. Is difficult to understand. Can read the table in the document as 1. priority, 2.priority - or - higher priority and lower priority. Maybe I understood this wrong.

I just found some source code for Z80 maybe written for other compiler which has other "priorities". Rolling Eyes
Post 21 Jan 2012, 17:45
View user's profile Send private message Send e-mail Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Oh, haven't understood the following part right the first time:
Quote:
The operations with higher priority value will be calculated first, you can of course change this behavior by putting some parts of expression into parenthesis.
So since there is no bug in the documentation I've unstuck the thread.
Post 21 Jan 2012, 19:26
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-2020, Tomasz Grysztar.

Powered by rwasa.