Macros !!!!!

[traumatic]

S.M.:
Thanks! I know how fasm-macros work, my question was pointing into
DoubleDutch's direction. Is it possible to use macro params as variables
for PB-functions?
I guess not... ...and that's why we still need "real" macros for PB.

Anyway, thank you for sharing your examples!

[Froggerprogger]

@all
- you shouldn't use 'test' as a name for the macro, because TEST is a keyword in FASM

Code: Select all

!macro bla
!{
  MessageRequester("test","hello")
!}
!bla
!bla

- the difference between macros and procedures is, that the body of a macro is filled in to each position, where it is called. This speeds up, because no procedure-call is made, but blows up your code, if you call a big macro at many different places.

- you can use parameters (S.M. already showed it), but it's a bit 'unhandy' unless implemented in PB. :

Code: Select all

Global a.l, b.f

!macro my_macro op1, op2
!{
  !MOV [v_a], op1
  !MOV [v_b], op2
  Debug a
  Debug b
!}

c = 999
!MOV eax, [v_c]
!my_macro eax, 1.238

Another way uses the stack:

Code: Select all

Global tempL1.l, tempL2.l, tempL3.l
!macro my_macro2
!{
  !POP [v_tempL1]
  !POP [v_tempL2]
  !POP [v_tempL3]
  tempL1 = tempL1 + tempL2 + tempL3
  !PUSH [v_tempL1]
!}

param1 = 1
param2 = 2
param3 = 3
result = 0

!PUSH [v_param1]
!PUSH [v_param2]
!PUSH [v_param3]
!my_macro2
!POP [v_result]
Debug result

@traumatic
I don't know a way to use the macro-parameters directly in the macro's body outside an ASM-line. We'll always have to wrap the values to a variable before.

=> Macros would be very nice to have, and I think this could't be too complicated because FASM does the main job anyway. Perhaps PB 4.0

[traumatic]

@traumatic
I don't know a way to use the macro-parameters directly in the macro's body outside an ASM-line. We'll always have to wrap the values to a variable before.

Thank you. MOVing or PUSHing params... Well...
So better wait for built-in macro support but hey, that's no news

[PB]

> the difference between macros and procedures is, that the body of a
> macro is filled in to each position, where it is called

Yep. This can be handy when using the same command over and over.
For example, my apps use MessageBeep_(#MB_ICONASTERISK) a lot,
to play a chime to the user. But as you can see, that's a lot of typing!
I can now do it like this, without having to use a procedure which would
be slower and pointless:

Code: Select all

!macro Chime
!{
  MessageBeep_(#MB_ICONASTERISK)
!}

!Chime

[thefool]

Macros are the same as if you putted your code at the place.

So everytime in a loop a procedure is called it needs to be CALLED and everytime a macro is in a loop, the REAL code is there so it doesnt need to call anything.

at compile time the code gets at the macro place for REAL. Also if you use the macro more than one time the whole macro code is putted at the place at compile time.


conclusion:
You have something you use over and over that needs to be _fast_ then use macros, if you have something wich you also use but doesnt really need that much speed, and you want to save the space instead [procedures wont need that much space as you call the ADDRESS of the procedure] use that. There are some plusses and minuses for the both. Also procedures have an adress place so you can manipulate etc, wich you need sometimes.

[Psychophanta]

If a Guru says its Fantastic and a Wizard says its Orgasmic then why am I still an Apprentice? hehe

-Anthony

I came too late, but of course I'm agree with FroggerProgger

[Droopy]

doesn't work with Japbe !

[thefool]

works here...
remember he made a little mistake, the !test should be ! test

try this:

Code: Select all

!macro test
!{
  MessageRequester("test","hello")
!}


! test
! test 

also try using another name than test as its a normal command...

Code: Select all

!macro yipii
!{
  MessageRequester("test","hello")
!}


! yipii
! yipii

[npath]

@leo1991,

Thanks for the speed test code. I couldn't resist some statistical testing.

I created an executable using your code and ran it 5 times (AMD Duron, 997 MHz, 512 MB RAM):

RESULTS

Data reported as mean +/- 1 standard error.

Macro: 7246 +/- 7 milliseconds

Procedure: 8364 +/- 63 milliseconds

P value = 0.01 (Mann-Whitney W test)

CONCLUSION

The macro is faster and has less variation in execution time. The procedure (on my machine) requires approximately 16% more time to run.

Npath

[Psychophanta]

npath,
That fact is due to the "wasted" time for PUSHes, CALL, POPs and RET used in procedure calls.
Using macros you save the use of that commands, that's the difference.
FroggerProgger explained in his 2nd point:

- the difference between macros and procedures is, that the body of a macro is filled in to each position, where it is called. This speeds up, because no procedure-call is made, but blows up your code, if you call a big macro at many different places.

[dagcrack]

maybe !bla doesnt work in jaPBe but ! bla does.
Maybe its an ide limitation / bug ?

ill test in the official ide.

Yup works fine in both ways at there.


by the way messenger is down ??

[Droopy]

works great now with the new code

[FloHimself]

macros in PB? im using this at least since: viewtopic.php?t=12451&highlight=macro

[DoubleDutch]

It should give a greater speed up with code that does not have any jumps of any kind. This is because the cache may not be cleared. This is not apparent in my example because it calls an operating system routine - but this was just a quick example.

I'm glad that some of you liked the idea, it just opens up the other possibilities of what else you can do because of the direct access to the underlying assembler.

-Anthony

[jack]

here's a tutorial on fasm macros http://decard.net/?body=tajga&chapter=preproc