Re: Rep:[f-cpu] Another proposition for a call convention

[Michael Riepe <michael@stud.uni-hannover.de>]

On Fri, Jun 07, 2002 at 10:58:24AM +0000, Nicolas Boulay wrote:
[...]
> >>> Must we obligatory have one unique stack pointer in C. I have read
> somewhere that the dependancies on this register is really strong
> (typical IPC jump far away without such pointer).

As far as I know, the stack/IPC problem results from the fact that Intel
CPUs update the stack pointer on every push/pop/call/ret instruction,
creating lots of read-after-write dependencies that kill effective IPC.

Intel sucks, doesn't it? Fortunately, not all of Gallia is occupied by
the Intel's. There's a little town... ;)

In F-CPU code, we're free to leave the stack pointer as is (or update
it once on function entry and exit, respectively) and use temporary
registers to access the stack (if we have to do so at all). That is,
we effectively use it as a frame pointer. There is, however, good
reason for an additional, `real' frame pointer - variable length arrays
(standardized in ISO C99) and the function `alloca()' that allocate
stack space dynamically. That is, r62 will point to the FEF (function
entry frame) and r63 to (FEF - <number of bytes allocated>), assuming
that the stack grows downward.

For languages that support nested functions (Pascal-style, but also
GNU C) it would be nice to have a third register that points to the
FEF of the lexically nesting function. But that doesn't have to be a
global register.

The `global pointer' register is an invention of mine; it is supposed
to point to a well-defined address inside the address space of a process
(e.g. at the beginning of the .data segment), in order to ease addressing:
with a global pointer, you can use pointer-relative addressing for global
data (and probably also for code), avoiding time-consuming relocations
at load time (which in turn improves shareability of code pages). An
additional `local pointer' will be useful for shared libraries; but we
can also use one of the `callee-saved' registers for that.

When a program is dynamically linked, it usually has two special data
areas: the `procedure linkage table' (PLT) and the `global offset table'
(GOT). The PLT provides entry points to all public functions while the
GOT contains addresses of public (global) data items. The addresses of
these tables should probably reside in global registers as well (unless
they can be calculated by adding a constant to the global pointer,
which usually is true for at most one of them).

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