Re: QELFASM V2.0 Question

 

Hi Richard,

After my new op
NAME 10
SEP R7
SEP RA STACK
makes:
D7
DA22
I think I understand what you are doing. As others have mentioned
(and I mentioned in my previous post), a macro facility would be the
best approach.

A brief explanation:


.MACRO DOIT
SEP R7 \1
.ENDMAC

This defines a macro in the source code that will take the code (which
comes after the macro):

DOIT aa

and turn it into:

SEP R7 aa

before the main assembler pass turns it into . . . D7 AA . . .

Note that the \1 is used as a place holder for the first argument.
Multi-argument macros could be produced using a notation \2 \3, etc.,
or \& to indicate everything to the end of a line. These arguments
could be used several times each within a macro, for complex
operations. Of course, there are very many variant notations for
macros and operand definitions. I'm not sure which are widely used
among 1802 assemblers.

Note that many of the compatibility issues you brought up at first
could be easily solved if you write a macro handler, instead of many
code converters:

.MACRO CALL
SEP R4
.ENDMAC

.MACRO EXIT
SEP R5
.ENDMAC

.MACRO PUSH
STXD
.ENDMAC

.MACRO POP
LDXA
.ENDMAC


OR:


.MACRO .LABEL
LABEL \&
.ENDMAC

.MACRO .EQU
EQU \&
.ENDMAC

.. etc.

You get the idea. . . This allows many kinds of extensions without
actually modifying the assembler, and the extensions are visible right
there in the source code. Then, anyone with code for a different
brand of assembler can make a "compatibility" macro set, stick it in a
file called "myasm1802.inc", and (if you have a way to include source
from outside files,) get compatibility with myasm1802 by adding a line
like

.INCLUDE myasm1802.inc


Also, I of course don't know how your code is structured, but I am
guessing from your posts that you have a lookup table with "SEP R7"
matched with D7, etc. Is that correct? That works fine as long as
you have a way of turning all the "whitespace" such as tabs, multiple
spaces, etc. into a single space so the match will not fail. Another
approach is to have a table with "SEP" linked to a function, wich
reads the next operand (a register number), and generates the full
byte into the output (D0+register = D7, for example)

The SEP() generating function itself would call a function to retrieve
an operand, which would in turn call the appropriate function to
convert the number format into a value. That kind of program
structure may be straightforward to write, and allows extensions to
the format to be made with consistency. Is this something like what
you have?


I think that the effort to write a portable 1802 assembler is a
service to the 1802 community, and is appreciated. I think that once
you have it working as you desire, and release it to the community,
others may themselves be able to help to add some of the improvements
they would like to see.


Regards,

David.

Join cosmacelf@groups.io to automatically receive all group messages.