Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sunybcs!boulder!hao!noao!mcdsun!fnf
From: fnf@mcdsun.UUCP (Fred Fish)
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <386@mcdsun.UUCP>
Date: Wed, 14-Oct-87 13:25:35 EDT
Article-I.D.: mcdsun.386
Posted: Wed Oct 14 13:25:35 1987
Date-Received: Fri, 16-Oct-87 22:19:46 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <384@mcdsun.UUCP> <117@nusdhub.UUCP>
Reply-To: fnf@mcdsun.UUCP (Fred Fish)
Organization: Motorola Microcomputer Division
Lines: 64

>In article <384@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes:
> 	the linker fix up all the jumps that are really "near" jumps
> 	to be "near" 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*.

Since posting this, I have received some mail from Dean Inada at Peregrine
Systems that provided an example where shrinking the code is not really
possible without considering more than one candidate jump at a time, something
that my current implementation doesn't do.  Thus growing the code is the
correct choice for my situation.

The example Dean provided was essentially:

	foo:
		farjump	bar
		["X" bytes of stuff]
		farjump	foo
	bar:

Where X is just that right size such that neither jump, considered by
itself, can be shortened to near, but if we had started with near jumps
neither would have been required to be lengthened to far jumps.  "X" 
depends upon the size of your near/far jump sequences.  Thus in order to
make my original statement true, it is necessary to consider more than
one candidate jump simultaneously (LOTS more work).  Thus "near" as the
default is even more obviously the correct choice for my implementation.

In article <117@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>    ALL "short" jumps [add/subtract value from the
>instruction pointer directly] are compleetly generated and closed
>in the assembler.  If there were to be an alteration in the size
>of a block of code-text, the linker would have to "reassemble" the
>code block to make up for the altered "short" jumps and such.  In
>order for the linker to do this it would either need the source
>code, or it would have to take a stab at disassembeling the object
>code and hope not to get it wrong. The assembler is designed to
>AUTOMATICALLY determine the "near"ness or "far"ness of a refrence. 

The only reason that the linker would need to "reassemble" the code
block is if the assembler decided to try doing part of the linker's
job to begin with.  My assembler doesn't, thus my linker doesn't have
to go through the pain you described above.

>	It should be obvious that the assemblers job is to assemble
>and the linkers job is to link.

I couldn't agree more...

>MR FRED: At one point you said "what could be simpler" [deleted from this text
>for brevity].  If it is so simple, I would love to see your compleeted
>disassembling-assebeling-optomizing-editing-linking-loader on the
>market.  [For a PC or 3B2 prefreable, as these are the machines
>I have avalible to test it on.]

You very likely will see it some day, though I doubt it will run on the
PC or 3B2 except possibly as part of a cross development environment.

-Fred
-- 
# Fred Fish    hao!noao!mcdsun!fnf    (602) 438-3614
# Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282  USA