Related articles |
---|
Vax span-dependent jumps chris@mimsy.umd.edu (1990-12-23) |
Re: Vax span-dependent jumps henry@zoo.toronto.edu (1990-12-30) |
Re: Vax span-dependent jumps lehotsky@aries.osf.org (1991-01-02) |
Re: Vax span-dependent jumps ccplumb@spurge.uwaterloo.ca (1991-01-03) |
Newsgroups: | comp.compilers |
From: | ccplumb@spurge.uwaterloo.ca (Colin Plumb) |
Keywords: | optimize, code, assembler |
Organization: | University of Waterloo |
References: | <9012111913.AA07310@cs-sun-fsa.cpsc.ucalgary.ca> <14692@goofy.megatest.UUCP> <28765@mimsy.umd.edu> <1990Dec30.005507.7842@zoo.toronto.edu> <17633@paperboy.OSF.ORG> |
Date: | Thu, 3 Jan 91 22:54:59 GMT |
Well, the nastiest case in production is the Inmos Transputer, which has a
different instruction length for each 4 bits of offset. 4 bits is 1 byte
of instruction, 8 bits is 2 bytes, 12 bits is 3, etc. A worst-case jump is
8 bytes.
Since every constant in the program is expressed this way, the problem is
put off until the linker. The linker has a nasty habit of being slow.
Eventually Cogent Research (where I used to work) rewrote it. Basically,
they build a list of all the non-constant offsets and the labels they're
relative to. Keep track of the distance between labels, beginning by assuming
they're all one byte long. Then run over the list extending things until
it stabilizes. I'm sure someone could come up with an example which only
lengthens one instruction per scan, and each instruction lengthens a few times,
but as long as it's only label1-label2, it's monotonically increasing
and you have reasonable worst-case run-time (and a lot faster than the wierd
heuristics that were in use before, in practice).
If you allow stranger expressions, I suppose it's possible for this to
produce non-optimal results, but it won't happen very often in practice.
--
-Colin
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.