already in SV mode. Second, when you do trap #0 and get to the 'set_ssp' function, forcing the SV mode in the save SR stack will cause havoc once the RTE instruction executes. Why? Because now you use the SV stack in user code after the SR is reloaded and the user stack is just lost. Bad! Bad! Bad! ;-)Odd, you've got it, many thanks! Finally someone who took a look at the code
But has he, really? I have nothing against being proved wrong, but...Odd's wrong (or very unclear) on one point, which is that the user stack would somehow be 'lost'. The user stack pointer will stick around forever in the register that is now (in supervisor mode) called USP, and will return to being A7 whenever the supervisor bit in the SR is cleared. There is no need to reload anything, since the register has contained the same value all the time. (At least all 680x0 documentation I've seen state that which A7 is "active" depends on nothing but the SR bits. It's also the only thing that makes any sense.)
That said, it is obviously not a terribly good idea to actually use the supervisor stack from user code (note, not user _mode_ code). But would it really be a problem (assuming you only use very little of it, since it's obviously usually a smaller stack than the user one, and interrupts would still be using it) under MiNT, since it doesn't do task switching when in supervisor mode, anyway? Or does MiNT perhaps modify the supervisor stack pointer (it uses per processes SV stacks, IIRC, but I don't know what it does if the process is already running in supervisor mode) on schedule interrupts, before deciding that it should just return to the same task? I can imagine that being a cause for problems in this case, if MiNT tries to use its own stack (an application in supervisor mode via Super() etc, would have another, but in this Trap#0 case it would be the same).
Further, I wonder how memory protection on or off could in any way affect this. It either shouldn't work at all, or always, unless something non-obvious is going on. But, of course, the "working without memory protection" case might be overwriting some memory somewhere. Still, IMO, the question remains why that would happen.
-- | Why are these | johan@klockars.net | .signatures | | so hard to do | http://www.klockars.net | well? | (fVDI, MGIFv5, QLem)