| ??? 06/28/06 16:17 Read: times |
#119272 - Fair point Responding to: ???'s previous message |
You're probably not going to want to do much after a stack overflow trap except to signal that the trap occured and then stop. I've never personally had the luxury of code analysis tools, and I suspect I would not run them on every development code iteration. A hardware stack overflow trap would be there all the time.
Do these code analysis routines know about nested interrupts? |
| 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 |