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-----*/ /*------------------------------------------------------------------------*/