SATNKernel

You don't understand the issue. When using an interrupt stack, no task stack space should be used by interrupt handlers. This is not possible on SH2. Even worse, there is an unavoidable small window at the start of every ISR where a higher-priority interrupt can pre-empt the running ISR before the stack pointer can be adjusted. This means the higher-priority interrupt's stack frame will also be pushed onto the user stack, and so on until you reach the highest priority level.

Other architectures solve this by banking some or all of the registers (eg. 68000, ARM) or by automatically disabling interrupts when entering an exception handler (eg. MIPS, SH3/SH4).

Try reading the source in question, maybe you'll figure out what we're talking about.
 
antime said:
I may be misremembering, but wasn't the rumour at one point that the original design used NEC CPUs (probably a v810 or similar) and that the switch to Hitachi was more or less done as a personal favour to their chairman?

According to an article in Special Issue 10 of Edge, the Saturn's original design had a single 16MHz NEC V60, the same CPU used by Sega's System 32 and Model 1 boards (and a number of boards from other manufacturers). The design was changed after Sega got hold of the Playstation's design specs, and the dual CPU configuration was chosen as an affordable way of getting performance using off-the-shelf parts. However, the article claims that Sega's then-CEO Hayao Nakayama personally picked the SH2, "it later being rumoured this was a favour to an old golfing buddy."
 
antime said:
You don't understand the issue. When using an interrupt stack, no task stack space should be used by interrupt handlers. This is not possible on SH2. Even worse, there is an unavoidable small window at the start of every ISR where a higher-priority interrupt can pre-empt the running ISR before the stack pointer can be adjusted. This means the higher-priority interrupt's stack frame will also be pushed onto the user stack, and so on until you reach the highest priority level.

Other architectures solve this by banking some or all of the registers (eg. 68000, ARM) or by automatically disabling interrupts when entering an exception handler (eg. MIPS, SH3/SH4).

Try reading the source in question, maybe you'll figure out what we're talking about.

I understand completely, I just don't see the problem. So you wind up with (possibly) a few hundred extra bytes being used on the task stack by int handlers. Big whoop. It's not like the Saturn is going to be trying to spawn hundreds of tasks. A typical usage would have at most two or three tasks running. Just remind authors that on the SH2, int handlers may be using the task stack, so don't go crazy on the local variable usage and leave it at that. Problem solved.
rolleyes.gif


You're conflating a problem for a SERVER with a small embedded system. Even if someone wanted to "go wild" with int handler overhead, it could easily be handled by changing the stack within the handler before going wild. If the handler needs tons of space, add a stack to the handler struct and switch to it before calling the handler. If a handler is just going to need space for saving used registers, there's no need for that... plenty of room on even a small task stack.
 
Chilly Willy said:
You're conflating a problem for a SERVER with a small embedded system.
It's precisely the smaller systems (like the SuperH controllers with 4KB instead of Saturn's 2MB) where this would turn into a major problem.
 
ExCyber said:
It's precisely the smaller systems (like the SuperH controllers with 4KB instead of Saturn's 2MB) where this would turn into a major problem.

Well, let's take a look... an interrupt happens and we get the PC and SR pushed on the stack. The processor fetches the address from the exception table and jumps to it. 8 bytes on the stack at this point. The exception handler pushes one register on the stack, then uses it to disable interrupts. We now have 12 bytes on the stack. IF another higher level interrupt occurs, we have at most 12 bytes on the stack. Now at worst, it puts another 12 bytes on the stack before it can disable ints. If ANOTHER higher level int occurs, we might get another 12 bytes. Do I have to point out how astronmical the odds are that higher level ints will occur in just the right order at just the right time? I hope not. So you might add a couple dozen bytes to the task stack AT WORST before you can switch to an interrupt stack. BIG F--KING WHOOP.
angry.gif
/>/>

End of discussion.

Let me show you where the REAL stack issue lies. I helped a person debug his PSP demo... he was porting a popular physic package to the PSP and all the simple examples were exploding instead of working while he found absolutely NOTHING wrong with any of the code. And there was ABSOLUTELY NOTHING wrong with the code... the problem was the current stack created for tasks on the PSP was 64KB. The examples were using anywhere from 100KB to 1000KB of stack space for local variables. The examples were running just fine, right up to the point the stack ran out of memory. This is even more of an issue for the Saturn given the small amount of ram, and much more likely to occur than any exception/interrupt stack space issue.
 
Chilly Willy said:
So you might add a couple dozen bytes to the task stack AT WORST before you can switch to an interrupt stack.

Worst case is 244 bytes wasted per task (4 words for each priority level + 1 for the outermost level). I don't understand the point of your posts. I pointed out a flaw in the CPU architecture and you've kept going off on completely irrelevant tangents.
 
Back
Top