Re: TAZM...(***VITAL***)

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

Re: TAZM...(***VITAL***)

(I'm only on the assembly-86 list...if you want me to see your reply, CC it
to david@acz.org)

> For those of you who don't know what TAZM is, it is a "better" TASM 3.0.1
> with unlimited line labels, cleaner code, follows the order of operations,
> etc.  Oh, and it assembles faster than TASM :)

Assembly Studio 86 already exists, and since the new version supports
plugins for the output file, it can be used with all Z80 calcs.  It's a full
IDE: color-syntax coloring editor, assembler, sprite editor, etc.  It also
includes a help file for all of the z80 instructions, ports, etc.  If anyone
is interested in using it for a calc other than the 86, we'll write plugins
for them.  Sure beats compiling in DOS :)  I don't care if you are a DOS
fanatic (I am), but you'll switch in no time.

> >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:

Assembly Studio has an option to warn you of "illegal indirection" when you
do something like this.  Evaluating left-to-right shouldn't be a problem, as
in a language like C that handles order of operations, it's still good
programming practice to use parenthis to eliminate any possibly ambiguity.
If you aren't using indirection, leave out the parenthesis.

If you do want <ld bc,nnnn> then it should be written as follows:

 ld bc,12*(3+1)

Suppose you did need the value, as with <ld bc,(nnnn)>:

address = 12*(3+1)     ; or even address = (12*(3+1))
 ld bc,(address)

> Actually, I realized after this message that TASM can determine the
> difference, but what if the author wanted to get the address of the
> address?  TASM has no clue, thus more lines of code are needed making the
> source REALLY ugly:
>
>   ld bc,(12*(3 + 1))    becomes:
>
[snip]
>   (I know that this can be optimized...I'm just making my point).

I fail to see how writing a page of code that's pointless makes a point.
The instruction exists, and as shown above, the compiler will generate it.
So you can use it.

> Proposal:  Z80 ASM "IDEAL" mode.  Most x86 programmers already know what
> this implies, but for the rest of you, this is what will happen:

It already exists.  You can't change the instruction set.

> 2)  Cleaner, shorter code (a bit obvious from the above example, no?)

Not really.  The assembler will still generate any code that's possible.  If
you're going to be lazy and not evaluate stuff before hand, then you'll just
have to suffer with adding an extra equate.

>   b)  Register math!!!  I can't count how many times I've just wanted to
type:
>       ld a, (a+b+c) << 2   (in IDEAL mode) and had to type:
>       ld a,a \ add a,b \ add a,c \ add a,a   instead.

Umm...that's what assembly is!  There is no instruction to do that, so the
assembler will have to make up it's own code.  That's not assembly language.
What if you aren't using the accumulator?  The assembler will never be able
to create as efficient code as a programmer will.

If the assembler creates the code and doesn't just assemble it, then it's
not assembly anymore!

> Everyone is happy with clearer, cleaner, shorter, error-free code...right?

Clearer/cleaner?  That's all opinion.
Shorter?  No.  The object code will be the same, no matter what source it
came from, assuming it's being assembled only.
Error-free?  Changing the format of code won't keep you from making errors.
But any experienced programmer that has to drastically switch formats might
start making more.

> Well, there is one catch.  If you read part #1 of the proposal, there is a
> huge problem.  ****ALL "OLD" Z80 CODE WILL HAVE TO BE CONVERTED!!!****
> Overall, it isn't a big conversion, but every line that has a memory
> reference:

My current project has 12,500+ lines of code.  I'd say that's a big
conversion.

******************************************************************
* To UNSUBSCRIBE, send an email TO: listserv@lists.ppp.ti.com
* with a message (not the subject) that reads SIGNOFF CALC-TI
*
* Archives at http://peach.ease.lsoft.com/archives/calc-ti.html
******************************************************************
References: