Page 1 of 2

Manual should specify what RTI does outside of an ISR

PostPosted: Sat Dec 14, 2013 6:21 pm
by alexrp
Issuing the instruction outside an ISR obviously makes little sense, but what should actually happen? This is not currently documented.

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Sun Dec 15, 2013 4:06 am
by over9000
alexrp wrote:Issuing the instruction outside an ISR obviously makes little sense, but what should actually happen? This is not currently documented.

I imagine that what happens is the same as on any other CPU. The CPU doesn't "know" that it's inside an interrupt handler routine. It just sees the "return from interrupt" instruction and does a "return from subroutine"-plus (pop any registers that were automatically stashed by the interrupt, such as previous status register and the like). If you really need to know, just look at the stack frame within your interrupt handler... you can set up a busy waiting loop in a known area of memory then after triggering the interrupt, scan up the stack until you hit a known memory address. Copy it out into a static area, send an off-chip signal and halt the core. Something like (pseudocode):

On this core:

set up interrupt handler on core
call label (sentinel on stack)
label: jump to label (ie, this instruction)

On another core (delayed long enough to activate during busy wait loop):
send software interrupt to core we're testing.

ISR:
scan up stack until we find label
send memory area from current stack pointer down to original SP to main memory
halt core

I haven't checked, but I'd be surprised if the stack frame during an interrupt wasn't documented...

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Sun Dec 15, 2013 10:45 am
by timpart
over9000 wrote:It just sees the "return from interrupt" instruction and does a return from subroutine"-plus (pop any registers that were automatically stashed by the interrupt, such as previous status register and the like).


My reading of the manual suggests that the interrupt doesn't stash anything - that has to be done entirely "manually" by the interrupt service routine. There aren't even any clones of some registers you can use.

The only ambiguity I can see from the description of the RTI instruction is whether any IPEND bit would get cleared if there was no current interrupt.

The rest seems straight forward. Interrupts are enabled and the processor jumps to whatever address is in IRET. Unfortunately IRET will contain whatever random point in the code the processor was at when last interrupted. So RTI outside of a service routine gives the processor an attack of deja vu which will probably be fatal to your program.

Tim

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Wed Dec 18, 2013 2:57 pm
by tnt
I'd also like to point out that "Not specified" can be on purpose. That can mean the behavior should not be relied upon and can be subject to change in future silicon revisions.

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Wed Dec 18, 2013 6:56 pm
by alexrp
tnt wrote:I'd also like to point out that "Not specified" can be on purpose. That can mean the behavior should not be relied upon and can be subject to change in future silicon revisions.


That's fine too, but then the manual should be explicit about it.

I may be somewhat demanding, but it's very hard to correctly simulate Epiphany at the moment because these things are not well-specified. You can't really know if it's an omission, or if it's undefined behavior, or if it'll raise an exception, and so on...

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Wed Dec 18, 2013 8:47 pm
by aolofsson
alex,
As tim and others guessed, the RTI instruction does not care if the program is in an ISR or not.(as a lowly hardware designer I had to think about what that meant:D)

This is what happens when an RTI instruction is executed:

1.) the PC jumps to the address in the IRET register

2.) status[1] is cleared, enabling interrupts

3.) The IPEND bit of the ISR currently being executed is cleared. If the IPEND register is all zero (no ISR), there is nothing to clear.

4.)...undocumented, untested, and unsupported....status[2], user/kernel mode is set to user mode=0. (you can probably ignore this for now, I can give more information if someone thinks a user/kernel mode might be useful..) To enable user/kernel mode, set bit [25] of the CONFIG register.

Andreas

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Wed Dec 18, 2013 10:22 pm
by alexrp
aolofsson wrote:alex,
As tim and others guessed, the RTI instruction does not care if the program is in an ISR or not.(as a lowly hardware designer I had to think about what that meant:D)

This is what happens when an RTI instruction is executed:

1.) the PC jumps to the address in the IRET register

2.) status[1] is cleared, enabling interrupts

3.) The IPEND bit of the ISR currently being executed is cleared. If the IPEND register is all zero (no ISR), there is nothing to clear.

4.)...undocumented, untested, and unsupported....status[2], user/kernel mode is set to user mode=0. (you can probably ignore this for now, I can give more information if someone thinks a user/kernel mode might be useful..) To enable user/kernel mode, set bit [25] of the CONFIG register.

Andreas


Thanks!

I would *love* to know more about user/kernel mode. I intend to implement something resembling an OS eventually, so if the hardware has some kind of support for this, it'd be great to know about.

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Thu Dec 19, 2013 1:58 pm
by timpart
Thanks for the info Andreas. I have a more academic curiosity about kernel mode. I'm guessing it write protects certain important register bits. The changing back from user to kernel mode and the RAM bank write protection bits are the obvious candidates.

Alex, there is a separate Epiphany Operating System forum where you may be able to find like minded people.

Tim

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Thu Dec 19, 2013 7:58 pm
by fdeutschmann
Any chance the user / kernel mode status is passed along on off-chip memory access transactions?

Re: Manual should specify what RTI does outside of an ISR

PostPosted: Sat Dec 21, 2013 1:29 pm
by aolofsson
all,
Since there seems to be some indication that it could be useful, I'll write up the chapter about the experimental user/kernel mode and SWI sometime in January after we get the board production solidly underway. Examples of things restricted in user mode include among other things: RTI,GIE,GID, and writing to MMRs.
Andreas