Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!sun!decwrl!labrea!jade!ucbvax!sdcsvax!ucsdhub!jack!man!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.lang.c
Subject: Re: near / far branches
Message-ID: <138@nusdhub.UUCP>
Date: Sat, 17-Oct-87 18:07:43 EDT
Article-I.D.: nusdhub.138
Posted: Sat Oct 17 18:07:43 1987
Date-Received: Sun, 18-Oct-87 22:42:00 EDT
References: <117@nusdhub.UUCP> <420@wrs.UUCP>
Organization: National University, San Diego
Lines: 68
Summary: ok..


As far as you coments on my coments on the assembeler, I must cede to
you greater knowlege.

My only execption to your statments is:

	When I used "SHORT" you started talking about "NEAR" and "FAR"
under the intel [grabag] there is an instruction which simply adds/
subtracts a signed byte from the instruction pointer.  In fact ALL
the conditional branching in a x86 family are these types of things.

The simbol table for load-time-fixups, not runtime relocation, would
be horrendus.  Since we were talking about shrinking and growing the
operations between word and dword parameters for every FAR refrence
which became NEAR durring linking.  [I.E. Why, that's right over here,
I don't need a segment on this refrence.] the problems become numerous.

1) all the conditional branches will have to have their inline constants
checked for validity, and each "short" label, which the assembeler
now disposes of, will have to be placed in the external symbol table.

2) The linker will have to look at the entire body of code, and determine
if any of the internal or external refrences to a procedure [i.e.
use of the "call" opp.] are actually far.  If none are, then the
linker can go ahead and change all the call opps, and the return opps
to nolonger contain a refrence to a segment.  It must then:
	a) scan the body of the call for any segment overides refering
	to the code segment, and trun them into NEAR opps.
	b) Scan the body of the text, and remove some one of the
	negitive-of-frame-pops, because the frame has been shrunken
	by one word.  This scaning would have to include itterated loops
	and simple addidtion of constatnts to the stack pointer or
	base pointer, or any regester or memory location which assumes
	the value of the above durring the functioning of the call, or
	any of it's branches or children.

<Jumps arn't This bad, but they have their own stickeyness about their
	selves to complicate these "fixups">

.....  [stuff and issues ad nausium deleted]   .....

My point was that any assembeler worth it's salt, in a similarly
valued programmer's hands can MUCH better serve by the judicious
use of "NEAR" and "FAR" rathar than screaming about how easy it
would be to make a linker which would "take a far call, turn it
into a near call, and then delete the no-ops to tighten the code"

Yes, Assembelers send all the pertinent information to the linker,
and yes the linker can do amazing things with it, and yes, Assembelers
can do all sorts of optomizing things to assembly code.  That was part
of my point.

But when someone tells me that they want to have a "Linker" go through
the output of their various compilers and assembelers and have it
re-optomize their code, rigt down to removing all those peskey extra
no-ops and over-refrenced calls, I SCOFF.  Isn't that what I bought
my compiler and assembeler for? <sort of>

If there is such a product, a "disassembeler-optomizer-assembeler-linker"
which can work with "any object output, no matter what the source"
and optomize it to such a persnicity level, there wont have to be any
programmers, because the language it was writen in will take instructions
like "make me an inventory cost-accounting database package costomized to
my needs.<CR>" as a fully functional programming directive.

I say: Write one for me, and I'll see how well it works.

Rob.