Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!bbn!rochester!cornell!uw-beaver!ubc-cs!alberta!myrias!cg
From: cg@myrias.UUCP (Chris Gray)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Another question on the 80286- er, 68000 memory models
Message-ID: <610@myrias.UUCP>
Date: 9 Jun 88 19:25:13 GMT
References: <8805182223.AA20918@cory.Berkeley.EDU> <2653@louie.udel.EDU> <2869@polya.STANFORD.EDU> <2069@sugar.UUCP>
Reply-To: cg@suncg.UUCP (Chris Gray)
Organization: Myrias Research Corporation
Lines: 55

>Article 1035 of comp.sys.amiga.tech:
>From: peter@sugar.UUCP (Peter da Silva)
>In article ... rokicki@polya.STANFORD.EDU (Tomas G. Rokicki) writes:
>> Let's get this all straight.  There are three independent things
>> that affect the `model' on the Lattice and Manx compilers:
>> 	* data addressing.  This can either be 32-bit absolute
>> 	  or 16-bit relative.  *Pointers are 32-bits in either
>> 	  case*.
>This sounds more like a job for Mr. Optimiser than something the programmer
>should have to deal with. You would have as many or as few base registers
>as you needed to get quick access to the data, allocated and set up as needed
>within the procedure, block, or even statement for which it's appropriate.
>
>No need for a memory model, unless you're used to doing things the intel way.
>The whole A4 business is an obvious copy of 8086 small data models.

The problem is that the same data must be accessible from everywhere in the
program (except for statics, which are more restricted). Your idea of cacheing
a pointer to somewhere in the globals has merit - I think I'll look at putting
something like that in my Draco compiler (I'm into optimizing right now). Note,
however that a solution like that will never be as efficient as a program-wide
convention of having a single register always point into the globals. For most
programs, the pointer-to-globals technique works, and can produce significantly
faster/smaller code.

>> 	* code addressing (jsr's.)  These can either be 32-bit
>> 	  absolute or 16-bit relative.  Again, you can mix
>> 	  models.
>And again, this is an optimisation that should be applied to all code. The
>UNIX *assembler* on the PDP-11 did this: you just specified that you were
>branching, and it'd generate either the short branch or the long branch
>depending on how far away the destination was. Surely a compiler can do this
>within a routine and for calls to static globals.

The decision as to whether to use a long or short branch can only be made when
the location of the target is known. With the Amiga's scatter loading, this
isn't known until program load time. If the target is too far away, a 32 bit
address may be required, so if the compiler has put in a 16 bit offset only,
someone will have to fake it (which is what both Lattice and Manx do). The
decisions done by the UNIX assembler were for a single assembly (one .c file)
only - interfile references were all long mode. Any compiler worth its salt
will use a short PC relative branch within a function whenever possible.
(Draco doesn't yet, but it's coming :-) )

Further comments about int sizes deleted.

Compiler writers are often in direct competion with one-another. One area of
competition is the speed/size of the generated code. Any technique by which
a compiler can be "improved" in this respect is considered fair game. Given
two identical programs, one compiled with a fully "large model", and one
compiled with a fully "small model", the latter will be smaller and faster.
Which one would sell better? Which one would you keep on your machine?
-- 
Chris Gray		Myrias Research, Edmonton	+1 403 428 1616
	{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg