| ??? 06/26/06 22:51 Read: times |
#119163 - Good rule Responding to: ???'s previous message |
Erik Malund said:
you will put the stack at the top of RAM (more DATA, low stack frce moer IDATA) so why the statement and check if it won't collide with data I'd say that "check if it won't collide with data" is always a good rule. Granted, you won't usually put data after the stack for exactly that reason. But Jan's caveat makes sense and if, by some fluke, data is put in someone's program at the top of data memory and gets clobbered by the stack, this caveat puts the onus on the developer to make sure there isn't any stray data where it wasn't expected. Lest they come back here and say, "Hey, you told me to set the stack to such and such, and it cloberred my data." Now we can say, "Yes, but we also told you to check that it didn't collide with other data." :) Regards, Craig Steiner |
| Topic | Author | Date |
| best practice regarding SP | 01/01/70 00:00 | |
| an easier method | 01/01/70 00:00 | |
| the other way round | 01/01/70 00:00 | |
| as a general rule | 01/01/70 00:00 | |
| Good rule | 01/01/70 00:00 | |
| on stack and data | 01/01/70 00:00 | |
| Estimating stack usage | 01/01/70 00:00 | |
| The future is now | 01/01/70 00:00 | |
| I'd like it also as interrupt... | 01/01/70 00:00 | |
| where would you store the interrupt retu | 01/01/70 00:00 | |
| what return??? | 01/01/70 00:00 | |
| then don't call it an interrupt | 01/01/70 00:00 | |
| OK, call it... exception? | 01/01/70 00:00 | |
| Trap perhaps? | 01/01/70 00:00 | |
| trap! | 01/01/70 00:00 | |
| the root | 01/01/70 00:00 | |
| Fair point | 01/01/70 00:00 | |
| signaling | 01/01/70 00:00 | |
avost? | 01/01/70 00:00 |