Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!portal!cup.portal.com!stephan
From: stephan@cup.portal.com (Stephen Derek Schaem)
Newsgroups: comp.sys.amiga
Subject: Re: To macro, or not to macro?  (LONG) ... a programming style.
Message-ID: <19191@cup.portal.com>
Date: 7 Jun 89 05:52:11 GMT
References: <2454@van-bc.UUCP>
Organization: The Portal System (TM)
Lines: 59


 Well, I'm here..:-)
I will try to show some point that make me fell that way about macro, It's not
 just idea but *experience*...
1) Macro more or less readable?: It's true that 'big' macro (usally over 10 
 lines of codes) dont make mutch difference over subrouitnes if they are not
directly included in the source file... Since you will have to open the macro
file or include file to take a look at them... But for 'customizing' the 
instruction set I have to disagrea! PUSH A0 will wont be self explanatory, but
move Rx,-(sp) is clear.Small macro ask you to have them all in your mind when
reading a source...
 
2) Macro used for library call: Here again I have to desagrea, my reason is
for library that dont especialy need the base to be passed in a special
 address register.And here again there is no specification for macro ussage,
so it's free to the programer and will have to take a look at the macro file
to be sure how things are done.
 
3) Macro = sub: For macro equivalent in size to a subroutine, It *should* be
include in a .library.Since it is used at least once by your software and
you also make it available for other program than yours.Every routine make
to be efecient should be excluded! I have other things to say about memory
usage but I wont enumerate them here, just that I could say that 5% to 10% of
the data from a file sit around doing nothing!People should free up their
startup code and initialization data after being used...
 
4)The point make with CLR, CLEAR, ClearData: That was a explample give for a
ONE line macro NOT subroutine! The discusion was at the time;'Why use macro
to redifine existing opcode'.I desagrea that a macro should be used instead
of moveq... moveq #0,Dx is a good way since the ALL world know what it mean!
a macro will Force you, again, to look at it and see how it is done, was the
programer 'stupid' and use CLR.L instead of moveq #0 in a loop called 65536 
 times?!

5) Optimizing code: Library call can be used to get very small 'master' code
by not repeating thing over and over (or subrouitnes).The context was not for
speed, sory if I let anybody beleived it.Sometime I use a bsr.s to jump over 
a data area in the main code section and use move.l (sp)+,Dx just because
all registers are used and I want the address in a data register.. That's for
Size optimizing.. For speed A bsr-rts can do alot, have to agrea:-)

6)Xref or no Xref? Well I dont use a linker very often And I try to keep it
that way.I have all the address offset mostly use in a file using EQU and 
all one that I never use in another.That same me some time for compiling.
But I use Xref in some cases but not for library base offset.
jsr _Examine(ax) or Call Examine <- need dosbase in a6!,
 		    LIBCALL Examine,Dosbase <-will be loaded in a6!
		    CALLDOS Examine <- Well Witch address register?!
In the 'normal' way:-) jsr _XX(ax) work ALL the time, everybody how will read
the code now it, and ther wont be ANY confusion! You you have to pass time
writing a good macro that will at the end (if you want full control) be as big
as a normal code.It's good if you use only a6, but when you have Dos or other
and have 3 library base used at the 'same' time you do extra work for 'nothing

Question a preferences?: Maybe, But I can live easy EVEN better without macro.
Could you without sub or include:-)
Well I saw to maybe people abusing macro...
 
Stephan Schaem: There isn't any toy I can't Break:-)