Hi all,
I got some questions regarding some macroinstruction I don't quite understand


1.
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

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:

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:

The local-macro on the other hand only allows such syntax:

I therefore would like to ask if it's possible to add something like:

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

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.

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

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.

But which input needs var to be assembled directly?
Sorry, I'm a bit slow-witted...

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

It is more than just native reservation, it is also for anything unknown: 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.

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

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.

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

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

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.

I'd rather say they have the same syntax, but when using local it is a little enhanced

vs
vs
I'd say it hinders a consistent syntax

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?

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