|Generic Assembler? firstname.lastname@example.org (Chris Williams) (2005-02-28)|
|Re: Generic Assembler? email@example.com (Randy) (2005-02-28)|
|Re: Generic Assembler? firstname.lastname@example.org (glen herrmannsfeldt) (2005-03-01)|
|Re: Generic Assembler? email@example.com (Vidar Hokstad) (2005-03-04)|
|From:||glen herrmannsfeldt <firstname.lastname@example.org>|
|Date:||1 Mar 2005 15:50:41 -0500|
Chris Williams wrote:
> I have started work (i.e. research and structure-creating algorithms)
> on a compiler that is intended to work solely as a scripted
> preprocessor--preprocessing the source code in levels based on
> symbological and structural definitions, then translating that into a
> lower level format via scripting. This process would be repeated for
> varying layers of languages, with the output of each being fed into
> the next layer.
This reminds me of Mortran, a language designed to be an improved
Fortran, with a processor to convert to ANSI standard Fortran.
The processor was written as a set of self-modifying macros, and a
macro processor to run them.
> C ruleset -> Generic Assembler Language -> Platform Assembler -> Bytes
> -> Object File
> For instance would be the various rulesets that could be applied. (The
> middle three would probably appear as a single file though, with the
> last simply being a library of functions that abstracted an object
There are some interesting differences between assemblers separate
from the actual opcodes being used. Some consider a label if it
starts in column one, otherwise no label. Others use a colon to
indicate a label, or sometimes two. Some require a special character
to indicate comments on the same line as code, others do it based on
fields. (label, opcode, operands, comments). Some consider the
destination operand on the left, others on the right.
I have seen various assemblers (Z80, 6502, 6809) written as macros for
the OS/360 assembler, which means they follow OS/360 assembler rules
even though they use the appropriate opcodes. Then again, the gnu
assembler often uses different opcodes and syntax from that normally
used by the appropriate machine.
It should not be too hard to build a table driven assembler that would
allow for different combinations of input syntax.
Return to the
Search the comp.compilers archives again.