| ??? 03/04/05 07:39 Modified: 03/04/05 07:48 Read: times |
#89075 - native doing Responding to: ???'s previous message |
hi,
Craig Steiner said:
It would seem that when the "Bible" refers to SP first being incremented, all it really means is that if SP=7, the value pushed into IRAM 08h. But three different derivatives produce 07h so it would appear the value to be pushed is read before the stack pointer is updated. The matter of this behaviour depends on how does derivative really do instruction in hardware. During execution, instructions are split into micro-codes each one of which is the fixed state of hardware state machine. All micro-codes are put into stream and then fetched and executed at clock ticks. For example, MOV location1,location2 may not be executed in a moment. Physicaly state processor needs to take value of location2 from code fetch engine and load it into RAM address register. Then it does read RAM cycle and puts result into temporal buffer (by the way, look at typical 8051 diagram and you may find TMP1 and TMP2 internal registers). Next step of state processor is loading value of location1 from code fetch engine to RAM address register. Finally, it does write RAM cycle and places value of temporal register into RAM location. Now let look what happens for PUSH SP. I think the answer is in question: how is stack pointer register implemented in hardware? If it is separate up/down counter then probably you will get 8. If it is just a part of memory like rest SFRs then probably you will get 7. Come to hardware state machine. SP needs to be incremented. But hardware cannot increment RAM location directly (even SP may be just a register accessed via common system address/data bus). So value of stack pointer is loaded into temporal up/down counter (probably located in ALU), incremented and the new value is loaded back. Okay, but at this time when ALU does own work, common bus is free. So hardware state machine prepares data to be pushed, here: reads value of SP location into temporal buffer. Once again - it must be done because hardware may not direct load from one to other location over common data/address system bus. The rest process is clean. Incremented stack pointer is used to put its own (but old!) value into stack area. In case when SP is implemented as separate up/down counter the process may be different. Hardware state machine just send one clock to + input, then reads value of SP into temporal buffer. Then content of up/down counter is used as RAM address pointer where value of temporal buffer must be loaded in. By the way, all above is IMHO. Do not rely on that (= Regards, Oleg |
| Topic | Author | Date |
| PUSH SP | 01/01/70 00:00 | |
| 8 | 01/01/70 00:00 | |
| 8??????????????????????????????????? | 01/01/70 00:00 | |
| On jokes, reasons &al. | 01/01/70 00:00 | |
| no, you don't | 01/01/70 00:00 | |
| I do not know and do not think I should | 01/01/70 00:00 | |
| Non-compliance? | 01/01/70 00:00 | |
| Theory vs. practice | 01/01/70 00:00 | |
| Jan is right: 7 | 01/01/70 00:00 | |
| I did not say 7! | 01/01/70 00:00 | |
| Interesting | 01/01/70 00:00 | |
| POP SP? :-) | 01/01/70 00:00 | |
| POP SP | 01/01/70 00:00 | |
| MOV SP,#SP | 01/01/70 00:00 | |
| exceptions and rules | 01/01/70 00:00 | |
| MOV A,ACC | 01/01/70 00:00 | |
| xxx a,acc | 01/01/70 00:00 | |
| if the "Bible says"... | 01/01/70 00:00 | |
| more interesting | 01/01/70 00:00 | |
| Hmmm.... interesting indeed! | 01/01/70 00:00 | |
| native doing | 01/01/70 00:00 | |
| Makes sense to me | 01/01/70 00:00 | |
| POP SP | 01/01/70 00:00 | |
| Output of SP | 01/01/70 00:00 | |
| Simulators | 01/01/70 00:00 | |
| simulators give me 7 7 | 01/01/70 00:00 | |
| 7 7 | 01/01/70 00:00 | |
| spent for which purpose | 01/01/70 00:00 | |
| Fun... | 01/01/70 00:00 | |
| Atmel and Philips | 01/01/70 00:00 | |
SiLabs F120 | 01/01/70 00:00 |