Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!princeton!udel!rochester!bbn!husc6!linus!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <899@mcgill-vision.UUCP>
Date: Tue, 22-Sep-87 01:54:33 EDT
Article-I.D.: mcgill-v.899
Posted: Tue Sep 22 01:54:33 1987
Date-Received: Sat, 3-Oct-87 06:10:47 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <366@mcdsun.UUCP>
Organization: McGill University, Montreal
Lines: 55

In article <366@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes:
> In article <320@swlabs.UUCP> jack@swlabs.UUCP (Jack Bonn) writes:
>> In article <364@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes:
[> through >>> about short/long branches]
[>>> (Fred Fish) says this complicates the linker]
[>> (Jack Bonn) says no]
[> (Fred Fish) says]

> Sigh, guess we are going to have to go into the gory details.

> [Example: machine with two jump instructions
> jump.near	<16 bit opcode><16 bit offset>
> jump.far	<16 bit opcode><   unused    >	<32 bit offset>
> ]

> Now assume some assembly code such as the following (note the lack of
> near/far specifications):
[intervening dots edited out -dM]
> 	0x00000100	jump	L1		#L1 is local
> 	0x00000200	jump	_strcpy		#_strcpy is defined elsewhere
> 	0x00000300  L1	jump	_exit		#_exit is defined elsewhere

> The assembler assumes all jumps are near jumps

But that is exactly what it mustn't do.  I would expect the assembler
to produce a near jump for the first one, since it knows that one is
near.  For the other two, it must produce far jumps, or at least
reserve enough space for a far jump.  Then the linker can either cop
out and use a far jump when the offset would have fit in 16 bits or it
can replace it with a near jump.  If it replaces it, it either has to
fill 32 bits with some sort of no-op or else it has to move stuff.  If
you choose to shrink things, the assembler will have to tell the loader
about the first jump as well (the offset will need changing).

In its complete form, the above solution is no better than the other
way (promoting near jumps to far jumps).  However, the above will
produce minimal code in almost all cases (one program out of five
thousand maybe will have a non-optimal jump?).  This is plenty good
enough for most people.  The other three can pay the price of a little
extra cpu time and get it optimal.

All you need is for the assembler to tell the loader about each such
instruction, so the loader can fix up whatever it has to without having
to scan the entire load module looking for jumps that cross the area
it's patching.

UNIX currently has something reminiscent of this: the assembler chooses
branch instructions in near/far variants and fixes the instruction type
at assemble time, pessimizing for undefined symbols.  The loader merely
fills in the offsets, even if a shorter instruction sequence would have
been possible had it been known that the target was as close as it is.

					der Mouse

				(mouse@mcgill-vision.uucp)