Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!sri-spam!sri-unix!hplabs!tektronix!tekgen!tekigm!phils
From: phils@tekigm.UUCP (Phil Staub)
Newsgroups: net.micro.amiga
Subject: Re: C compiler comparison
Message-ID: <962@tekigm.UUCP>
Date: Thu, 9-Oct-86 03:29:53 EDT
Article-I.D.: tekigm.962
Posted: Thu Oct  9 03:29:53 1986
Date-Received: Fri, 10-Oct-86 00:48:49 EDT
References: <8610071955.AA15436@cory.Berkeley.EDU>
Reply-To: phils@tekigm.UUCP (Phil Staub)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 78

In article <8610071955.AA15436@cory.Berkeley.EDU> dillon@CORY (Matt Dillon) writes:
>by about 10-20%.
>
>>>	Talking to Jay Denebeim (sysop for the BBS w/carries Blink), Lattice's
>>>3.04 compiler will have PC relative addressing modes for calls and jumps, and
>>>relative addressing through an address register for static/global variables.
>>>He pointed out that this would mean that I could make my shell and any other
>>>program re-entrant without any problem.  This will also, incidently, probably
>>>make the code more compact than Manx as Lattice already has some great
>>>optimization hacks in the compiler.
>>>
>>
>>Manx 3.20a already uses these optimizations if small code and data models
>>are used (the default).
>
>	I used Lattice on an IBM system... couldn't stand the FOUR memory
>models.  But on an 8086/8 you don't have much choice since the registers
>aren't 32 bits and you have that idiotic segmentation scheme.  One of the
>reasons C on the 680x0 is *so* much better is that you don't really have
>to worry about code size.  The pointer problem that occured with 8086/8
>doesn't exist.  
>
>	The 68000 and 68010 do, however, limit the address space for 
>PC relative operations.  Does MANX's flag for PC-RELATIVE addressing
>on absolute calls require that the code be smaller than 32K? Or will
>it employ some sort of relative jump table for calls beyond the addressing
>range?
>
>					-Matt

Exactly. A jump table is built in the data segment to handle the case of
the overgrown code segment (more than 32k), and even that is only necessary
for cases where pc-relative goes beyond 32k away. (i.e., it is only used in
those cases, not for all accesses).
Data segments, however, are limited to 64k in small model. Data are accessed
by 16-bit offsets from a pointer to the *center* of the data segment.
I suspect that the new Lattice approach is similar, if not identical to this
method.

I fully agree with your comment about the 8086 requirement for 4 memory
models. I've been there. However, I'm not quite so uncomfortable with this
approach, for a couple of reasons. First, of course is the ability to use any
size code segment with small code model (as described above), even if it
does require the overhead of the additional level of indirection. 
For really large programs, you may be able to arrange modules to minimize 
the references to routines more than 32K away, though I realize this would 
be time consuming and (yeech) a manual operation. Second, you can mix and 
match large and small model code and data in any combinations you wish. 
(i.e., you don't have to have large code to get large data model).

Now the bad news (there had to be some). The libraries were compiled using
small code, small data. So what do you do if you want to use large data
model to get a data segment larger than 64K? You have two options one of
which is rather messy, the other only slightly messy. The messier one is to
re-compile the libraries (implies you have bought the commercial version).
The less messy one is to just go ahead and use the libraries as is.
What the linker does in this case is to generate the data segment with 
A4 pointing to the middle of it, no matter how big it is. Of course, any
references from small data modules will have to be within 32K of the center
of the data segment. This may require some tweaking (the messy part) to get
modules linked in the right order, but at least it *should* work, unless
you've got more than 64k of "small" data, in which case I suppose you have
to revert to the first solution.

Yes, I know, this is not an ideal solution. I feel that an ideal solution
would have to be a) completely transparent to the user, and b) always "know"
when to do what to generate the best (read "smallest and fastest") possible
code. (I'm sure there are other criteria I'm missing, but those two are
tough enough to meet). But for (perhaps) 95% or more of applications, there 
may well be no problem. 

Phil Staub
Tektronix, Inc.
ISI Engineering
P.O. Box 3500
Vancouver, Washington 98668
C1-904, (206) 253-5634
..tektronix!tekigm!phils