Who should convert literals to integers?

In article <1953@ima.ISC.COM>, boulder!bob@ncar.UCAR.EDU (Bob Gray) writes:


> Several common processors are provided with GLA, such as putting
> an identifier into a hash table, making an integer from a series
> of digits, storing strings...etc.


This feature has prompted me to comment, though this isn't a criticism
of GLA in particular.


Does anyone else think that converting a series of digits into an integer
is inappropriate for a lexical analyser? It seems to be a very common
thing to do, but I can see practically no advantages to it, and several
disadvantages.


First, what do you do if the integer is out of range? Report an error,
I hope. But what's the range? Is this a long literal? A short? A char?


What if this is a cross-compiler? The maximum-size integer may not even
fit in the word-size of the host machine. Even if the host has words as big
as those on the target, the valid integer range may differ. This may seem
like a specialized case, but shouldn't the lexical analyser be completely
independent of the code generator?


And who needs the literal in converted form? Not the parser. The code
generator needs it for constant folding, but it can convert it itself
just as easily as the lexical analyser could have. Often, the code
generator will be in a separate pass, with an ASCII intermediate language,
which means the first pass will be converting the integer right back
to a series of digits.


The only advantage I can see is that the lexical analyser will be scanning
past the digits anyway, while a later conversion would require an
additional scan, with attendant loop overhead. Surely this is a completely
negligible gain?


Any comments?


        Radford Neal
[Your point is well taken, and I note that I increasingly see constants,
particularly floating point ones, pass right through to the assembler pass
without ever being converted to binary on the way, -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.