Specifications

shown at left, with the operating comparison below. We compare a prefix null to
a second null, between the two commas— but we wanted to com-
IFC ,\1 pare a null with *,S *! The solution is relatively easy. We
is seen as stuff in some periods, and compare them in place of nulls, as
IFC ,,S shown in the third set of examples. (First, we’ll compare a
leading null to the parm ',S', and then we'll test nulls.)
IFC .,\1. Note the prefix period, and the period which follows the psue-
is seen as do-variable \1. This time, our comparison is valid. We compare
IFC *»>S. the leading period with a null between the two commas. The two
are not comparable, so IFC fails as it should. Now, suppose we
truly have a null parameter for psuedo-variable \1, instead of ',S'— after all,
that was the problem we started with. And lo! Though we compare two periods, the
comparison is valid, and we pass the IFC test. Note that the
IFC .,\1. parameter which caused all this trouble is very common:',S' —
is seen as: which means the top value on the stack. We had to find a way
IFC .,. around the preceding comma, and the period is one way. Only if
(null,null) we pass a parm — which is highly unlikely— will the peri-
iod fail. If you must compare such a parm, you can change the
comparison statement to any character other than a period (if you don't other
wise use that alternate character).
Before you proceed, please look at CALL MACRO at the end of this article. I will
refer to it many times from here on. The numbers in {} are line numbers, and not
part of the macro. As written, it handles up to six parameters (the maximum you
may pass to any system routine). If you need more, expand it. Here are some ex
amples of how to use it; in them, your code is in CAPITALS and bold face, while
lower case and '+' show macro-generated code. Note how CALL MACRO first sets the
parameter count (pcount_) to zero {2}, so we can keep track
CALL PUTHL_ of how many bytes we must release from the stack after the
call. In the example left, we want a new line and pass no
+ jsr putnl_ parameters. IFNC {3} fails because we compare two nulls, so
we skip to its ENDC (33) with pcount_ still zero. The macro
generates a JSR at line {34}, and pcount_ is checked at {35}. Since pcount_ is
equal to zero (ifne), no LEAS instruction is generated to adjust the stack.
Let's try again, with a call to PUTCHAP>_ to print a space. Again, pcount_ is set
to zero; the first IFNC test is passed (we pass a parm);
CALL POTCHAR_,#' ' but note the second IFNC fails. We drop down to its cor-
+ ldd #' ' esponding ENDC {31}* and emit the LDD \1 found there; it
+ jsr putchar_ loads the #' ' that we passed (all parms to system rou
tines are passed in the D register); then emits the JSR
at {34}, and as before does not generate the LEAS instruction because pcount_ is
still zero. (If you ask why passing a parameter doesn't increment pcount_, note
that one parameter is passed in the D register, not from the stack. Only when we
pass two parameters or more is the stack involved.)
In the next call, the first two IFNC tests are passed, and pcount_ this time is
incremented. Since we passed only two parms, the third IFNC fails {6}; we drop
; P1 P2 to its ENDC {28}, emit the LDD {29}, the
CALL OPENF_,#FILENAME,#FILEMODE PSHS D {30} to put P2 on stack; then the
+ pcount_ set 2 LDD for P1 at {32}, and finally the JSR at
+ ldd #fileraode ;P2 {34}. This time, the test of pcount_ shows
+ pshs D value, and so we emit the LEAS 2,S to adj-
SuperpPET Gazette, Vol.I No.11
-159-
December 1983/January 1984