[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] More Instruction Set Trouble



On Sat, Aug 18, 2001 at 10:09:39PM -0400, Lee Salzman wrote:
[...]
> >Unfortunately, the term `general case' means four(!) successive loadcons
> >instructions (or similar).  There is no way to optimize one or two of
> >them away because the compiler/assembler doesn't know which value is
> >loaded.
> 
> The linker can handle whatever optimizations are necessary for efficient
> relocations or else it is a very sad linker indeed. If this means
> providing several alternatives patches of code to fill in depending
> on the distances, then so be it. Too much focus has been put on
> optimizing at compile time traditionally when it is quite beneficial
> to do it at load time. The distances between code and data sections 
> are very well known at this peculiar and oft ignored time.

Linkers cannot insert code when necessary, nor can they remove
superfluous instructions.  They can just overwrite them with something
different.

> >You might say: "use PC-relative addresses".  But that doesn't work
> >either -- in fact it's even *worse* than using the absolute address
> >because you need four loadcons instructions to put the relative address
> >into a register, and then you still have to execute loadaddrd (that is,
> >you need one instruction *more* for relative addressing).
> 
> I don't see why you couldn't just use loadraddrid here and fall back
> to loadaddrd if the distance is too large.

Because it makes almost no difference.  You have to provide space for
the longest possible load sequence, and fill it with NOPs or similar
when a shorter sequence is used.  Bigger code, longer delay.  Besides
that, it makes the link editor more complex; I'd rather not do that.

> >The same is true if you use a `base' register that points to the
> >beginning of the data section and calculate the distance to that point.
> >You still need 4x loadcons + 1x add to get the variable's address (and
> >yet another instruction if you want the data to be prefetched, because
> >`add' doesn't do that).
> 
> The distance of the variable from the current PC is easily calculated
> at load time so a loadaddrid can be use great utility here, as has
> been noted.

How many programs do you know that fit into 128K (including the initial
working set)?  My /bin/bash needs >400K (on ia32 -- that's CISC, not RISC).

> >A module-local base register is also possible, but you'll have to save,
> >set and restore it in every function that is not module-local (e.g. has
> >`extern' linkage in C) and uses global variables -- and you need the full
> >`quadruple-loadcons' instruction sequence again each time you access a
> >global variable that belongs to *another* module (just in case it isn't
> >clear: `module' means `source file').
> 
> Not quite... a function need only have two entry points - one entry
> point is module local and does nothing while the other is for the
> non-local
> case and sets the current module. Calls to non-local functions are
> responsible for setting the current module after the non-local function
> returns. This allows for efficient local calls that pay no penalty at
> all.

That bloats external function calls with `base restore' operations.
But the idea is interesting.  Gotta think that over.

> Additionally, one should not neglect the effectiveness of redundancy
> elimination when applied to constant loads.
> 
> When that fails... hasn't anyone told you that global variables are
> evil anyway? :)

I learned LISP ~20 years ago.  (questionsp 'any)

There is also constant global data.  String constants, for example.
Or jump and lookup tables.

> >Any other ideas how we can reduce/avoid the `address load penalty'?
> An add coupled with a prefetch for data address loads off a
> base/module register would be very nice. Possibly an immediate add
> that some how supported longer immediate constants would be nice too,
> but that could be done without.

The `address add' idea looks better and better, and it's good for
pointer/array/structure accesses, too.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/