From: Groepaz (groepaz_at_gmx.net)
Date: 2000-12-11 23:07:46
Ullrich von Bassewitz wrote:
> Yes, this is a known problem, and there may even be a comment in the docs
> about it.
mmmh, didnt see any (i have to admit i didnt read every single bit of the docs
either ;=D)
> The parser works with one token lookahead, so the decision about the
> addressing mode is made by the first token of the operand.
yeah, thats what i thought aswell.
> There are other assemblers that use brackets instead of parenthesis to avoid
> this problem. Another way would be to use more lookahead tokens. I don't like
> any of these solutions, so I just ignored the problem:-) I don't think there
> is an urgent need to fix this, since the problem happens very rarely (you are
> the first one complaining:-), and there is an easy workaround. Anyway, I will
> put it on the todo list, maybe I find a third and cleaner solution.
mmmh the brackets thing SUX (RGBASM - a gameboy/z80 assembler used to be like
that and its _very_ disturbing)... it's mostly a 'cosmetic' thing for me aswell,
but still a decent scanner shouldnt fail at such an easy task ;)
other than that, i think there might be a pretty easy fix actually, provided
you could 'overload' one of the builtin mnemonics with a 'traditional' macro.
like
.macro lda arg,reg
<add stuff for different adr.modes here>
...
lda(0+arg),y
...
.endmacro
... or
.define lda(x) lda(0+x)
again, this was also possible in rgbasm, and i fixed/worked around a whole
lot of simelar problems using macros this way....
> > #define AREA(x) =COUNT;COUNT+=x;
> [...]
> > so far i couldnt reproduce this behaviour in ca65, and it looks to me like
> > allowing multiple lines in c-style macros would be the way to go ;)
>
> The syntax itself may be reproduced with "old fashioned" macros and some V2.6
> features:
>
> .macro AREA Arg
>
> .if .not .match (.left (1, Arg), ()
> .error "Argument needs parens"
> .endif
>
> ...
> .endmacro
well, uhm.... no this would NOT work.... look at my example again ... i am
gonna write it down like i would have expected it to work in ca65:
.define AREA(x) =COUNT \ COUNT+=x \
foo AREA(100)
... with the c-style macro, this would expand to:
foo =COUNT
COUNT+=100
now with the traditional macro:
.macro AREA x
=COUNT
COUNT+=x
.endmacro
foo AREA(100)
...expands to:
foo ; error ": expected"
=COUNT
COUNT+=100
(if at all ;=D)
...ayeah btw, macro-params that have one character length only don't work
either.... i dont mind ;=D
> The bigger problem is that you are not allowed to modify constants, which
> means that COUNT+=x will not work. So, even having line terminators as part of
> a C style macro does not help here.
>
> Maybe you can tell me somewhat more detailed what the author of the code is
> trying to do, so I can decide if there is a way to do this with ca65, or (if
> there is no such way, and the feature seems reasonable), I can add something
> to make it work.
well since 'the author' is ME, no problem ;=D
i will however try to explain what i wanna do (or did before in tasm), not
what the resulting code/tables could be used for - this may fill another
acrticle in some other mag ;=D
i see several little problems here, which as a whole really ruin the possible
power of a macro-processor IMHO.
a) like you said, one isnt allow to modify constants (which generally is a good
thing ofcoz ;=D) - the bad thing is, that as a consequence, there's no other
kind of symbol whose value can be controlled (as in 'modified') at compile-
time. that fact makes a lot of stuff impossible, that's used frequently in
code written for eg. turbo-asm.
if you dont have some kind of these symbols, you also take most of the power
away from the .rept thing you wanna introduce ;/
b) c-style macros cannot have multiple statements/lines - this is one thing
were i just ask myself 'WHY THE HELL?!' - since a lot of useful stuff can
be done in a very convinient way using c-macros that have multiple lines.
(and yes, many of them can't be done using traditional macros)
c) with conditional assembly, there is neither a way to jump around in the
code using some kind of labels (the c64 tasm-way, i don't like it either ;=D)
nor any other way to built some loops. using recoursive macros is a pain
in the ass if you ask me, and once you got a bunch of nested loops you
end up in a good amount of newly introduced bugs aswell ;)
i understand that .rept will be added in the next release so thats probably
no more a problem then
d) c-style macros aren't exactly operating at 'scanner level'... again the
rgbasm handles this very nicely. i would expect them to really work as
"find and replace" - since this would again allow some nice stuff....
.define .db .byte
OR, if you dont want directives in c-style macros
.define db byte
should still work exactly the same (due to the find-and-replace behaviour)
e) traditional macros can't take strings as arguments - this again makes
various stuff impossible, for eg i wanted to create a macro that takes a
string and which would convert the argument (string) byte-per-byte to
eg petsci format. - right now i can do that for a single byte like intended,
but once you got more that a few words of text, you want real strings aswell ;=)
f) if you enclose a block using .proc / .endproc, other global symbols
become invisible to this block ?!? HU?! ;=D should i include my global header
files in each of these blocks ?!? nononono this can only be a bug ;)
some more stuff.... (more like nice things i've seen elsewhere....) ;=D
- extend the .incbin directive to work like
.incbin "filename",start,end,step
(includes "filename" starting from pos. start to pos. end
taking every step'th byte)
- add a simelar directive for use in macros, that works like
.readbin "filename",pos
(returns pos'th byte in "filename")
this is a VERY powerful feature, since you can do all sorts of convertion
and code-generating jobs using external data-files.
- introduce "compiler variables" as a new kind of symbols. these could live
in their own seperated namespace, or even coexist with other global symbols
in the top-level namespace. compiler variables may be 16bit integers (wether
signed or unsigned may depend on how the user works with them) that can be
modified at any time and multiple times at compile time.
.var foo = *
label=$0400
.var count = 1
.rept $10
.var foo += label+count
lda foo
.var bla += label+count
sta bla
count+=1
.endrept
- make some basic math/trig functions available ... democoders will
love you for ever ;=D
...
c: ldx #$00
.var count = 0
.rept $28
.var pos = .sin(count*$20)
lda # .readbin("themap.bin",pos)
sta $0400+count,x
count+=1
.endrept
inc c+1
...
ehrm.......enough for now ;=) hehe, better do some c64 code *G*
gpz
--
----------------------------------------------------------------------
/^\
\ /
ASCII RIBBON CAMPAIGN X AGAINST HTML JUNK MAIL
/ \
----------------------------------------------------------------------
___ ___ .___________________ .___________ _______.
c=64 / | \| \__ ___/ \ \_ _____/ \ \ groepaz
cgb / ' \ | | | / \ / \ | __)_ / | \
psx \ . / | | |/ ' \| \/ | \
dc \___|_ /|___| |____|\____|__ /_______ /\____|__ /
\/ ' \/ \/ \/
http://www.hitmen-console.org Hitmen WWW Headquarters
http://fly.to/hitmen-groepaz my personal playground
----------------------------------------------------------------------
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:37 CET