Bug: operator precedence

Index > Compiler Internals > Bug: operator precedence

Author

Thread

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 21 Jan 2012, 12:48

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

21 Jan 2012, 12:48

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Jan 2012, 15:27

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.

21 Jan 2012, 15:27

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 21 Jan 2012, 15:52

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

21 Jan 2012, 15:52

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 21 Jan 2012, 17:45

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

21 Jan 2012, 17:45

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Jan 2012, 19:26

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.

21 Jan 2012, 19:26

< 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