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

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



No, it's not a stupid question at all. I had the same
first thought when I read the posting. You may just
have a need for a seperate stack for the scheduling
handler.

JG


On Tue, 23 Jul 2002, Nicolas Boulay wrote:
>
>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/