fasmg macro parameters and braces

Index > Programming Language Design > fasmg macro parameters and braces

Author

Thread

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 14 Oct 2016, 05:19

I think I've seen this effect before, on other assemblers.

The problem with simple, literal copy of params, is if the param string is an expression, the result can change in the macro

Calling
MacroName 20_000_000/4

gives differing results, depending on how many braces are used inside macro.

;00 80 96 98 dd ((ParS and 0x1ff) shl 9) Incorrect
;00 80 02 00 dd (((ParS) and 0x1ff) shl 9) Correct

Looks like a 'dummy' line of
pV = ParS
will also fix this by forcing an evaluation.

Nicer is if anywhere the param is used in any expression, the braces are treated as implicit.
Not sure how easy that is to fix...

14 Oct 2016, 05:19

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20298
Location: In your JS exploiting you and your system

revolution 14 Oct 2016, 05:45

jmg wrote:

Not sure how easy that is to fix...

It is not necessarily broken. By forcing implicit brackets you also reduce potential functionality.

14 Oct 2016, 05:45

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 14 Oct 2016, 06:23

revolution wrote:

... By forcing implicit brackets you also reduce potential functionality.

Notice I said 'anywhere the param is used in any expression, the braces are treated as implicit.' - by doing that, you should not lose any functionality, but you DO remove a nasty source of bugs.

14 Oct 2016, 06:23

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20298
Location: In your JS exploiting you and your system

revolution 14 Oct 2016, 06:38

jmg wrote:

Notice I said 'anywhere the param is used in any expression, the braces are treated as implicit.' - by doing that, you should not lose any functionality ...

By doing that you will limit the potential uses. With great power comes great responsibility.

There are alternative uses where forcing implicit evaluation will make the code fail. Consider the following where "op" is forced to evaluate first:

Code:

macro something op
  db 3 op 4
end macro
something +
something -
something *

jmg wrote:

but you DO remove a nasty source of bugs.

This is only a potential source of bugs. For someone that is not familiar with text replacement in expressions this might become a problem, but only in the conceptual understanding of what will happen. C programmers deal with this all the time and they are called "macro side-effects" (or something similar) within the C community. But it will never be "fixed" because it isn't really broken as such.

14 Oct 2016, 06:38

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 14 Oct 2016, 08:46

revolution wrote:

...

There are alternative uses where forcing implicit evaluation will make the code fail. Consider the following where "op" is forced to evaluate first:
Code:
macro something op
  db 3 op 4
end macro
something +
something -
something *    

I'm not following your example, as I said "used in any expression", not "forcing implicit evaluation"

Your example would work fine, under my suggested rules.

14 Oct 2016, 08:46

Tomasz Grysztar

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

Tomasz Grysztar 14 Oct 2016, 10:30

jmg wrote:

revolution wrote:
...

There are alternative uses where forcing implicit evaluation will make the code fail. Consider the following where "op" is forced to evaluate first:
Code:
macro something op
  db 3 op 4
end macro
something +
something -
something *    
I'm not following your example, as I said "used in any expression", not "forcing implicit evaluation"

Your example would work fine, under my suggested rules.

I think there is some misunderstanding, because revolution's example is quite clearly a use of parameter in an expression (the parameter serves the role of binary operator in that expression).

Another example is the "ns" operand in x86 macros:

Code:

macro x86.parse_operand_value ns,op
        ; ...
        ns.size = (ns.imm metadata 1) metadata 1 - x86.reg
        ; ...

On the right side "ns" is used in the expression and again, adding any "hidden" brackets there would break the whole thing.

One might also argue, that if we were to add (during the expression parsing) implicit brackets around values that originated from parameters, we should also do the same for symbolic variables, since this is an analogous problem (see the example with "symbolic equ 2 + 2" in the manual). But then the tricks like the one with "define SUFF" that I proposed for your Parallax macros would no longer work.

fasm and fasmg rely on the principle of emergent language (what I once called "complex solutions with simple features") - the features of the assembler itself aim to be simple and sharply defined, so when you know in detail what each one of them does, you should be able to combine them into complex constructions in a plethora of different ways, often even some that were not envisioned initially when these features were designed.

The consequence of this principle is that anything that is not one of these simple building blocks is then implemented in form of macros and this is how the philosophy of fasmg was born.

14 Oct 2016, 10:30

< 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