Re: Who should convert literals to integers?

> 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.


Keep in mind that "converting to an integer" may not mean changing it to an
internal binary form. After you locate the character string, you will do
some operations to bless what you have found and make it have whatever
form the next stage of the compiler expects for an integer.


> 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?


Unless you have context to help, you have to manage it as the largest
integer that is valid in the target context. There may be implications in
the language definition about this.


If you *can* figure out what the internal representation is supposed to be,
there's one advantage to doing the conversion, namely that you don't have
to mess around with a variable-size character string any more. You also
get the conversion out of the way early on, without another scan. Schlepping
characters about is expensive...if you look at some of the work that led up
to GLA, you see considerable effort devoted to touching/moving source
characters as little as possible.


Also,...
> [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]


There's one thing I think you ought to do, for integers (where it's
trivial) and for floating-point, where it may matter more: Convert to a
canonical form. For integers, you'd want to toss leading zeros, and you
might want all the constants in the same radix. For floating point you'd
want to "normalize". (This is still meaningful when you keep a textual
form.)
---
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
      ...I'm not cynical - just experienced.
--

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