[COMMIT] IMCC bug fixes and changes
Melvin Smith
2) IMCC labels can no longer start with #, although they may
contain embedded #
Reasoning: Its a bit ambiguous to the eye, which isn't too bad,
but IMCC should be able to spit out PASM and turn around and compile
it from text format (.pasm), which previously it could not, since it
handled labels differently than the assembler.
IMCC will no longer parse the following as a comment:
foo#old comment
Instead foo#old is now an identifier (or label if in label context)
Add a space: foo #old comment
3) Sub arguments overflow correctly now, I've tested with 30 arguments.
-Melvin
Leopold Toetsch
> 2) IMCC labels can no longer start with #, although they may
> contain embedded #
Suboptimal. Label starting with an underscore are global labels and get
an entry in the fixup-table.
> Reasoning: Its a bit ambiguous to the eye, which isn't too bad,
> but IMCC should be able to spit out PASM and turn around and compile
> it from text format (.pasm), which previously it could not, since it
> handled labels differently than the assembler.
This was suboptimal too, for sure. What I wanted to achieve is, that the
generated labels never interfer with user labels. If we want to compile
generated PASM, there is no solution for this. We only can reserve some
syntax for our own usage.
> IMCC will no longer parse the following as a comment:
> foo#old comment
This seems rather dangerous to me.
What about:
@reserved_internal_label:
@reserved_identifier
> -Melvin
leo
Melvin Smith
>Melvin Smith <mrjol...@mindspring.com> wrote:
> > 2) IMCC labels can no longer start with #, although they may
> > contain embedded #
>
>Suboptimal. Label starting with an underscore are global labels and get
>an entry in the fixup-table.
Then we'll have to come up with another solution.
> > Reasoning: Its a bit ambiguous to the eye, which isn't too bad,
> > but IMCC should be able to spit out PASM and turn around and compile
> > it from text format (.pasm), which previously it could not, since it
> > handled labels differently than the assembler.
>
>This was suboptimal too, for sure. What I wanted to achieve is, that the
>generated labels never interfer with user labels. If we want to compile
>generated PASM, there is no solution for this. We only can reserve some
>syntax for our own usage.
I'm not sure which you mean is suboptimal, IMCC spitting out code that
can't be compiled, or my fix.
> > IMCC will no longer parse the following as a comment:
> > foo#old comment
>
>This seems rather dangerous to me.
>
>What about:
>
> @reserved_internal_label:
> @reserved_identifier
I'd actually considered the same. I think this might work.
We definitely have to reserve something that doesn't collide with
the assembler, and # won't do.
-Melvin