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

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



If you want to invent a new OS which doesn't need a stack, well okay. But my
oppinion is that you would need to be friendly with software programmers and
don't complicate their jobs because you only think about the hardware part
without any regard about the habits of programmers.

I really understand the whys you prefer to avoid a pre-increment/decrement,
but the fact is there are situations we need it.

Stacks must be used with minimal intents. Having too much stacks can lead to
a bad ressource handling (lot of memory wasted) and a lot of cache miss
(stack is used as a temporary memory so functions should reuse the same room
when not embedded).

By the way, i was not speaking about the stack for OS but about the user
signal handler which is a simple C function to call in the owner process.
You can still give it another stack, but you need to allocate one (wasted
ressource), need to know which register for stack pointer to use (gcc knows
only one), or use a stack-pointer switching (where to save the old stack
pointer ?), etc. Do you really want to have Linux works on your F-CPU ?! why
to do things more complicate when one user process stack is enough to handle
this handler ?

----- Original Message -----
From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
To: <f-cpu@seul.org>
Sent: Tuesday, July 23, 2002 1:22 PM
Subject: Rep:Re: [f-cpu] Stack handling


Maybe it's a stupid question, but why it's forced to try to simulate a
simple stack. There is no hardware support for stack in the f-cpu. Why
not using a completely different pointer for such things ? Why must we
stuck to the use of one single stack ?

nicO


-----Message d'origine-----
De: "Christophe Avoinne" <christophe.avoinne@laposte.net>
A: <f-cpu@seul.org>
Date: 23/07/02
Objet: Re: [f-cpu] Stack handling

Was it possible that nobody never saw that problem !? so no one found a
workaround to avoid pre-increment/decrement and still thinks he can use
'push' and 'pop' without pre-increment/decrement ?

Well I can see two workarounds :

1)
        push ...
        push ...
        push ...
        push ...
        ...
        addi 8,r3,r3 // we need to point on the last pushed word for
popping
properly
        pop ...
        pop ...
        pop ...
        pop ...
        subi 8,r3,r3 // we need to adjust stack to avoid leaving a word
hole
after popping

Just imagine a interruption occurs between the last pop and subi, and
for
some reasons we push in the stack, we are corrupting the stack with the
first push because we are crashing a pushed value no matter where it is.
In
fact the problem is the same for the other pop too.
| POPPED |
| POPPED |
| POPPED |
| POPPED | <- interruptions occurs
| PUSHED | <- r3 is pointing here when interrupted, this word instead
the
last popped is likely to be crashed if a push occurs.
| PUSHED |
...

So you understand why a lot of CPU has the pre/post-increment/decrement
to
be atomic with this regard.

Of course, some people would argue interruption cannot do that. Just an
idea, you want to use unix signals. That means you want to run
asynchronously signal handlers. How to do that ? let us try SIG_ALARM. A
timer interruption raises. It sees there is a signal to send to a
process,
so it installs a user interrupt (what matters how) in the given process
so
the latter can execute the alarm handler. Of course, this alarm handler
is a
normal C function which is likely to push some registers in the stack,
usually in the same stack of the interrupted application of the same
process. Well corruption due to a bad design for stack operations.

2)
        subi 8,r3,r3 // we need to adjust stack to avoid leaving a word
hole
        push ...
        push ...
        push ...
        push ...
        addi 8,r3,r3 // we need to point on the last pushed word for
popping
properly
        ...
        pop ...
        pop ...
        pop ...
        pop ...

The same problem still occurs after each pop.


----- Original Message -----
From: "Thomas Lavergne" <thomas.lavergne@laposte.net>
To: "FCpu English" <f-cpu@seul.org>
Sent: Tuesday, July 23, 2002 6:42 AM
Subject: [f-cpu] Stack handling


> I've reread the manual and found a problem in stack handling
suggestion
>
> The manual say :
>
> pop = load 8, r3, r2
> push = store -8, r3, r2
>
> With r3 a stack pointer and r2 a value to be pushed/poped to/from the
stack.
>
> but this was false, for example try to make :
> push r2
> pop r2
>
> you obtain this code
>
> store -8, r3, r2
> load 8, r3, r2
>
> you push r2 at r3 address and increment r3,
> and after you get in r2 the value at r3 and decrement the pointer
> so after executing this you don't have the same value in r2... Bug
>
> We can't manage a stack without pre-decrement instruction, or we need
a
> lot of tricks and obtain very bad code...
>
> Tom
>
> --
> Thomas Lavergne                       "Le vrai rêveur est celui qui
rêve
>                                         de l'impossible."  (Elsa
Triolet)
> thomas.lavergne@laposte.net
> d-12@laposte.net    ICQ:#137121910
http://assoc.wanadoo.fr/thallium/
>
> *************************************************************
> 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/