Re: Who should convert literals to integers?

In article <2299@ima.ima.isc.com> I wrote:
>I once worked on a cross-compiler that ran on a 16-bit-integer machine
>but produced code for a 32-bit-integer machine. Integer constants
>smaller than 32k were converted to binary, but we left larger ones in
>text form until the assembly pass. Users weren't allowed to declare
>arrays of more than 32k elements...


In article <2370@ima.ima.isc.com>, markhall@pyramid.pyramid.com (Mark Hall)
replied:
>If anyone out there is writing a compiler from scratch, please
>don't do what is described above. Whenever compile-time
>arithmetic is required, calls should be made to a retargetable
>module which can carry out the computation in the same precision
>and semantics of the target machine. If the host has more [less? TL]
>precision than the target, then the representation possibly
>`must' be strings, but it's far from impossible to do arithmetic
>on strings!


I agree *in principle*. In practice there are some other considerations.
The compiler I described was a bootstrap system, which we fully intended to
scrap once we had a stable development platform on the target hardware.
In that context, building a multiple-precision integer arithmetic package
just wasn't worth the effort; the compiler's (not very severe) restrictions
could be lived with.


For a production cross-compiler, it would make sense to do things as
Hall suggests. Note that the implications are extensive: for example, the
offsets to local variables in a procedure's stack frame would need to be
target-integers. Thus doing it right impacts the compiler's symbol table,
as well as virtually all aspects of code generation. In currently popular
systems programming languages, the notational inconveniences alone would be
a tremendous problem ("add(x,convert_int(1))" instead of "x+1").


Dealing with floating-point arithmetic is much harder. For instance,
I recall reading horror stories about early Fortran systems in which
compile-time conversion of a floating point constant could give a
different result than run-time input of the same character string.
A cross-compiler that does constant-expression folding is going to have
a very hard time ensuring that it gets exactly the same result as run-time
evaluation would. (This may get easier in future, as more machines
are built to the IEEE floating-point standards.) The only good aspect
of the situation is that cross-compilers are usually used for
development of systems software, in which optimization of floating point
arithmetic isn't much needed. Therefore, the problem can be bypassed
by passing F.P. constants through in text form, and not attempting to
precompute any constant F.P. expressions... which is exactly what we did,
as did some other recent posters. (Then the only problem is correctly
converting F.P. constants to bit strings in the cross-assembler.)


The article that started this discussion proposed the pass-through,
"hands-off" approach for *all* constants, integer as well as floating point.
The point I tried to make is that the semantics of programming languages
often require the compiler to do calculations with integer constants; so the
fully hands-off approach is not workable. (Compile-time floating-point
operations are never required in Pascal or C; I'm not too sure about Ada.)
Hall's point is that having to do calculations does not mean having to
assume that host-integers are the same as target-integers. This is a valid
point, and is probably the right attitude to take in a production quality
cross-compiler; but the cost is not trivial.


--
tom lane
Internet: tgl@zog.cs.cmu.edu
UUCP: <your favorite internet/arpanet gateway>!zog.cs.cmu.edu!tgl
BITNET: tgl%zog.cs.cmu.edu@cmuccvma
--

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