push(rx) in Beta

1st of all I do not know Beta's assembler then take my answers as assembler general knowledge knowing that Beta might present some special behavior on these topics..

The first thing you have to know is that some assemblers i.e. x86 have a specially dedicated assembler instruction for push.
push eax ;  it pushes the 32bits content of register eax into the stack.


About incrementing then storing, well it depends on the architecture...

some architectures have a stack that "grows" towards higher memory offsets (like BETA) on those architectures you define the initial stack pointer value as the lowest memory offset the stack pointer will ever hold... let say initial sp = 0x1000

then if you "push 0x0a" considering a 4 byte oriented memory (Beta) you get

address  stackContent

0x1000                            <SP initial position
>0x1001  0x0000000a
0x1002

why the system increments before it assigns is due to the "pop" instruction that retrieves values from the stack (opposite of push)
if you'd push assigning first then incrementing you'd have a problem if you perform a pop operation at the initial stack position, because the systen would try to decrement the SP and then get the value but if you where at the initial stack position and you decrement the SP then that SP points outside the defined Stack area....


Intel architecture handles the stack the opposite way
you define the highest SP address and every push first decrement the SP and then assigns the value...

push al;    pushes register eax least significant byte into the stack

0x0FFE
>0x0FFF  0x0a
0x1000            <SP initial position

Hello pma
Wrt your statement:
" if you perform a pop operation at the initial stack position, because the systen would try to decrement the SP and then get the value but if you where at the initial stack position and you decrement the SP then that SP points outside the defined Stack area..."

When we are into pop situation, if say SP point to initial stack position, that means, Stack has no records, conceptually. i do not think aasembler will not check stack empty before running pop, So,
a) We will not get into such situation where pop runs when stack is empty unless my program has a bug.
b)
1) if u get the value
2) and then decrement
SP will anayways point outside Defined Stack area

Sham

Hello pma
Can you please also look into ID:27186513
Sham

"i do not think aasembler will not check stack empty before running pop..."
this is wrong...
do not make assumptions about stack handling, push and pop are just 2 very simple microprocessor instructions that do not check absolutly anything before execution. Then you very well could pop from outside the stack area w/o  trigger any uP error condition.
You have to see that "we" define the stack area, the uP doesn't know anything about stack boundaries, that's a higher level abstraction that is not handled by the uP but by the programmer instead.

Then the uP designers had to decide if a push/pop operation would be an SP adjustment plus an assignation or the other way arround, then they took the first option because it results a more coherent option, considering stack boundaries issues and also to make the SP always pointing to the last valid pushed value.
You'll see the last one plays an importan role when passing parameters to C functions. but don't get into this now ;-)

Sorry pma, It was typo, I meant control unit will not check in its push/pop logic about boundary conditions.

I still did not understand your point about error conditions, if u refer my point b in my last update

a uP error condition is a mechanism where the uP triggers a special behavior when someting bad happens...

i.e. when you try to perform a division by 0 the uP can trigger a "divide by cero Interrupt", an interrup stops the normal program flow and invoke a special piece of code (Interrupt Service Routine) to deal with the error condition. when the ISR finishes it returns to the interrupted code.

in the case of push/pot thery do not trigger error conditions when the stack pointer points outside the defined stack boundaries.
As I told you the uP doesn't know anything about stack boundaries.


note: all of this is valid for small/simple uP and the explanation is kept simple for you to grasp the uP stack concepts. It does not mean that it couldn't be out there some special uP where you can define let say stack boundaries or things like that...

Hello pma
I totally agree with your point.
But my question is,
Either you
1) if u get the value
2) and then decrement
or
1) Decrement
2) and then  get the value

How does it this handle below scenario as you quoted:
 " if say SP point to initial stack position,"
Sham

the SP points to the initial position and on a growing stack architecture (like Beta) we have

the operation for push is
increment SP + put

the operation for put is
get + decrement SP.

it is not true that poping the initial SP location will always lead to retrieving an undefined value, because you can well define the value of the initial SP position when you set-up your stack. After all an SP location is just a regular memory location...

when you pop from the initial location the SP will end up pointing outside the stack boundarie;, it is up to the progrmmer dealing with SP health....

the operation for put is
get + decrement SP.

should say

the operation for pop is
get + decrement SP.

Hello pma
I did not get your last 2 updates

For Beta architecture, this is what is happening:
To push <x> whic is in rx:
sp <-  <sp> + 1;
ST(rx,-1,sp)


To pop() that same value into rx:
LD(rx,-1,sp)
sp <-  <sp> - 1;

1) Does this approach have any loophole?
2) For push operation above, Do we have any unavoidable reason, for incrementing first and then putting value?
3) For pop operation above, Do we have any unavoidable reason, for getting value first and then decrement the pointer?


Sham

If above is OK

then what is the meaning of:
"if you'd push assigning first then incrementing you'd have a problem if you perform a pop operation at the initial stack position, because the systen would try to decrement the SP and then get the value but if you where at the initial stack position and you decrement the SP then that SP points outside the defined Stack area...."

the problem I describe on your last post it's why among other things uP decided to implement it as pop= SP increment+put.
but if you ask me if that reason is "unavoidable" I have to say "no really".... it is more logical the way that uP designers do but dealing with a uP that implements the oposite stack strategy wouln't be impossible...

then you got the reasons why they do what they do, but those reasons in this case are not "unavoidable"

on a uP if you divide by 0 you rise an error condition; always... because the uP does not handle the concept of mathematical singularity or infinitum; thi is an "unavoidable" reason.

Perfect but you confused me in the middle

sorry.. ;-)

Hello pma
I see that author of Beta says a reason for
ADDC(sp,1,sp)
before
ST(rx,-1,sp)


The reason he says is, if ADDC(sp,1,sp) gets exceuted and the OS scheduler schedules another process

Does that make  sense on these lines?
Sham

from my humble point of view that explanation is not sustainable:

The push and pop mnemonics represent uP "atomic" instructions.
That means they cannot be split on its "componnets" instructions, that means an scheduler action cannot ever stop an executing "push" or "pop" action.

is push literally divided into add and str or does control unit has the proper hardware circuit for complete push operation

the push operation is a hardware opertion, it has it own opcode, it is fetched on a single step, then ,as I said before, it cannot be split in two by a scheduler, when the processor start a push operation it runs it 'til completion

So just for our understanding we are splitting into two?

I do not really know what Beta does...
I do not even know if Beta is a real processor or just a fictitious learning tool...
I think Beta is not good for learning uP stuff
a uP cannot stop a push/pop operation; it would be a serious design flaw, ask your instructor about it...