Re: Vax span-dependent jumps

ccplumb@spurge.uwaterloo.ca (Colin Plumb)
Thu, 3 Jan 91 22:54:59 GMT

          From comp.compilers

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)
| List of all articles for this month |

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


Post a followup to this message

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