On Mon, 16 Feb 2009, Lee Jones wrote:

> old DEC Macro-10 assembler (on TOPS-10/TOPS-20 OS) thread...
> 
> I know exactly what BillW is getting at.  Been there, done
> that, still have the manuals, and may have the source code.
> 
> >>> (This lets you write code like:
> >>>       cpi R15, 'A'
> >>>       %IF E
> >>>         ; code
> >>>       %ELSE
> >>>         ; more code
> >>>       %ENDIF
> >>>
> >>> Which is convenient.  Has anyone managed to do that sort of thing  
> >>> with PIC or AVR assemblers? (without a separate pre-processor.))
> 
> >> Yes, of course! You can define global or local variables in MPASM,  
> >> you can calculate with those, check their values and use them in
> >> ASM lines of conditional directives including IF and WHILE.
> 
> > I think your missing that this is NOT compile-time IF or similar.
> > The above should assemble to something like:
> >
> >         cpi R15, 'A'
> >         bne BEG023
> >            ;; code
> >         br  END023
> >     BEG023:
> >            ;; more code
> >     END023:
> 
> Macro-10 had impressive, generalized string manipulation that
> allowed you to use the value of a symbol to create a string.
> That string could then be used as a label (i.e. branch target).
> 
> It allowed building structured programming constructs, such as
> IF - THEN - ELSE - ENDIF, using macros inside assembler programs.
> For example, define a macro called IF which did a comparision &
> branched to a label.  Define a second macro called THEN which
> created the label used by the IF.  Define a third macro called
> ELSE which defined a different label (alternate target for IF).
> And a fourth macro for ENDIF which defined a label to be used
> as the branch target.
> 
> It's easy to build if you only want to use one IF - THEN etc
> contruct in the entire program.  Mostly you want to be able to
> have multiple IF - THEN blocks so each macro invocation has to
> create new labels which are kept track of by numeric symbols.
> The symbols & generated labels were only for the use of the
> macros, so human readability did not matter.  (Same thing a
> compiler does with internal jump points.)
> 
> A tricky part was keeping track of the symbols/labels so that
> you could nest the IF statements.

XCASM has a '.if_rt' directive that does all the above for you. It can be 
nested and works with complex expressions.

e.g.

	; this generates runtime code

	.if_rt	(fred * 3) > bert

	... "true" block of assembly code

	.else

	... "false" block of assembly code

	.endif

Also if the conditional expression equates to the constant NOT 0 then only 
the "true" block of assembly code is included in the runtime executable 
(the "false" block being excluded). If the conditional equates to the 
constant 0 then only the "false" block of assembly code is included in the 
runtime executable (the "true" block being excluded). If the conditional 
expression does NOT equates to a constant then runtime code is generated 
to evaluate the expression at runtime.

In this way the assembler can actually produce optimised code which is 
dependent on the actual address of a symbol determined at assembly time 
(which is equivalent to link time in other systems because of the way the 
XCASM works). This is not possible with a pre-processor.

Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist