Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <8745@utzoo.UUCP>
Date: Sat, 10-Oct-87 19:58:08 EDT
Article-I.D.: utzoo.8745
Posted: Sat Oct 10 19:58:08 1987
Date-Received: Sat, 10-Oct-87 19:58:08 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>
Organization: U of Toronto Zoology
Lines: 24

>	... If you default to "near" jumps, you have the
>	linker fix up all the jumps that are really "far" jumps ...
>	[vice versa for defaulting to "far" jumps]
>	... In either case, you either grow or
>	shrink the code as appropriate, in the linker.  What could
>	be easier?  In either case, you end up with exactly the same
>	executable object code.  No nops, no "non-optimal" jumps, the
>	*same* *optimal* *code*. ...I don't claim that either is somehow
>	theoretically "better"...

Hah, caught you, Fred!  Not (quite) true unless the linker is fairly
sophisticated.  There are interdependent situations in which the spans of
several jumps depend on each other's size:  they can all be "near", but the
linker will discover this only if it looks at making them *all* "near" at
the same time.  A simple one-at-a-time approach with a "far" default will
leave them all "far".  The level of sophistication needed to spot this
amounts to simulating a "near" default, so one might as well just use that
default in the first place.

Such situations are admittedly not all that common, but it does supply a
reason for picking "near" over "far" if nothing else interferes.
-- 
"Mir" means "peace", as in           |  Henry Spencer @ U of Toronto Zoology
"the war is over; we've won".        | {allegra,ihnp4,decvax,utai}!utzoo!henry