-
Notifications
You must be signed in to change notification settings - Fork 15
/
writeup_6502.itr
2132 lines (1916 loc) · 70.2 KB
/
writeup_6502.itr
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
.ds [ \s+1\z[\h'1p'\z[\h'-1p'\s-1\0
.ds ] \s+1\z]\h'-1p'\z]\s-1\0
.ds Z \s+1\z]\h'-1p'\z]\h'3p'\z*\s-1\0
.ds Da July 7, 1986
.TL
\s+6Macross 6502\s-6
\"Macross
.AU
an assembler for people who hate assembly language
by
Chip Morningstar
.AI
Lucasfilm Ltd. Games Division
\*(Da
.ds LH Macross
.ds CH \*(Da
.ds RH 6502 Version
.ds LF Lucasfilm Ltd. Proprietary Information
.ds CF - % -
.ds RF CONFIDENTIAL
.AB
This document describes the 6502 version of \fIMacross\fR, a super-duper
cross-assembler that has actually been used!
.AE
.SH
\s+3Introduction\s-3
\"Introduction
.PP
\fIMacross\fR is a generic cross assembler for a variety of different
microprocessors. This document describes the 6502 version of \fIMacross\fR.
\fIMacross\fR differs from many macro assemblers in that it provides a number
of ``higher level'' constructs not traditionally found in assembly language.
These include block-structured flow-of-control statements (\fCif\fR,
\fCwhile\fR, etc.) and the ability to define record-oriented data structures
(\fCstruct\fR). In addition, it contains a powerful macro capability that is
based on syntactic structural manipulations rather than simple text
substitution. \fIMacross\fR is, in fact, a complete block-structured
programming language in its own right which is interpreted at assembly time.
.SH
\s+3General Form of \fIMacross\fP Statements\s-3
\"General Form of \fIMacross\fP Statements
.PP
Stylistically, much of \fIMacross\fR is patterned after \fBC\fR. In
particular, the form of many keywords and of block structured entities is
derived from \fBC\fR. Unlike \fBC\fR however, \fIMacross\fR follows the
convention of more traditional assemblers that statements are delimited by
line boundaries (i.e., one statement per line, with the end of a line ending a
statement).
.PP
In general, spaces and tabs are treated as whitespace characters and are
ignored. Therefore, such characters may be used as the assembly language
programmer desires to format his or her program according to personal taste.
For the convenience of the programmer, \fIMacross\fR relaxes the syntax rule
that newlines always end a statement: newlines may also be treated as
whitespace characters (again, for purposes of formatting) in places where it
would be syntactically unambiguous to do so (i.e., where a statement obviously
cannot terminate, such as after a comma). For example:
.nf
\fCbyte 1, 2, 3, 4,
5, 6, 7, 8\fR
.fi
is allowed and is equivalent to
.nf
\fCbyte 1, 2, 3, 4, 5, 6, 7, 8
.fi
.PP
Comments begin with a semicolon (``\fC;\fR'') and continue to the end of the
line, as is common in many assemblers. In addition, \fIMacross\fR supports
\fBC\fR style comments bracketed by ``\fC/*\fR'' and ``\fC*/\fR''.
.PP
As with most assemblers, \fIMacross\fR statements are allowed to begin with a
label (or several labels, if you like). A label is denoted by an identifier
followed by a colon (``\fC:\fR''). There is no requirement that the label
start in column 1, or anything like that. Labels, if present, merely must
precede anything else in a statement.
.PP
An identifier is just what you'd expect from all your years of programming
experience: a string of letters and digits that must begin with a letter. As
is traditional in Unix*
.FS *
Unix is a footnote of Bell Laboratories.
.FE
land, the underscore character (``\fC_\fR'') is considered to be a letter
(smacks of hubris that, but tradition is tradition). Departing from Unix
tradition, upper- and lower-case characters are not distinct from each other
for purposes of distinguishing identifiers. If you use mixed case for
stylistic reasons, \fIMacross\fR will remember the case of the letters in an
identifier when it was first defined, so that symbol table dumps and
cross-reference listings will retain whatever case usage style you've adopted.
There is, in principle, no restriction imposed upon the length of identifiers.
.SH
\s+3The Language\s-3
.PP
In what follows, things in \fCthis typewriter like typeface\fR are keywords
and characters that are used literally. Things in \fIitalics\fR are other
kinds of syntactic entities. Double brackets (``\*['' and ``\*]'') enclose
things that are optional, while brackets followed by an asterisk (``*'')
enclose things that may be optionally repeated zero or more times.
.NH 1
The Instruction Statement
.PP
The most elementary \fIMacross\fR statement is the instruction statement,
wherein the programmer specifies a machine instruction to be assembled. The
instruction statement is
.nf
\*[ \fIlabel\fR \*Z \fIopcode\fR \*[ \fIoperand\fR \*[ \fC,\fR \fIoperand\fR \*Z \*]
.fi
just like every assembler ever made (except \fBa65\fR, of course).
\fIOpcode\fR is an identifier which is either a machine instruction mnemonic
(a list of which mnemonics are accepted by \fIMacross\fR is given in
\fBAppendix F\fR at the end of this document) or a macro name. For example:
.nf
\fCand foobar\fR
\fCsomeMacro foo, bar, baz, bletch\fR
.fi
.PP
The operands of an instruction may be any of the various types of operands
allowed by the various addressing modes of the target processor. In the case
of the 6502, these are:
.NH 2
\fRDirect addressing
.PP
Direct addresses take the form
.nf
\fIexpression\fR
.fi
and are used both for instructions that use direct addressing and ones that
use relative addressing (the offset is computed automatically by
\fIMacross\fR).
.NH 2
\fRIndirect addressing
.PP
Indirect addresses take the form
.nf
\fC@\fR \fIexpression\fR
.fi
Of course, the only 6502 instruction which accepts an indirectly addressed
operand is \fCjmp\fR.
.NH 2
\fRImmediate operands
.PP
Immediate operands take the form
.nf
\fC#\fR \fIexpression\fR
.fi
In the 6502, immediate mode operands are restricted to eight bit quantities.
\fIMacross\fR will give an error message if the operand value is larger than
this.
.NH 2
\fRIndexed addressing
.PP
Indexed addressing operands take the forms
.nf
\fCx\fR \fC\s-1[\s+1\fR \fIexpression\fR \fC\s-1]\s+1\fR
\fCy\fR \fC\s-1[\s+1\fR \fIexpression\fR \fC\s-1]\s+1\fR
.fi
An alternate form of indexed addressing which is supported by \fIMacross\fR
allows the symbolic selection of a field of a \fCstruct\fR pointed to by an
index register
.nf
\fCx\fR \fC.\fR \fIidentifier\fR \*[ \fC.\fR \fIidentifier\fR \*Z
\fCy\fR \fC.\fR \fIidentifier\fR \*[ \fC.\fR \fIidentifier\fR \*Z
.fi
This is explained in greater detail in the sections on \fCstruct\fRs and
expressions below.
.NH 2
\fRPre-indexed indirect addressing
.PP
Pre-indexed indirect addressing is specified by operands of the form
.nf
\fC@\fR \fCx\fR \fC\s-1[\s+1\fR \fIexpression\fR \fC\s-1]\s+1\fR
.fi
As with ordinary indexed addressing, there is a form of pre-indexed indirect
addressing which uses \fCstruct\fR fields
.nf
\fC@\fR \fCx\fR \fC.\fR \fIidentifier\fR \*[ \fC.\fR \fIidentifier\fR \*Z
.fi
.NH 2
\fRPost-indexed indirect addressing
.PP
Post-indexed indirect addressing is specified by operands of the form
.nf
\fCy\fR \fC\s-1[\s+1\fR \fC@\fR \fIexpression\fR \fC\s-1]\s+1\fR
.fi
There is no \fCstruct\fR-oriented form of post-indexed indirect addressing
since there doesn't seem to be any consistent interpretation of such a thing
that makes sense.
.NH 2
\fRRegister addressing
.PP
The only register in the 6502 which is used as an operand in its own right is
the accumulator
.nf
\fCa\fR
.fi
For the sake of completeness, so that macros may have them as operands,
\fIMacross\fR also allows either of the index registers to be used as operands
.nf
\fCx\fR
\fCy\fR
.fi
These are equivalent to
.nf
\fCx[0]\fR
\fCy[0]\fR
.fi
Note that \fCa\fR, \fCx\fR and \fCy\fR are reserved words in the \fIMacross\fR
language and so cannot be used as labels, variable names, etc. It might seem
natural to call a variable \fCx\fR but you can't. Sorry.
.NH 2
\fRText operands
.PP
For the sake of macros, text strings may also be used as operands
.nf
\fC"\fIany string you like\fC"\fR
.fi
The same conventions regarding escaped characters (using ``\fC\\\fR'') that
are followed by \fBC\fR are followed by \fIMacross\fR. These are documented
in \fBAppendix E\fR. Note that on many target machines the codes that these
escape sequences stand for are meaningless. They are provided primarily as a
convenience for writing calls to \fCprintf()\fR.
.NH 1
The Flow of Control Statements
.PP
\fIMacross\fR provides a number of statements which allow program flow of
control to be specified in a \fBC\fR-like block structured fashion. This
include a conditional execution statement (\fCif\fR) and three conditional
loop statements (\fCwhile\fR, \fCdo-while\fR and \fCdo-until\fR). These
statements assemble into the appropriate conditional branches and jumps to
realize the desired construct.
.NH 2
If\fR statement
.PP
The \fCif\fR statement has the following form
.nf
\*[ \fIlabel\fR \*Z \fCif\fR \fC(\fR \fIcondition\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \*[ \fCelseif\fR \fC(\fR \fIcondition\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \*Z \*[ \fCelse\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \*]
.fi
\fIcondition\fR is either the name of one of the target processor's hardware
condition codes such as can be tested for in a conditional branch instruction
(e.g., \fCcarry\fR, \fCoverflow\fR, etc.\(em the complete list is in
\fBAppendix B\fR) or one either of these negated using the ``logical not''
operator (``\fC!\fR'') or the name of one of the more complex conditions
which \fIMacross\fR understands (\fCgeq\fR, \fClt\fR, etc., discussed
shortly). The condition is used to determine the appropriate type of branch
instruction(s) to use. For example,
.nf
\fCif (plus) {\fR
\fIstatements-1\fR
\fC} elseif (carry) {\fR
\fIstatements-2\fR
\fC} else {\fR
\fIstatements-3\fR
\fC}\fR
.fi
expands into this (the labels are made up for illustrative purposes only):
.nf
\fCbmi temp1
\fIstatements-1
\fCjmp temp3
temp1: bcc temp2
\fIstatements-3
\fCjmp temp3
temp2: \fIstatements-3
\fCtemp3: \fIwhatever follows\fR
.fi
The keyword \fCelseif\fR may be used as shown, or specified as two separate
keywords, \fCelse if\fR, depending on the programmer's whim.
.PP
\fIMacross\fR knows about certain conditions which are more complex than those
than can be realized with single conditional branch instructions. These
conditions correspond to the results of comparison operations (such as
\fCgeq\fR \(em ``greater than or equal to'') that may require rather
complicated sequences of conditional branches to implement. These may be used
in any location where an ordinary condition may be used. One simply should
keep in mind that they can result in a non-trivial amount of code being
generated, if one is concerned about speed of execution. The complete list of
these complex conditions along with the object code that they produce is given
in \fBAppendix B\fR.
.NH 2
While\fR statement
.PP
The \fCwhile\fR statement has the following form
.nf
\*[ \fIlabel\fR \*Z \fCwhile\fR \fC(\fR \fIcondition\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
\fIcondition\fR is as described above for the \fCif\fR statement. An example
of the \fCwhile\fR statement would be
.nf
\fCwhile (!carry) {\fR
\fIstatements\fR
\fC}\fR
.fi
which would turn into
.nf
bcs temp1
\fCtemp2: \fIstatements
\fCbcc temp2
temp1: \fIwhatever follows\fR
.fi
.NH 2
Do-while\fR statement
.PP
The \fCdo-while\fR statement is similar to the \fCwhile\fR statement except
that the condition is tested at the bottom of the loop. It has the form
.nf
\*[ \fIlabel\fR \*Z \fCdo\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \fCwhile\fR \fC(\fR \fIcondition\fR \fC)\fR
.fi
For example
.nf
\fCdo {\fR
\fIstatements\fR
\fC} while (equal)\fR
.fi
which is equivalent to
.nf
\fCtemp: \fIstatements
\fCbeq temp\fR
.fi
.NH 2
Do-until\fR statement
.PP
The \fCdo-until\fR statement is the same as the \fCdo-while\fR statement
except that the sense of the condition is negated. It has the form
.nf
\*[ \fIlabel\fR \*Z \fCdo\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \fCuntil\fR \fC(\fR \fIcondition\fR \fC)\fR
.fi
For example
.nf
\fCdo {\fR
\fIstatements\fR
\fC} until (equal)\fR
.fi
which is equivalent to
.nf
\fCtemp: \fIstatements
\fCbne temp\fR
.fi
.NH 1
The Data Statements
.PP
The data statements allow the allocation of memory space and the storage of
constant data. These statements are like the ones found in most assemblers.
There are several different forms, each for a different type of data.
.NH 2
Block\fR statement
.PP
The \fCblock\fR statement allocates blocks of memory without initializing the
bytes to any particular value (actually, the loader will in all likelihood
initialize these to 0, but it is probably not really wise to rely on this).
It has the form
.nf
\*[ \fIlabel\fR \*Z \fCblock\fR \fIexpression\fR \*[ \fC,\fR \fIexpression\fR \*Z
.fi
The \fIexpression\fRs are the sizes of the blocks to reserve, expressed in
bytes.
.NH 2
Align\fR statement
.PP
The \fCalign\fR statement aligns the current location counter to an integer
multiple of some value (e.g., to align with a word boundary). It has the form
.nf
\*[ \fIlabel\fR \*Z \fCalign\fR \fIexpression\fR
.fi
The \fIexpression\fR is the multiple to which the current location counter is
to be aligned. For example,
.nf
\fCalign 2\fR
.fi
would align the current location to a word boundary, while
.nf
\fCalign 0x100\fR
.fi
would align to a page boundary.
.NH 2
Constrain\fR statement
.PP
The \fCconstrain\fR statement provides a means of constraining a portion of
code or data to be located within a region of memory bounded by addresses of
integer multiples of some value (e.g., within a page). Its form is
.nf
\fCconstrain\fR \fC(\fR \fIboundary\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
\fIBoundary\fR may be any expression which evaluates to a number. The
\fIstatement\fRs are assembled normally. If assembling in absolute mode, an
error message is issued if the current location counter crosses an integer
multiple of \fIboundary\fR. If assembling in relocatable mode, information
about the constraint will be output in the object file and the contents of the
constrained block will be relocated as needed to satisfy the constraint (note
that this means that it is unsafe to assume that the things in the assembly
source immediately before the \fCconstrain\fR statement, the contents of the
constrain block itself, and the things in the assembly source immediately
after the \fCconstrain\fR statement will be located in contiguous locations in
the eventual target machine address space). For example,
.nf
\fCconstrain (0x100) {\fR
\fIstatements\fR
\fC}\fR
.fi
constrains the given statements to all fit within a page.
.NH 2
Word\fR statement
.PP
The \fCword\fR statement allocates words, i.e., two byte chunks, of memory.
It takes the form
.nf
\*[ \fIlabel\fR \*Z \fCword\fR \fIexpression\fR \*[ \fC,\fR \fIexpression\fR \*Z
.fi
The \fIexpression\fRs must evaluate to quantities that can be contained in 16
bits, of course. For example,
.nf
\fCword 0x1234, foobar\fR
.fi
would allocate two words, the first of which would be initialized to the
hexadecimal value \fC0x1234\fR and the second to whatever the value of
\fCfoobar\fR is.
.NH 2
Dbyte\fR statement
.PP
The \fCdbyte\fR statement is just like the \fCword\fR statement, except that
the word is byte-swapped in memory. Its form is
.nf
\*[ \fIlabel\fR \*Z \fCdbyte\fR \fIexpression\fR \*[ \fC,\fR \fIexpression\fR \*Z
.fi
.NH 2
Long\fR statement
.PP
The \fClong\fR statement allocates longwords, i.e., four byte chunks, of
memory. It takes the form
.nf
\*[ \fIlabel\fR \*Z \fClong\fR \fIexpression\fR \*[ \fC,\fR \fIexpression\fR \*Z
.fi
The \fIexpression\fRs must evaluate to quantities that can be contained in 32
bits, of course. For example,
.nf
\fClong 0x12345678, foobar\fR
.fi
would allocate two longwords, the first of which would be initialized to the
hexadecimal value \fC0x12345678\fR and the second to whatever the value of
\fCfoobar\fR is.
.NH 2
Byte\fR statement
.PP
The \fCbyte\fR statement is similar to the \fCword\fR and \fCdbyte\fR
statements, except that it allocates single byte chunks. Its form is
.nf
\*[ \fIlabel\fR \*Z \fCbyte\fR \fIexpression\fR \*[ \fC,\fR \fIexpression\fR \*Z
.fi
An \fIexpression\fR, in this case, is either an ordinary expression (see
\fBExpressions\fR, below) which must evaluate to an 8-bit quantity, indicating
the value for a single byte to be reserved, or a string (see above, under the
discussion of text operands), indicating that the characters in the string
should be placed in memory at the current location.
.NH 2
String\fR statement
.PP
The \fCstring\fR statement is much like the \fCbyte\fR statement, except that
the values indicated are followed in memory by a zero byte. This enables the
convenient declaration and allocation of NULL terminated character strings.
This feature is of little use in the 6502 version of \fIMacross\fR but is
provided for compatability with future versions targeted at more sophisticated
processors. The form of the \fCstring\fR statement is
.nf
\*[ \fIlabel\fR \*Z \fCstring\fR \fIexpression\fR \*[ \fC,\fR \fIexpression\fR \*Z
.fi
.NH 2
Struct\fR statement
.PP
The \fCstruct\fR statement enables the declaration and allocation of
record-oriented data structures. There are two forms of the \fCstruct\fR
statement, the first of which declares a \fCstruct\fR record type, and the
second of which causes space to be set aside in memory for a \fCstruct\fR that
has already been declared. The form of the first type of \fCstruct\fR
statement is
.nf
\*[ \fIlabel\fR \*Z \fCstruct\fR \fC{\fR
\*[ \fIdataStatement\fR \*Z
\fC}\fR \fIname\fR
.fi
\fIdataStatement\fRs are any of the data statements described in this section
(section 3). \fIName\fR becomes the name of the \fCstruct\fR. Any labels
inside the \fCstruct\fR become \fIfields\fR of the data structure which may be
referred to later in expressions using the ``\fC.\fR'' operator, as in
\fBC\fR. A more complete description of the semantics of \fCstruct\fRs is
given in the section below on expressions.
.PP
The first form of the \fCstruct\fR statement, called a ``\fCstruct\fR
definition'', lays out the constituent parts of a data structure and gives
those names to those parts. The second form of the \fCstruct\fR statement,
called a ``\fCstruct\fR instantiation'',
.nf
\*[ \fIlabel\fR \*Z \fCstruct\fR \fIname\fR
.fi
causes storage for the \fCstruct\fR named by \fIname\fR to be allocated. A
\fCstruct\fR definition \fImay not\fR contain another \fCstruct\fR definition,
but it \fImay\fR contain a \fCstruct\fR instantiation. For example,
.nf
\fCstruct {
pointer: block 2
class: block 1
} fooThing\fR
.fi
would create a \fCstruct\fR called \fCfooThing\fR. Then,
.nf
\fCfooLabel: struct fooThing\fR
.fi
would allocate one at the current location at the address labeled
\fCfooLabel\fR. This could then be used as follows:
.nf
\fCand fooLabel.class
jmp @fooLabel.pointer\fR
.fi
which would AND the accumulator with the \fCclass\fR field of the \fCstruct\fR
and then jump to wherever the \fCpointer\fR field pointed to. If the \fCx\fR
index register already contained the address of this \fCstruct\fR, then one
could say
.nf
\fCand x.class\fR
.fi
.NH 1
The Symbol Definition Statements
.PP
The various symbol definition statements allow the declaration of symbolic
variables and values and the definition of macros and functions.
.NH 2
Define\fR statement
.PP
The \fCdefine\fR statement enables the programmer to create symbolic names for
values. It has two forms. The first
.nf
\fCdefine\fR \fIsymbolname\fR
.fi
creates a new symbol, \fIsymbolname\fR (an identifier), and gives it the
special value \fCunassigned\fR. Any attempt to take the value of an
unassigned symbol will cause an error message from the assembler. The symbol
will, however, cause the \fCisDefined()\fR built-in function (see
\fBExpressions\fR, below) to return \fCTRUE\fR if passed as an argument. It
is also an error to \fCdefine\fR a symbol that has already been \fCdefine\fRd.
.PP
The second form of the \fCdefine\fR statement
.nf
\fCdefine\fR \fIsymbolname\fR \fC=\fR \fIexpression\fR
.fi
creates the symbol and gives it the value obtained by evaluating
\fIexpression\fR (see \fBExpressions\fR, below). Actually, what \fCdefine\fR
does is create a symbolic name for \fIexpression\fR and the save this
expression away in a secret place. This means that symbols in
\fIexpression\fR may be forward references, e.g., labels that haven't been
encountered yet. It is also possible to forward reference to symbols that are
defined by future \fCdefine\fR statements, for example:
.nf
\fCdefine foo = bar + 2
define bar = 47\fR
.fi
effectively defines \fCfoo\fR to be \fC49\fR. Beware, however, as there is no
way for the assembler to detect mutually recursive references of this sort, so
that
.nf
\fCdefine foo = bar + 2
define bar = foo + 2\fR
.fi
will be happily swallowed without complaint, until you actually try to use
\fCfoo\fR or \fCbar\fR in an instruction, whereupon \fIMacross\fR's expression
evaluator will go into infinite recursion until it runs out of stack space and
crashes the assembler (it looks to see what \fCfoo\fR is and sees that it's
\fCbar + 2\fR, so it looks to see what \fCbar\fR and see that it's \fCfoo +
2\fR, so it looks to see what \fCfoo\fR is... To have the assembler detect
and signal this error would, in the general case, add much complication and
inefficiency (read: make your programs assemble a lot more slowly) for little
return).
.PP
The scope of symbols defined in either of these two ways extends in time from
the definition itself to the end of the assembly.
.NH 2
Variable\fR statement
.PP
The \fCvariable\fR statement enables the programmer to declare symbolic
variables for future use. Similar to the \fCdefine\fR statement, it has two
forms. The first
.nf
\fCvariable\fR \fIsymbolname\fR
.fi
creates a variable named \fIsymbolname\fR and gives it the special value
\fCunassigned\fR, just like the analogous \fCdefine\fR statement.
.PP
The second form of the \fCvariable\fR statement
.nf
\fCvariable \fIsymbolname\fR \fC=\fR \fIexpression\fR
.fi
creates the variable and gives it the value obtained by evaluating
\fIexpression\fR. The scope of variables defined in either of these two ways
extends from the \fCvariable\fR statement itself to the end of the assembly
(i.e., the variable is global).
.PP
The difference between the \fCdefine\fR statement and the \fCvariable\fR
statement is that the \fCdefine\fR statement creates what is in essence a
constant whereas the \fCvariable\fR statement creates a true variable. The
value of a variable may change (e.g., it may be assigned to) during the course
of assembly. In addition, the expression which establishes a symbol's value
in a \fCdefine\fR statement may contain forward references (i.e., labels whose
values are unknown because they haven't been encountered yet) whereas the
expression assigning an initial value to a variable must be made up of terms
all of whose values are known at the time the \fCvariable\fR statement is
encountered in the assembly.
.PP
A variable may also be declared as an array, using the form
.nf
\fCvariable \fIsymbolname \fC[ \fIlength \fC]\fR
.fi
where \fIlength\fP is an expression that indicates the number of elements the
array is to have. \fIMacross\fR arrays are zero-based, so the elements are
indexed from 0 to \fIlength\fP-1. As with ordinary variables, the elements of
the array may be initialized in the \fCvariable\fR statement using a statement
of the form
.nf
\fCvariable \fIsymbolname \fC[ \fIlength \fC] = \fIexpression
\fR\*[ \fC, \fIexpression \fR\*Z
.fi
The \fIexpression\fPs are assigned sequentially into the elements of the
array. If the array length is greater than the number of \fIexpression\fPs
given, the remaining elements are filled with zeroes. Of course, you should
not specify more than \fIlength\fP expressions or the assembler will complain
at you.
.NH 2
Macro\fR statement
.PP
The \fCmacro\fR statement is used to define macros (surprise!). Its syntax is
.nf
\fCmacro\fR \fImacroname\fR \*[ \fIargumentname\fR \*[ \fC,\fR \fIargumentname\fR \*Z \*] \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
where \fImacroname\fR is just that and the \fIargumentname\fRs are identifiers
corresponding to the formal parameters of the macro (in the classical
fashion). When the macro is called, the call arguments are bound to these
symbols and then \fIMacross\fR assembles the \fIstatement\fRs which form the
macro body. The scope of these symbols is limited to the inside of the macro
body and their values go away when the macro expansion is completed. The
\fIstatement\fRs may be any valid \fIMacross\fR statements except for
\fCmacro\fR statements and \fCfunction\fR statements (i.e., macro and function
definitions may not be nested).
.PP
Statement labels used inside macros can be made local to the macro by
preceding the label identifier with a dollar sign (``\fC$\fR''). For
example,
.nf
\fCmacro fooMac arg {
jmp $foo
word arg
$foo: nop
}\fR
.fi
defines a macro named \fCfooMac\fR that emits a word of data that gets jumped
over. The label \fC$foo\fR is local to the macro: both the reference to it
in the first line of the macro and its definition on the third will only be
seen inside the macro. Each time the macro is called, the \fCjmp\fR will
refer to the location two instructions ahead, and any other macros that might
contain \fC$foo\fR will not affect this nor will they be affected by this.
.PP
It is possible to define macros which take a variable number of arguments.
This is accomplished by following the last argument in the \fCmacro\fP
statement by \fC[ ]\fR. This declares the argument to be an array, which gets
assigned a list of all of the parameters not accounted for by the other
declared arguments. This array may be interrogated with the
\fCarrayLength()\fR built-in function (to find out how many extra parameters
there were) and accessed just like a regular array. For example,
.nf
\fCmacro enfoon precision, args[] {
mvariable len = arrayLength(args)
mvariable i
word precision
mfor (i=0, i<len, ++i) {
byte args[i]
}
}\fR
.fi
declares the macro \fCenfoon\fP that takes one or more parameters. The first
parameter is bound to \fCprecision\fP, while the remainder are collected in an
array that is bound to \fCargs\fP. It emits the first parameter as a word
value and the remaining parameters as bytes.
.NH 2
Function\fR statement
.PP
The \fCfunction\fR statement is used to define functions. Its syntax is
.nf
\fCfunction\fR \fIfuncname\fR \fC(\fR \*[ \fIargumentname\fR \*[ \fC,\fR \fIargumentname\fR \*Z \*] \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
where \fIfuncname\fR is the name of the function and the \fIargumentname\fRs
are identifiers corresponding to the formal parameters of the function. When
the function is called, the call arguments are evaluated and then bound to
these symbols and then \fIMacross\fR assembles the \fIstatement\fRs which form
the function body. The scope of these symbols is limited to the inside of the
function body and their values go away when the function evaluation is
completed. As with macro definitions, the \fIstatement\fRs may be any valid
\fIMacross\fR statements except for the \fCmacro\fR and \fCfunction\fR
statements. A function may return a value using the \fCfreturn\fR statement,
which is described below.
.PP
Just as you can define macros that take variable numbers of arguments, so too
can you define functions. The mechanism is the same. For example
.nf
\fCfunction sum(args[]) {
mvariable len = arrayLength(args)
mvariable i
mvariable result = 0
mfor (i=0, i<len, ++i) {
result += args[i]
}
freturn(result);
}\fR
.fi
which simply returns the sum of its arguments.
.NH 2
Undefine\fR statement
.PP
The \fCundefine\fR statement allows symbol and macro definitions to be removed
from \fIMacross\fR' symbol table. It takes the form
.nf
\fCundefine\fR \fIsymbolname\fR \*[ \fC,\fR \fIsymbolname\fR \*Z
.fi
The named symbols go away as if they never were \(em they are free to be
defined again and the \fCisDefined()\fR built-in function will return
\fCFALSE\fR if passed one of them as an argument.
.NH 1
Macro Body Statements
.PP
\fIMacross\fR provides several statements which are primarily intended to
manage the flow of control (or, rather, the ``flow of assembly'') within a
macro or function definition. Some of these statements are analogs to the
flow of control statements described above in section 2. However, one should
keep in mind that these statements are executed interpretively at assembly
time, whereas the previously described statements result in machine code in
the target-processor-executable output of the assembly process.
.PP
Although these statements are intended primarily for use within macros and
functions, their use is not restricted and they may be used at any point in a
program. In particular, the \fCmif\fR statement (to be described shortly) is
the means by which conditional assembly may be realized.
.NH 2
\fRBlocks
.PP
The construct
.nf
\fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
is called a \fIblock\fR and is in fact a valid \fIMacross\fR statement type in
its own right. Blocks are used extensively in \fIMacross\fR to form the
bodies of flow-of-control statements, flow-of-assembly statements and macros.
.NH 2
Mdefine\fR statement
.PP
The \fCmdefine\fR statement
.nf
\fCmdefine\fR \fIsymbolname\fR
or
\fCmdefine\fR \fIsymbolname\fR \fC=\fR \fIexpression\fR
.fi
operates like (and is syntactically congruent with) the \fCdefine\fR
statement, except that the scope of the symbol definition is restricted to the
body block of the macro or function in which the \fCmdefine\fR appears. The
symbol definition is invisible outside that block, though it \fIis\fR visible
inside any blocks that may themselves be contained within the macro or
function.
.NH 2
Mvariable\fR statement
.PP
The \fCmvariable\fR statement
.nf
\fCmvariable\fR \fIsymbolname\fR
or
\fCmvariable\fR \fIsymbolname\fR \fC=\fR \fIexpression\fR
.fi
bears exactly the same relationship to the \fCvariable\fR statement that the
\fCmdefine\fR statement does to the \fCdefine\fR statement. It declares a
variable whose scope is limited to the function or macro in whose definition
it appears.
.NH 2
Mif\fR statement
.PP
The \fCmif\fR statement conditionally assembles the statements contained in
the block following it:
.nf
\fCmif\fR \fC(\fR \fIcondition\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \*[ \fCmelseif\fR \fC(\fR \fIcondition\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \*Z \*[ \fCmelse\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \*]
.fi
unlike the \fCif\fR statement, the \fIcondition\fR may be any expression
whatsoever. \fIMacross\fR follows the \fBC\fR convention that the value 0
represents \fCFALSE\fR and any other value represents \fCTRUE\fR (in fact, the
symbols \fCTRUE\fR and \fCFALSE\fR are ``predefined'' by the assembler to
have the values 1 and 0 respectively). The meaning of the \fCmif\fR construct
is the obvious one, but keep in mind that it is interpreted at assembly time
and has no direct bearing on the execution of the resulting assembled program.
.NH 2
Mwhile\fR statement
.PP
The \fCmwhile\fR statement repetitively assembles a block of statements so
long as a given condition remains true. Its form is
.nf
\fCmwhile\fR \fC(\fR \fIcondition\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
As with \fCmif\fR, the \fIcondition\fR may be any valid \fIMacross\fR
expression and the interpretation is what it seems.
.NH 2
Mdo-while\fR statement
.PP
The \fCmdo-while\fR statement provides an alternative to the \fCmwhile\fR
statement by testing at the bottom of the loop instead of at the top. Its
form is
.nf
\fCmdo\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \fCwhile\fR \fC(\fR \fIcondition\fR \fC)\fR
.fi
.NH 2
Mdo-until\fR statement
.PP
The \fCmdo-until\fR statement is the same as the \fCmdo-while\fR statement
except that the sense of the condition is negated. It has the form
.nf
\fCmdo\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR \fCuntil\fR \fC(\fR \fIcondition\fR \fC)\fR
.fi
.NH 2
Mfor\fR statement
.PP
The \fCmfor\fR statement provides a more general looping construct analogous
to the \fBC\fR \fCfor\fR loop. Its form is
.nf
\fCmfor\fR \fC(\fR \fIexpression-1\fR \fC,\fR \fIexpression-2\fR \fC,\fR \fIexpression-3\fR \fC)\fR \fC{\fR
\*[ \fIstatement\fR \*Z
\fC}\fR
.fi
where \fIexpression-1\fR is an initialization expression, \fIexpression-2\fR
is a test to see if looping should continue, and \fIexpression-3\fR is
executed at the bottom of the loop to set up for the next time around, just as
in \fBC\fR. Note that, unlike \fBC\fR, the \fIexpression\fRs are separated by
commas, not semicolons. This is because semicolons are used to delimit line
comments.
.PP
The \fCmfor\fR statement is equivalent to
.nf