flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > some questions regarding macros/macroinstructions

Author
Thread Post new topic Reply to topic
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
Hi all,
I got some questions regarding some macroinstruction I don't quite understand


1.
Code:
  local param
  match =param,param {}    

Why does this actually work?
When I output param via display it says its uninitialized value is like param?Sd/Se/etc.
So they wouldn't match, would they? Or is this an exception implemented in match to make use of uninitialized locals as switches?


2. defargs@proc in proc32.inc has a part which says
Code:
   forward
     ;[...]
   common
     args@proc equ current@arg    

When you e.g. write "proc lol x,y,z", I would have said args@proc would be equal to z because current@arg gets set to every param after another in a loop, doesn't it?
But it's actually equal to x,y,z which I don't understand


3. The local-macro has the following part at its very end:
Code:
  match ,done@local
    \{ var
       restore done@local \}    

This gets executed if "match varname[count]:vartype, var" and "match :varname:vartype, done@local:var" don't match.
But I don't get its purpose, for which code is this part actually needed?



--
I also would like to suggest small modifications to the proc-/local-macro:


1. The epilogue of the proc-macro always contains "leave" even when only the "pop ebp"-part is needed.
Is it because it just doesn't matter or because "leave" looks nicer than "pop ebp"? As it actually wastes some cycles..
Not that anyone would care, I'm just wondering..


2. The proc-macro allows usage like this:
Code:
proc lol x,y:byte,z:BYTE    

The local-macro on the other hand only allows such syntax:
Code:
local x:DWORD,y:BYTE,z:BYTE    

I therefore would like to ask if it's possible to add something like:
Code:
      match :varname[count],done@local:var
         \{ varname rd count
      restore done@local \}
         
        match :varname,done@local:var
        \{ varname dd ?
          restore done@local \}    

so "local x" would work like "local x:DWORD".
I also wonder if one could exchange those "match =BYTE,...." with "if byte eq vartype" like in the defargs@proc-macro to make it case-insensitive, as writing everything lowercase and then be forced to use "local x:DWORD" kind of looks ugly


Hope you can shed some light, thank you
Post 09 Jul 2011, 18:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
1. Inside match, if "param" has no equ substitution then it is simply the literal string "param" and thus matches the other literal string "param".

2. Because of this line: "local ..arg,current@arg". current@arg is actually defined multiple times in the forward loop, and all are combined into one once we are outside the forward loop and back into the common section.

3. This line: "forward done@local equ" defines done@local as blank. The final part you quoted above is restoring done@local back to whatever the previous value was if none of the other lines above have matched and restored it.
Post 10 Jul 2011, 00:22
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
Thank you for replying,
got 1. and 2. now.
But you kind of got my third question wrong:
I can't figure out this piece of code's purpose inside of the local-macro.
For example which parameters do you have to provide to make it match?
Or, when does this "var" inside that last match generate valid code?


As for the suggested modifications, I myself find them reasonable and therefore would like them being implemented, but it'd suck if I only changed my local copy as I then had to distribute those changes as well when sharing source code
Post 12 Jul 2011, 00:16
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
If the previous two matches did nothing then the parameter "var" is simply assembled directly and the equate for done@local is released. We can't simply ignore "var", it has to either match one of the two templates or be assemble directly.
Post 12 Jul 2011, 00:41
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
But which input needs var to be assembled directly?
Sorry, I'm a bit slow-witted...
Post 12 Jul 2011, 00:52
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
Code:
proc ...
 local abc[4]:BYTE ;first match
 local def:DWORD   ;second match
 local ghi rq 4    ;last match    
Post 12 Jul 2011, 01:09
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
Ah, so the purpose of evaluating just "var" is to provide 'native' data reservation
I just didn't think of it, thank you very much Smile
Post 12 Jul 2011, 01:50
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
yoshimitsu wrote:
Ah, so the purpose of evaluating just "var" is to provide 'native' data reservation
I just didn't think of it, thank you very much Smile
It is more than just native reservation, it is also for anything unknown:
Code:
local ajlghiiergjvh #$%^& 0xghjn    
This must also generate an error to the programmer. If "var" was ignored then the programmer might never know that the entire line was ignored.
Post 12 Jul 2011, 01:57
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
Hey, just wanted to ask yet again about my suggested modifications which were altering proc's epilogue a little and making local's syntax match the one used by parameters in the proc-macro
Post 20 Jul 2011, 11:20
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
re you suggested mods:

1: If you really care about wasted cycles then you should be manually writing your own code to suit your specific requirements. Counting cycles, and other performance measurements, are very very tricky and intimately linked to the exact CPU and mobo combination you use. There is no universal way to know whether any particular code sequence is "faster" than any other because there are too many variations of hardware and they all perform differently from each other. The only reliable metric that can be used across all hardware variants is code size.

2: Seems to be a personal preference thing here. You would need to wait for Tomasz to read this and decide if it is to his liking.
Post 20 Jul 2011, 11:54
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
1. that's an argument. but on the other hand does 'leave' perform two operations therefore it's kind of questionable if there are many or even any processors which execute it faster than just 'pop ebp'

2. it's not important by any means, though, it'd provide some consistency
one could also choose by one's favour wether to use 'x', 'x:dword' or 'x:DWORD', it wouldn't harm existing code as well
Post 20 Jul 2011, 20:27
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
1. Also note downside of increased memory consumption during assembly process, for every procedure. But generally, assuming all my assumptions are correc, I'd support 'pop ebp' too Smile

2. I don't see a need for consistency between LOCAL and PROC argument. LOCAL also allows array form which proc argument doesn't, etc.
Post 20 Jul 2011, 23:18
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
I'd rather say they have the same syntax, but when using local it is a little enhanced

Code:
proc test a:dword,b:dword
  local x:DWORD,y:DWORD
  mov dword [eax],ebx
  ret
endp    
vs
Code:
proc test a:dword,b:dword
  local x:dword,y:dword
  mov dword [eax],ebx
  ret
endp    

Code:
proc test a,b
  local x:DWORD,y:DWORD
  ret
endp    
vs
Code:
proc test a,b
  local x,y
  ret
endp    

I'd say it hinders a consistent syntax
Post 21 Jul 2011, 09:58
View user's profile Send private message Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
yes/no/maybe? :/
Post 01 Aug 2011, 02:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
yoshimitsu wrote:
yes/no/maybe? :/
What was the question? You have stated your case. vid and myself have also responded with our respective thoughts. I don't see that there is much more to answer here unless you are just hoping that someone else will post that they agree with your suggestion?
Post 01 Aug 2011, 03:12
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
I know it's not important by any means and I don't want to annoy, but I was kinda hoping Tomasz would respond whether he could implement those small changes somewhen
Post 01 Aug 2011, 05:56
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. Also on YouTube, Twitter.

Website powered by rwasa.