Subject:
Re: special numbers
From:
Craig Franklin ####@####.####
Date:
10 Sep 2004 21:28:33 +0100
Message-Id: <41411F56.7050904@users.sourceforge.net>
pico wrote:
> The ambiguos thing is, that the actual gpasm architecture don't
> utilize the two-tiered lex/yacc but a tree-tiered
> lex/yacc/lookup-table(c) parsing.
Don't forget that gpasm supports several processors with different
instruction sets. So some type of runtime selection of instructions is
required. It gets complicated too. The instruction sets aren't even
uniform across all devices within a family. For example, the 17c42
doesn't have the multiplication instructions the other devices in its
family have.
Also some of the directives, the special mnemonics, are only available
on certain devices. So they also require some type of runtime selection
as well.
The lookup table method was chosen to solve these problems. It isn't
the only solution, but it is a good one IMHO.
> It's possible to decide, that some command are parsed at stage 2 (yacc).
> My feeling is, that this can bring more sideffects. Specially if a more
> cleanup of code is made.
I would hope that the regression tests would catch any errors that we
make, but they aren't perfect.
> As example the orginal MPASM uses the cpp as first pass.
> This ensures, that you can use #defines for changing include files.
> The current implementation don't differ from #include, #define
> and include / set. If we mix these stages, the possibility is high,
> that we can have some trouble later, if something must be parsed in
> the correct/different way.
gpasm's preprocessor logic is in the lexer. So it is part of the first
pass. It too could use #defines in the #includes, if someone (probably
me) would change the code to support it. It isn't a limitation of
gpasm's architecture, just developer time.
I also want to be clear. The last time I checked mpasm wasn't using
"cpp" as its first pass. Like gpasm, it was using its own internal
preprocessor.
> You suggest, that either analyse the identifier and make a tiny C
> state machine on top of the bison parser, parse the directives as yacc
> grammar
> and patch it later to be identifiers, or parse it directly in yacc.
> It seems to me, that all this tree possibilitys are more cribbled code
> as those proposed. The actual code work only, if you use 0x100000 or
> D'100000', or 1000*100, but not 1000000. The radix base don't matter.
>
> It's possible that i'm wrong from the internal parsing in gpasm.
> I had some parsing errors resulting in the wrong radix or that
> generate a error like this: illegal character 'c' in numerc value.
> I have added somethings like that in order to resolve the error.
>
> [0-9][a-z0-9]+ { char *p; yylval=strtol(yytext,&p,radix);
> yyless(yytext-p); }
>
We need to be careful not to confuse subjects. Please send me a
specific example and we can work through it.
> In my eyes, fixing this bug or more esplitly speaking this compatibility
> parsing in bison requires a considerably rework of the parsing
> algorithm. It's possible, that Craig has this type of solution.
>
Many of you have probably wondered, why I never fixed this problem. The
complications pico is wrestling with are why. I never considered the
bug a major issue, because I always use 0x123 or d'123' on my numbers.
There were always higher priority problems.
Many bug reports have been reported on the same issue, this issue, over
the last couple of months. So I will move it to the top of my priority
list and try to take care of it. There might be a little delay, but I
will get it done.
> The patch now works, it was my initial error to don't consider the
> list p=xxx .
> As note, the lexer makes a special case, if it's in a list command.
> This is to ignore the current lexer radix.
> Cleaning up all this means a non significant rework of the lexer/parser.
>
>
>> Scott
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
