Melvin Smith wrote:
> 
> At 06:07 PM 6/1/2002 -0400, Kevin Falcone wrote:
> > >>>>> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
> >
> >MS> FYI, Cola breaks with the new assembler. I think this is for 2
> >MS> reasons, multiple labels and not allowing _ in label names. Kevin
> >MS> posted a couple of patches which fix the breakage, but I'm not
> >MS> sure sticking noop in there is the correct fix for dup labels.
Aiyee. I did think about the possibility of multiple labels but the code
never made it into the new version. This is a bug, and it will be fixed
shortly. I just didn't think that hand-written compilers would generate
this code, but I suppose it's possible.

And '_' is allowed, just not as the first character. This was not what I
had in mind for limitations, and I'll patch this problem shortly. I was
just trying to eliminate 0-9 as the first character, and apparently got
a bit wild.

> >Any thoughts on what to do instead of the noop?
> >
> >It definitely isn't the best thing to do, but other parts of the
> >assembler expect to be able to yank an instruction out of the data
> >structure and run it.  The other option I guess is to fix the part of
> >the assembler which scans for and removes labels, but I couldn't get
> >that to work reliably.
> 
> I think your quick fix is fine; I expect we should merge adjacent labels,
> but I was leaving that up to Jeff. At least I can use your patch to run
> my programs. :)

Feel free to do that but I'll fix the actual bug soon.

> >And yes, cola was my test language to fix these things.

I'm running this now for tests as well, but at the time I was
concentrating on making sure it passed the basic tests of .pasm
instructions.

> I think I'll probably fix this in the backend (imcc) soon so as
> not to emit multiple labels.

Multiple labels should be allowed, but it wasn't in my test suite. Maybe
we should add that to macro.t.

> We should probably be testing the assembler with Cola and
> Jako, since the plain pasm samples are probably not typical
> enough of compiler generated code.

Before we go down this line too far, I'd like to remind people that the
macro layer is pretty much exclusively for hand-generating code.
Compilers should be smart enough to generate their own unique labels, so
..local definitions go away. Constants should probably be interpolated,
but I'm concerned about how the compiler will know the PMC types at
runtime...

> -Melvin
--
Jeff <[EMAIL PROTECTED]>

Reply via email to