We bumped the # of tokens in the TOKENSTREAM structure from 32 to 64,
but also added some logic to the macro invocation code to check if we
break the limits and thus don't crash. Will 64 be enough? My crystal
ball is cloudy ATM... :-P
As far as I can tell, there should be no more regressions, but that's
no guarantee of anything. Assuming no more are found, this should go
out as version 2.0.0. :-D
RMAC has needed a struct for fixups for some time, and now it has one.
All of the credit for pushing (and patching!) in that direction goes to
ggn; blame for the way it's implemented goes to me. There's still room
for improvement; but for now, this should leave us in much better shape.
Now at v1.12.0.
The last commit had gone a bit overboard with the 32 vs 64 bit token
changes; this has been rectified. There's still a ways to go with the
floating point code, but this should be stable for now. Version now at
1.10.1.
The float changes will need some going over to ensure that we don't end
up with what we had when pointers were shoved into the token stream
willy-nilly.
Version bump to 1.9.0. Right now the only thing that supports it is
dc.d; now that the infrastructure supports it, anything else that needs
64-bit support (such as FPUs and the like) can be done very easily now.
Just when you thought it was safe to write macros with constants, up
pops a condition you thought was dead and buried yet lurches inexorably
towards your code and causes it to segfault. As it turns out, it was
bad token stream parsing that caused this, with a constant masquerading
as a STRING token being the particular mischief maker. The code that
was in place was an awful mess of horrible garbage code that wasn't
even being used anymore--so that crap is gone, and replaced with
something more (I hope) sane and maintainable. I think that the code
that was there survived purging for so long because nobody really
understood it; now that I understand it, I can't believe that it was
written in the first place (to be fair, some of it was patching done by
me, though the bulk of awfulness didn't come from that code). Onward
and upward...
Somehow I put a unicode character in my assembly source and RMAC then
barfed up an internal error #2. Chasing this down, I finally determined
that the debug traces weren't lying to me and the input file had a
problem. However, RMAC wasn't reporting the illegal character correctly
either, so that was fixed (who knew that gcc was silently killing bit 7
of chars now?). I also realized that having five separate functions for
reporting errors (and the cruft of using those crippled things) was just
a wee bit insane, so now we have proper variable argument error and
warning functions (they can be used just like a printf). Enjoy!
ggn deserves most of the credit for this, as my job was going through
and tossing out the stuff that wasn't needed. ;-) There might be some
ELFish things that still need fixing; time, as usual, will tell.
Thanks to GroovyBee for reporting the .cargs problem! Also, pretty much
all of the remaining cruft coming from the misguided "GPU in Main" cult
has been removed. Never do in an assembler what you can do with either
macros or a good preprocessor!
Removing all automatic code munging in the background by the RISC
compiler, including GPU in main idiocy. This means there are no more
built-in macros either. If you really needed this functionality, you can
put macros in your source code to do it. It doesn't belong in the guts
of the assembler.
While the assembler is in better shape vis-a-vis 64-bitness, there's
still a long way to go towards refactoring the thing to remove all
the problems it has with crufty data structures, and I'm sure there's
still bugs left in things like the .rept directive.
There's still lots to do, like refactoring a bunch of stuff that's
still basically wrong, but that's par for the course. There may be
more things that need fixing (like the .rept function, for example).
I removed a few functions that are better off being handled by the
native system libraries (malloc for amem, strdup for nstring). Also,
cleaned up files in preparation for removing pointers from the token
stream--which is preventing RMAC from working on 64-bit systems.
ggn