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

Re: [f-cpu] Stack handling




----- Original Message -----
From: "Thomas Lavergne" <thomas.lavergne@laposte.net>
To: <f-cpu@seul.org>
Sent: Wednesday, July 24, 2002 6:46 AM
Subject: Re: [f-cpu] Stack handling


> > Please take into account that a SW-managed stack is an excellent
> > place for doing optimisations. What is written in the last manual
> > is a big issue for F-CPU : the unique function return address
> > register is a critical "bottleneck" because a pointer can't
> > be moved to another register (the value can, but the hidden
> > flags won't be moved, so the next use will create a stall
> > during maybe 5 or 10 cycles).
>
> Ok, but this call convention was only for inter-language call, so not
> the most common, generally most of the call was made inside the programm
> and the compiler could optimize register allocation for return address.
>

It reminds to me that AMD Athlon uses an internal 12 entry return-address
stack to speedup 'retn' .

So your proposal is having several return pointer registers instead of one ?
for static functions it isn't a problem but for public functions it is.
Because everytime you need to enter a function in a function, you will need
to know which register to save. But how the caller can know which
return-address register to save since it can be called by anyone ?

> > I think and know that there are several "inconsistencies".
> > but the key is to NOT think like with usual CPUs.
> > Ask yourself : what the CPU has to do and what is the simplest,
> > fastest way to perform the task.
>
> If you want to make thing in the simplest way you need a stack, because
> most compiler was based on a stack and if you have few function call
> imbricated with some expression evaluation you quickly overflow a
> register stack and you need to store data in memory and stack is the
> simplest way to do this.

With optimized compiler, stack should be in last resort. But the fact (look
at the code generated by gcc), a lot of registers is saved in stack. It is
not a matter of limited number of registers but the necessity that some
registers need to be inchanged thru a function call (the callee will save
these registers at enter and restore them at exit). Having one or several
stacks changes nothing, we always need an temporary memory for saving those
registers and the bottleneck remains.

>
> > F-CPU is not MIPS : r63 is not hardwired in the instructions
> > when a call or return is performed. We have the choice of using
> > 63 registers for storing the return address. 8 of them can be used
> > "statically", whatever their number, to reduce the re-fetching overhead.
> > Same for data. It is simpler and faster to allocate 8 data and
> > 8 instruction pointers, rather than trying to reuse the scheme
> > used by other CPUs "because that's all people are used to".
>
> I'm ok, but I don't want to remake thing made in other cpu, I just want
> to make a call convention that will be easy to use for most languages.
> But I'll agree with you for internal call in programs.
>

Sometimes I wonder if you are aware of the problem arised with the multiple
instruction pointers... for public code, you still need to save one of those
multiple instruction pointer because we cannot be sure that our public
functions that we call in our function use or not the same instruction
pointer !!!

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/