Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!pacbell!ames!umd5!uvaarpa!mcnc!rti!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Another question on the 80286- er, 68000 memory models
Message-ID: <527@sas.UUCP>
Date: 3 Jun 88 17:33:50 GMT
Article-I.D.: sas.527
References: <8805182223.AA20918@cory.Berkeley.EDU> <2653@louie.udel.EDU> <2869@polya.STANFORD.EDU> <2069@sugar.UUCP>
Reply-To: toebes@sas.UUCP (John Toebes)
Organization: SAS Institute Inc, Cary NC
Lines: 91
Summary: No cigar...  Memory models are for the 8086

Let me comment ahead of time.  I think that we are off base calling the
compiler options 'memory models', but read on...
In article <2069@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>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.
Wrong.  The A4 business is straight out of the Motorola data books from
looking at the timings and sizes.  The concept of a single register to address
data comes from many machines including Apollo and Macintosh - both 68000
machines.

Using A4 as a base register has other implications that are much
more important.  Because of the C language definition (and even Modula2)
you do not have any idea of the total amount of data that a program might
contain.  Given this, the code must be generated knowing AHEAD of time
how big the data is going to be.  The ONLY real optimization that can be
done to do this without the programmer giving information ahead of time is
to delay generation of code until link time.  There are indeed articles
discussing this type of optimization, but it is far from acceptable in
performance for a simple piece of information.  The word here is 'TRADEOFF'
you EITHER have the programmer specify that he has more than 64K of data
or less than 64K of data and the compiler does its work from that OR
you have the compiler figure it out by trying to compile everything one
way and the let the linker REDO all the work later on (as expensive if not
more so than recompiling everything a second time). 

Perhaps you should spend some time studying the subject first.  I have
done quite a bit of research into what can be done on optimizing code -
4.0 should be evidance of that.  Optimizers only tend to clean up BAD and
sloppy code, the best improvements in speed of a program come from
ALGORITHIMIC [sic] improvements and general code generation strategies.
Compiler technology being researched and written about currently includes
more global application wide optimizations that take advantage of profiling
and inter-procedual data flow analysis.  These are not cheap optimizations,
figures of 100 lines per minute occur in the literature frequently.
>Use it, but keep on your vendor's tail about doing it right.
Which means encourage them to do exactly as they are.  Unless you are
advocating INCREASING compilation (actually link) time.  I was under the
impression that people don't want to wait for the compiler - no matter
how good a code it can generate.  Besides, this is one switch that has a global
positive impact for a simple user choice.
>> 	* 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.
As it is by default for Lattice.  However, you seem to neglect the fact that
there are at times that the code is large enough that the fixups take up
more space than using the long branches.  Unike Manx, Lattice does not treat
this as a 'model' allowing you to freely mix the code without any concern.
The linker will patch up any addresses out of range, BUT the user must be
able to disable this if it gets to be too unwieldy.
>> 	* int size.  Both Manx and Lattice allow 16 and 32-bit
>> 	  ints.
>
>This is the only case that I know of for which the concept of "models" is
>appropriate. This is also the case that bites everyone.
'models' is the wrong word here.  A model IMPLIES incompatibility between
the choices for compilation options.  With the Lattice, you can quite readily
mix ALL of the code generation options within the same compilation.  The
only concern comes when you are calling between short/long integer default code
to ensure that it is using the correct parameterization.
>> Someone please correct me where I'm wrong.
>You're not wrong, just too willing to make allowances for 8086 mentality.
The only 8086 mentality here is trying to equate the models.  What we have done
with the Lattice 4.0 compiler is completely unrelated to any other machine.
Each code generation option was designed to take advantage of a feature
pointed out in the MOTOROLA data books.  If we had an 8086 mentality, you
wouldn't be able to mix the code generation options so freely (I can't comment
for any other compiler vendors).  Also, we would have to wack off half
the pointers to give the extra level of frustration :-)
Are you suggesting that we spend more time trying to mimic the 8086? ;-)

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/