Re: 8051 assembler in Common Lisp


Peter Seibel <peter@xxxxxxxxxxxxxxx> writes:
> Greg Menke <gregm-xyzpdq@xxxxxxxxxxxx> writes:

> So if you look at my other post where I included the implementation of
> DEFTEXT and GETTEXT, you'll see that DEFTEXT works in several
> passes. It may be that you want to store the result of one of earlier
> passes, before symbols have been resolved. Then you can stitch
> together a bunch of bits of code defined with different DEFTEXT's and
> DEFBSS's and so forth and then do the final resolution of symbols to
> addresses.

Thats pretty much what I'm doing. Or its pretty much what I think I'm
doing. Or something.


>
> Anyway, if you can annotate this test code a brief comment about what
> each form does, that'd help me understand what's goin on.
>
> >
> > (defproject testproj
> > (:text-base #x100
> > :data-base nil
> > :text-align 16
> > :data-align 8))

Set overall code & data origin and linked symbol alignment policy. As
given, data symbols will be located by default after all the code
symbols since there is no :data-base defined. Each text symbol starts
on a 16 byte boundary, etc. (I've since added :bss-base and
:bss-align).


> >
> > (defmacro xyzpdq (parm)
> > `(add acc ,parm))

Assembly macro, substitutes its contents for itself wherever it occurs
in the code elsewhere.

> > (defparameter +RESERVE-DATA-LEN+ 100)

Constant...


> >
> > (defdata tst-data2 (:org #x20)
> > (dw 'tst-code))

Assemble a vector to txt-code at address #x0020, overriding origin
policy for this segment only (:align can also be used). defdata,
deftext & defbss can all do this.


> > (defbss tst-bss ()
> > (reserve +RESERVE-DATA-LEN+))

Reserve a defined # of bytes as a bss symbol- does not emit code, just
reserves a region of memory.


> > (defdata tst-data ()
> > (dw 0 1 2 3 'tst-code 'tst-bss)
> > (db 4 5 6 7 '(lobyte tst-data2))
> > (db \"hello, world\")
> > supercat2
> > (filldata +RESERVE-DATA-LEN+)
> > (filldata 10 #\\x)
> > (filldata 2 '(let ((x 1) (y 2) (z 3))
> > (list x y z))) )
> >

Emit various sequences of bytes which together comprise a data segment.
dw items accept 16 bit values, emitting them as little endian byte
pairs. db items are emitted as is- integers are limited to 8 bits.
(lobyte) takes an integer, returning the least significant 8 bits.
(hibyte) is also available. 'supercat2' is a label which is set to the
address of the byte just after the 'd' in the preceeding db sequence.
filldata builds and inserts sequences of bytes, length given by the 1st
parm, the 2nd parm can take a variety of forms and provides an
initialization value or produces a sequence of chars/ints. The sequence
is trimmed or padded with 0 bytes as necessary to match the given
length. The sexp parms are supposed to be evaluated at link-time to
produce the data- the length of each section must known beforehand so
memory regions can be worked out.


> > (deftext tst-code ()
> > (nop)
> > (xyzpdq 10)
> > (nop)
> > supercat
> > (addc a 1)
> > (anl acc 15)
> > (inc dptr)
> > (cjne acc 3 'tst-data)
> > (clr a)
> > ;;(ajmp 'supercat2)
> > (acall 'supercat)
> > (acall 'tst-data)
> > (acall '(+ tst-code 2)))
>

Emit code. xyzpdq is a macro substitution. 'supercat' is set to the
address just after the preceeding nop. If not commented out, the ajmp
produces a compile-time error because it is not defined within tst-code.
The operand symbol references are supposed to produce their link-time
addresses for coding into the instruction- but expressions are
appropriate too.


> Finally, on a terminology note, you talk about "symbols" in a fairly
> confusing way. If I've understood correctly, a form like a DEFTEXT
> form creates something (exactly what isn't quite clear to me yet:
> intermediate code or machine code or something) and then gives it a
> name. The name is a symbol but the data is not the symbol. In other
> words it's analogous to the way DEFUN creates something (a function)
> and associates it with a name. For example given:
>
> (defun hello () (print "hello"))
>
> we don't say the symbol HELLO *is* a function; we say it names the
> function.
>
> Similarly in your system, it would probably be better to talk about
> "the address of the text segment named FOO" than "the address of the
> symbol FOO".
>
> -Peter

Gotcha. As usual the problem exists between keyboard and
chair... Thanks.

Each assembly instruction is a generic method, operand types selecting
the variant. The 805x instruction set revels in coding variations based
upon differences in operand types & registers. When an instruction's
method is called it creates an instance of an class that specifies the
output length in bytes of the instruction and a macro which closes over
the operands (hope I used the right words there..), which when evaluated
later, generates the instruction bytes. By deferring this step till
last, all sexps, arithmetic, etc.. are computed in one shot and the
instruction can be coded. There is no fundamental difference between
text, data or bss coding- code instructions can be put in a data segment
and vice versa. The compiler specifically allows only (reserve ..)
items in bss segments.

deftext et al name a data structure which holds the compile state for
the contents of the associated code/data/bss segment. Each pass in the
compile process evolves the compile state in the structure.

Regards,

Gregm

.