News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

MultilineMacroHandler??

Started by BrWarburto, June 30, 2005, 12:17:07 PM

Previous topic - Next topic

BrWarburto

Goasm as yet does not handle multiline macros as does MASM and TASM. In discussions with Jeremy, he didn't think it was worth doing> However it might be useful to discuss amongst users.
I have put below a rough spec. for such a handler. Comments would be appreciated and if favorable, I might try and produce a beta version ??!!

BrWarbuto

                        A Macrolibrary System

Aim: To mimic the MASM and TASM macrolibrary systems

We would not use the include file directive, as this would considerably inflate the source file. Rather, we would have the macrolib source file on the same directory as the assembly process.We would then copy only the required macro from the library and nothing else.

The calling progamme would either:
      a)        define a new macro
      b)        use an existing macro

(a) A check would be made first to see if the new macro name was already in use. If so an ERROR would result. If not, the new macro text would be copied to the end of 'macrolib'. Macrolib would be a text file consisting of assembly instructions or other macronames.
Any syntax error in the macro text would cause a fault.
Macros must start: name MACRO par1 par2 par3....
and end:           ENDM
Multiline macros are allowed.

(b) If a macro is to be used, the name of the macro itself should be enough to invoke the inclusion of the macro text. Any paramters required should follow the macro name using spaces. Should the macro name used not exist an ERROR would occur.
If the macro uses parameters these would be pushed on to the stack.
Strings would be referenced by their addresses.
32-bit variables would be used exclusively. The stack must be cleaned up
on termination of the macro.
In one sense a macro is rather like a procedure, the main
difference being the fact that the macro code is written 'in line' in the
body of the programme. In this connection, it might be useful to
use a flag e.g. 'hunt/p'. This would have the effect of causing 'hunt'
to be written like a subr or proc at the end of the calling programme.
hunt/p would become 'call hunt'.
The advantage of this would be the saving of space if the macro
was used several times in a programme. On the other hand if
'hunt' were to be used alone, it would look more look a function
as used in a high level language such as C or C++.
We could allow both
hunt mouse spider fly or
hunt(mouse,spider,fly)

General Implimentation
Notes:

The driving programme would need to recognize the
macro name as something other than any existing
assembly statement, but this should not be a
problem.
It would be easy avoid confusion with 'called'
Procedures etc. as these would have their
names preceeded by call sp name.
The Macro handler would be used as a preprocessor for Goasm





donkey

The line continuation character (\) can be used for multiline macros...

CB_SetContent(hControl,pList) = push edi \
push esi \
mov esi,pList \
push esi \
C1: \
add esi,1 \
mov al,[esi] \
cmp al,0 \
jne <C1 \
add esi,1 \
push 0 \
push 143h \
push hControl \
call SendMessageA \
mov cl,[esi] \
cmp cl,0 \
je >C2 \
push esi \
jmp <C1 \
C2: \
pop esi \
pop edi


Anonymous labels are local to the macro and comments can be inserted...

TestMacro = mov eax, 10 \
; some comment \
mov eax, 100
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

BrWarburto

Thank you for pointing this out, Donkey. Clearly it would be silly to 'reinvent the wheel'. I'm sure this existing facility could enable something in the way of a library as well. I will do some experimenting and see what could done. It's good that the existing definition method will also handle parameter passing as you have demonstrated! If a library of such definitions were to be maintained by the user, it could be contrived that only those definitions required by the current programme would be extracted at assembly time. A preprocessor could easily put the required material only into a temporary inc file temp.inc and temp.inc would be automatically deleted after the job?


BrWarburto

donkey

Hi BrWarburto,

You might want to take a look at my version of VKim's debug for GoAsm, it is available on my website. It makes extensive use of macros to allow for easy debugging of applications. Including some very interesting use of conditional compilation in a macro, unicode support based on the STRINGS directive and a few of the features that Jeremy added for me (@line etc...). I am not a big fan of macros in general as I believe they tend to obfuscate code but in the case of the debug library they were very effective.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

BrWarburto

Hi Donkey!


Thanks again for this: I'll have a look.

Brwarburto