Re: A82: Ilya?

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

Re: A82: Ilya?


Comments in message.

<snip>
>I am frantically doing 2 things:
>
>1)  Writing TAZM.
>2)  Re-designing my web pages and expanding the entire site.
>
>TAZM is a Z80 table assembler like TASM301, but the main advantage is that
>there are no limitations until memory runs out.  Based on TASM301's docs I
>determined I was going to run out of line labels before I finished SQRXZ
>82.  So, I threw up my hands in desperation and I wrote 2000 lines of
>source for TAZM.
>
>While I'm talking about TAZM, are there any features that anyone would like
>to see?  Note that TAZM's syntax has some differences that make code easier
>to read:
>
>ld bc,(TEXTMEM + 12) becomes ld bc,([TEXTMEM + 12])
>
>TASM301's format is harder to read because an address is being referenced,
>which could be a label, macro, or defined constant.  Thus, the preprocessor
>has to search all three types for a match.  The new format says that this
>is a constant value + 12.  This makes is much easier to process...thus
>making it faster.


Hrm, this may make the assembler quicker, but is this necessarily a good
thing, if the programmer has to adopt styles which take longer to enter?  I
don't think we should have to work around a compiler's/assembler's syntax to
simply make the assembly quicker.  How is this easier to read?  Maybe if
you've done some other assembly which likes square brackets it would be all
right, but having two pairs seems a bit redundant.

If this is so labels and macros don't get confused by using [ ] for labels,
I don't think you need to bother.  It'd be bad programming practice to use
the same identifiers for macros and labels anyway.

>Due to this new syntax, there is no longer the requirement that spaces be
>before the lines of actual code:
>
>Label:
>  ld bc,0
>
>Could be
>
>Label:
>ld bc,0
>
>That's bad coding, but it's allowed (TASM301's format is still strongly
>supported...this is allowed for more flexibility).


That's good...

>There's much more to TAZM than just these new features.  I have included
>the standard "Stats" section to the end of each assemble.  Error messages
>are much more detailed than TASM301's.  A memory usage display is planned.
>Direct binary file inclusion (e.g. #bininclude "Filename.bin").  Anything
>else that people want (?).


Ahh... something I've been wanting for a while.  I've always had HUGE
include files with .dbs in it.

Another thing I think that's needed -- proper order of evaluation!  I don't
usually include complex expressions in my source code, but I think something
other than TASM's left-to-right ordering is needed.

How about a Win32 port of the assembler?  I don't mean like a GUI for it,
but I've got a development environment written and it's always a pain to
open a DOS prompt from my environment to assemble it.  It'd be quicker for
me (with my slowish computer) if the prog was native Win32 (with no visible
interface, just running hidden in the background).  If you did this, could
you include a switch used to direct the error messages/stats to a particular
file (because there wouldn't be a stdout to redirect if from).

Cool.  What else've you got planned?
Follow-Ups: