A85: TAZM...(***VITAL***)

[Prev][Index][Thread]

A85: TAZM...(***VITAL***)


I know how someone will complain about the "mass-mailing" that this is.
However, the issue here is big enough that confining this thread to A82 is
no longer an option.  I have already made several proposals that people on
A82 agree with me (for the most part).  However, I have been thinking about
a suggestion that someone mentioned for a while and I wish to ask what the
rest of you Z80 programmers think.

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

Now, what are hybrid-brackets?  In a previous A82 thread, I changed the
specs. on TAZM to use hybrid-bracket code for math.  (The first
specifications called for square brackets [] around ALL math operations to
speed up the preprocessor...people complained so I changed the specs :)
Here is what I said when I proposed hybrid-brackets:

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

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:

  push af
  push hl
  push de
  ld bc,(3 + 1)
  ld d,12 - 1
  ld h,b
  ld l,c
Label:
  add hl,bc
  dec d  
  jr nz,Label
  ex de,hl
  ld hl,Label2
  ld (hl),e
  inc hl
  ld (hl),d
  .db $opcodeForLDBC,(XXXX)
Label2:
  .db $00, $00
  pop de
  pop hl
  pop af

  (I know that this can be optimized...I'm just making my point).

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

1)  ALL memory references will need to be inside square brackets [].  ALL
math operations will therefore be required to be inside of paranthesis ().

2)  Cleaner, shorter code (a bit obvious from the above example, no?)
  a)  Simplified multiple address references (previous example).
  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.

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

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:

  ld bc,(12*(3 + 1))    will have to be converted to:
  ld bc,[12*(3 + 1)]    (Note the square brackets)

You may be asking why I don't include a switch to turn IDEAL mode off.  The
problem lies in the fact that my already 2000+ lines of source will
automatically become 4000+.  Maintaining TWO sets of source in one program
is more hassle than it's worth.

If I didn't think that IDEAL mode was more important than the one big
"setback," I wouldn't have even thought about writing this e-mail.  Rather,
I strongly believe that IDEAL mode will allow us to write programs faster,
with less source code, allowing for more time to optimize.

Tell me what you think about this.  Don't forget, your voice counts!!!


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