bug in 'if' macro?

Index > Macroinstructions > bug in 'if' macro?

Author

Thread

quiveror

Joined: 20 Jun 2003
Posts: 34

quiveror

The following expressions don't seem to be correctly generated (as now for 1.66). Please try them out.
1. ~ax & bx
2. ~(ax | bx)
3. ax&bx | cx&dx

cheers,

16 May 2006, 17:56

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland

Tomasz Grysztar

One quick fix info before I update the package:

Code:

; Fixed fragment of IF.INC
      match (,symb
      \\\{
          parsed equ parsed neg@cond,<
          define nest@cond +
          define symb@cond
          define neg@cond ; <- INSERTED LINE
      \\\}
      match any,symb@cond
      \\\{
          parsed equ parsed neg@cond,symb@cond
          define status@cond +
          define neg@cond ; <- INSERTED LINE
      \\\}

PS. The macros are not versioned like fasm's core is. The fasmw package may get updated without any change to the core (also editor is versioned independently, the macros are currently versioned only by date).

16 May 2006, 18:15

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid

can you give examples of cases where it doesn't work?

16 May 2006, 18:22

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland

Tomasz Grysztar

As for the "ax&bx | cx&dx", note that in fasm (I mean the regular IF), the & and | operators have exactly the same precedence, so they are executed simply from left to right (just like multiplication and division, or addition and substraction). Those macros reproduce the same behavior here, too. Thus

Code:

.if ax & bx | cx & dx

is equivalent to:

Code:

.if  ( (ax & bx) | cx ) & dx

and generated code is correct in this case.

16 May 2006, 18:28

quiveror

Joined: 20 Jun 2003
Posts: 34

quiveror

IMHO, the & should have higher precedence than |. This would be great because it would conform to the C language (and many others) defacto standard and a bit easier for newcomers to get used to fasm too.

Anyway, I've been using fasm for quite a while but never notice this. The fact surprises me indeed Shocked

17 May 2006, 10:45

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland

Tomasz Grysztar

I made it this way because for my own understanding it's more natural than the "defacto standard". You should anyway always use square brackets if you're not sure how it would be interpreted.

17 May 2006, 13:28

Aster!x

Joined: 16 Jul 2004
Posts: 26

Aster!x

But if there are no brackets the interpreter should follow the C standard, i think

22 May 2006, 08:08

okasvi

Joined: 18 Aug 2005
Posts: 382
Location: Finland

okasvi

why should assembler follow C standard? Confused

and anyway it's just a macro, anyone not liking it can make a new one |:

22 May 2006, 08:10

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland

Tomasz Grysztar

It's just a macro, but it reproduces the same operators precedence that fasm uses internally (for assembler-processed IF conditions).

22 May 2006, 09:36

< 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