Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!husc6!hao!noao!mcdsun!fnf
From: fnf@mcdsun.UUCP
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <364@mcdsun.UUCP>
Date: Sun, 30-Aug-87 17:08:23 EDT
Article-I.D.: mcdsun.364
Posted: Sun Aug 30 17:08:23 1987
Date-Received: Mon, 31-Aug-87 04:06:40 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <200@hobbes.UUCP> <296@swlabs.UUCP>
Reply-To: fnf@mcdsun.UUCP (Fred Fish)
Organization: Motorola Microcomputer Division
Lines: 34

In article <296@swlabs.UUCP> jack@swlabs.UUCP (Jack Bonn) writes:
>Why not generate source assembler that doesn't indicate whether the target
>is near or far.

Ok so far...

>		  Then let the assembler choose the long or short form of
>the jump depending on the worst case distance from the target.

This only works for jumps to local symbols within the same assembly module,
and GREATLY complicates the work of a linker which optimizes both local
and global references (since it must now cope with relocation done by
the assembler when it inserts or deletes code between the definition and
reference of a local symbol).  Again, I believe the assembler has no
business whatsoever doing relocation and current implementations only
do so for historical reasons (the assembler writer knew that assemblers
have "always" done this).  Relocation is the linker's job.  If anyone
has a counter argument please post!

>Of course there are cases where this is too pessimistic, since the "real"
>solution is exponential (np-complete?).  But in real cases, this yields
>results very close to optimum.

Gosh, I'm glad this discussion didn't come up several months ago when
I was in the midst of writing a new linker from scratch.  The code to
implement near/far relocation optimizations might have taken more than
the three days or so that it actually took, if I'd have known how
difficult a problem it was to solve efficiently...   :-) :-) :-) :-)

-Fred
-- 
= Drug tests; just say *NO*!
= Fred Fish  Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282  USA
= seismo!noao!mcdsun!fnf    (602) 438-3614