A82: TAZM (Proposal)...

[Prev][Next][Index][Thread]

A82: TAZM (Proposal)...


Some people previously mentioned that they would like to have TAZM not be
so strict and easier to work with.  So, here is what I propose that I will do:

1)  Change the strict bracket requirement to a preprocessor suggestion.
This means that people will have the option to use brackets to speed up
compilation.  I will, in future versions, include a command-line option for
strict bracket compilation.  So, the result will be a hybrid-bracket
compilation.

2)  Add logic to do math according to the order of operations.

3)  Change the strict requirements for macro definitions and, again, make
them just a preprocessor suggestion.  The current format requires both the
definition name and the line that invokes the macro expansion to have a
colon ':' at the end.  Essentially, a macro is really a cross between a
line label and a #define, so I mixed the two to come up with the new
definition.  I figure a lot of people will complain, so I'm including
support for the "old" format.

4)  References to line labels will be left as they are.  While some might
complain that they have to use the wing-brackets '{}', I strongly believe
that they not only increase assembler speed, but it makes reading code so
much easier.  I would need a _real_ good reason to remove the code.  I
might possibly include a switch to turn them off, but it will slow the
assembler down to about half its speed and even less readability.


I'm leaving in hybrid-bracket code for good reason.  Suppose someone wanted
some math done first inside of paranthesis.  Thinking logically, an
assembler already has a tough time discerning what to calculate and what
not to.  Thus, TASM, according to the Z80 table, cannot handle the following:

  ld bc,(12*(3 + 1))

The author probably will just want the value at a memory address, but the
assembler can't tell this since there are two sets of paranthesis (for all
it knows is that it could be a value to be directly loaded into bc).  While
this is easy to calculate and plug in the value, this is only an example.
Both assemblers (TASM and TAZM) have no clue as to how to deal with this
and both generate an error.  This is where the hybrid-bracket stuff comes
into play in TAZM:

  ld bc,([12*(3 + 1)])      OR      ld bc,(12*[3 + 1])

Will both tell TAZM that it should take the value at memory address $30 and
store it into bc.  Note that the first hybrid-bracket option is easier to
add to the program, but also makes the assembler faster, even though both
are accepted formats.  The important thing that the hybrid format does is
clarify what the assembler is supposed to do.

This is the only application that I can come up with right now, but I'm
sure there are others.


So, what do you think?  Anything else?


        Thomas J. Hruska -- shinelight@detroit.crosswinds.net
Shining Light Productions -- "Meeting the needs of fellow programmers"
                   http://www.shininglightpro.com/
Follow-Ups: