Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!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: <534@sas.UUCP>
Date: 6 Jun 88 13:16:43 GMT
References: <8805182223.AA20918@cory.Berkeley.EDU> <2653@louie.udel.EDU> <10507@agate.BERKELEY.EDU> <2085@sugar.UUCP>
Reply-To: toebes@sas.UUCP (John Toebes)
Organization: SAS Institute Inc, Cary NC
Lines: 48

In article <2085@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>If you're using the variable frequently in a routine (say, in a loop) it should
>store the address of the variable, or the base address of the array, in a
>register. If not, then who cares how you get to it?
>
>That's why I was talking about having registers allocated on the fly, instead
>of dedicating A4 to ALL global data.
Have you tried what you are suggesting?  I have.  It is a general problem on
the 370 for which I have worked on a C compiler.  With the general philosophy
of C code you come out BEHIND.  Just take a second and THINK about it.

Externals must be addressed in some manner.  If you are going to get the
address of the external, it will cost you 6 bytes to load it into the
register (2 bytes for the instruction plus 4 bytes for the relocated address)
Now assuming that on the average you address 5 external variables in a
subroutine, that is a minimum of 30 bytes PER SUBROUTINE of additional
overhead that cannot be eliminated in any way.  Without a GLOBAL PROGRAMWIDE
optimizer, this cost cannot be spread out among modules resulting it this cost
being given to almost every subroutine.  (If you want such an optimizer, I
hope you have a long time to wait for it to finish on any reasonably sized
program).

Note that in general references to EXTERNALS are sparse such that
only one or two modifications/references occur in a module.  With a program
that is written to be reentrant, this issue is completely moot BECAUSE there
are no externals.

Again, I suggest that you research your subject.  If you had then you would
recognize the other areas that could benefit compilers in general.  I spend
a lot of effort and time in improving our compiler technology by looking at
real live user programs and general coding philosophies.  When you see what
type of code is really written you get a feel for what makes sense to
implement and what is theoretical hogwash.

>Not at all. You apply this optimisation to the routines you know are local:
>that will be in the same load module. You're going to want to make long jumps
>outside that load module anyway, since it could be scatter-loaded anywhere.
>You *do* want to scatter load: it can make the difference between having your
>code run or not when memory is tight.
What you are referring to is already in BLINK in a general form that does
not limit itself to just compiler geneated code. ALVs are constructed to
perform any necessary bridging.  The compiler has always generated short
calls for subroutine branches.

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