Personally I don't think extending the reserved
symbols is a big deal. I don't like the idea of using
formatting to allow the use of vague-sounding labels
like this:
A = $50
LDA
LDA #$FF
ROR A
vs.
CAR_ADR = $50
LOAD_SPRITE
LDA #$FF
ROR CAR_ADR
I mean, if people just use more descriptive labels I
don't think you'd naturally want to use a reserved
keyword. The only time I think "A" would naturally
come up is if you were putting a label on an A
character graphics area, but you could just as easily
prefix those labels like "GFX_A" or "SHAPE_A" or
"CHR_A".
This was more of a problem when people used to
assemble directly on 6502s and you used mostly short
acronym-type labels to save space.
If someone had an old sourcecode file to assemble I
would just have a command line switch to go back and
forth between strict formatting (short list of
reserved keywords) and loose formatting (long list of
reserved keywords). But the default could be loose.
--- "C. Bond" <cbond@xxxxxxxxxxxxx> wrote:
> You can certainly write an assembler which accepts
> opcodes or labels on
> a 'hard left margin', but there are tradeoffs. For
> example, this may prevent
> you from using certain labels, especially if your
> opcode list includes all
> the unofficial opcodes. In some cases you may have
> to rewrite your source code
> to change labels such as SAX, DCP, etc. so they
> don't conflict with opcodes.
> It might be better to simply separate labels from
> opcodes by a formatting rule.
> (Maybe not, just a thought!)
>
> Another issue has to do with using opcode syntax
> such as LSR A and
> ROL A. If your assembler simply requires LSR or ROL,
> you can free
> up 'A' for use as a label, otherwise it becomes a
> reserved symbol.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
