Re: Rep:Re: [f-cpu] Stack handling

[Juergen Goeritz <goeritz@oekomm.de>]

On Wed, 24 Jul 2002, Nicolas Boulay wrote:
>>From the beginning we choose that they will be no hardware stack in
>F-cpu. Stacks are always a bottleneck. So this should be left on the SW
>side.

Okay, if it was a main design goal. 

>If you want to avoid the need to save and restore data for call
>convention, we should use windowed register (that could be a great thing
>to decrease memory pressure, because most of the time there is no memory
>access). But the interrupt handler must be really optimised.

Windowed register is some kind of a invisibility handling.
I can imagine to have it be implemented like some ReadOnly
setting of parts of a global register bank combined with a
reordering just on the addressing scheme.

(or use leon :)

To save operations to restore/save of data which is provided
to subroutines I can imagine an offset indication telling
the code that parameters start at register position xy.
Could be great when 256 registers or more are available.
You don't have to copy to specific postitions then but
just make sure that parameters are ascending assigned to
registers and tell the callee where it starts or the other
way round to tell the caller where multiple return data is
starting in the registers.

>For interrupt management, it must have somethings as a lifo to be
>reentrant (nested interrupt). The linked list previously proposed is
>hard for the hardware and hard to be extended.

Linked list is preferably software feature or
for dma units but hardly an processor issue.

JG

>nicO
>
>-----Message d'origine-----
>De: Juergen Goeritz <goeritz@oekomm.de>
>A: f-cpu@seul.org
>Date: 24/07/02
>Objet: Re: [f-cpu] Stack handling
>
>Sorry for the typo - must be lifo of course.
>
>On Wed, 24 Jul 2002, Juergen Goeritz wrote:
>>Apropos call/return saving of return address. I am not
>>really convinced that return address handling should
>>be a matter of the code. As someone mentioned before
>>this requires the need for defining which register
>>contains what data already in a statically fixed manner.
>>
>>The return addresses are the most critical part. If you
>>get wrong data you simply get wrong results but if your
>>return address gets faked the program crashes (I know
>>there are exceptions where it needs fake to circumvent
>>some processor inconveniences - but not f-cpu so far).
>>
>>So why not use a simple fifo type structure onchip for
>>separate return address handling?
>>
>>JG
>>
>>*************************************************************
>>To unsubscribe, send an e-mail to majordomo@seul.org with
>>unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
>>
>
>*************************************************************
>To unsubscribe, send an e-mail to majordomo@seul.org with
>unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
>
> 
>______________________________________________________________________________
>ifrance.com, l'email gratuit le plus complet de l'Internet !
>vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
>http://www.ifrance.com/_reloc/email.emailif
>
>
>*************************************************************
>To unsubscribe, send an e-mail to majordomo@seul.org with
>unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
>

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