Re: A82: Ilya?

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

Re: A82: Ilya?


At 04:15 PM 5/6/99 +1000, you wrote:
>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.

The square brackets tell the assembler to run the "calculator."  This
returns a value which is replaced inside the brackets.  There are VERY
different ways to recognize constants, macros and labels.  I only
demonstrated the way the assembler recognizes constants.  The rules are
different for macros and labels.  Macros are not in square brackets and are
on their own lines.  I decided on square brackets to make it easier on the
user and the assembler to determine what they were looking at, a direct
number (no brackets), a constant value (e.g. TEXTMEM), or a label.  As you
will notice, the following is hard to determine the differences between
various items:

  ld bc,($15)
  ld bc,(TEXTMEM)
  ld bc,(label)
  ld bc,(label + TEXTMEM)

and so on...  All of those are difficult to determine what each thing is,
both for the user and the assembler.  The only reason you know that label
is a line label is because it is is called 'label.'  The assembler doesn't
know this and has to search the labels and constant values AFTER it
searches for a match in the Z80 opcode table.  Being able to calculate
values before a search makes the assembler TWICE as fast!  Here is how to
program everything above for the new assembler:

  ld bc,($15)
  ld bc,( [TEXTMEM] )
  ld bc,( [{label}] )
  ld bc,( [{label} + TEXTMEM] )

True, a lot of the time, label references will seem a bit like overkill
(three brackets in memory address references).  I should probably allow
people to (in a future version) use the old-fashioned, slow TASM301 syntax.

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

Yeah, I know how disgusting it is to know that you are writing a program to
convert a binary file to .dbs only to have it be converted right back into
its original form  :P

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

I thought about that.  Right now I've got the TASM301 way of doing that.
I'll throw a dozen or more lines of code in later to fix that.

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

I probably can do that...using DJGPP once I'm done.

>Cool.  What else've you got planned?

I'm just trying to get the basic programming stuff done first...details
come later.  Oh, eventually, I'm going to write some code to dump debugging
info. into a separate file to be used in conjunction with an emulator (I've
been wanting one that didn't need a ROM for while now).

If you think of anything else you want, let me know.


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