A82: Re: TAZM (Proposal)...


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

A82: Re: 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/

Sounds better, but I have another suggestion for that bracketing.  Why not
just use square brackets to indicate indirection, and all parantheses will
be used in mathematical evaluation?  This'd be quite readable, especially to
x86 programmers, and should be sufficient for determining what to do.

Remember, the more changes you make to the source code format, the less
likely people will be to switch to it -- some people have been using the
TASM format for quite a while now, and won't like the changes.

Best of luck,
Cameron




Follow-Ups: References: