What happened to GETINT?
RossH
Posts: 5,462
in Propeller 2
Did I miss something? What happened to the GETINT instruction? It is mentioned in the P2 documentation, but it seems to no longer exist. PNUT doesn't know about it.
Is there a replacement instruction to allow us to get the interrupt status?
Is there a replacement instruction to allow us to get the interrupt status?
Comments
I have temporarily removed it.
Attached is my first attempt at adding C interrupts. As usual, compiled for the P2 EVAL board, serial interface, 230400 baud.
I have included my proposed interrupt header file (which still mentions "getint") ...
There are several discussions about GETBRK, but I can't find anything definitive about what the bits mean. Are they the same as GETINT?
https://forums.parallax.com/discussion/comment/1434024/#Comment_1434024
Hmmm. Not sure that helps. And I thought C code was impenetrable!
Here's my interpretation of the last one: C = 0
Z = 1 if no skip bits set.
result(D register) = skip bits
EDIT: Inverted Z description.
EDIT2: Corrected C as well. I really don't know my verilog.
Edit: Typo & correction.
Yikes!
My verilog is a bit rusty, but looking at it again I read the 32 bits as
Yes, I thought that too - until I realized it meant I had to have two copies of all the library code, and two times as many kernels (and there are 12 of the little buggers already!). One set that could be used in an interrupt-driven system, and one that could not
Have you considered having interrupts use the same stack as regular code? It would simplify things a lot, and be more like other processors.
I was actually mostly using SKIPF in the kernel (i.e. in cog execution mode). But even so, the benefits were becoming more and more doubtful in the cases I was using it.
I don't really like the idea that all stacks have to allow for the possibility of arbitrary interrupt code, when they have no idea how much stack space might be required (I'm thinking primarily of threads here).
The P2 is a microcontroller with limited RAM, not a general-purpose CPU with effectively infinite RAM. Everything needs to be constrained to fixed sizes.
The int_select and int_state registers are not single bits though.
int_select are 4 bits each and int_state are 2 its each.
These are defined elsewhere and not shown in the Verilog snippet.
In the Verilog were referring to we are incorporating elements of these registers.
One day, someone will figure out what the return value actually means and it might prove useful.
LEDs blink if state indicates ISR executing.
Thanks. You can see from this code why the overhead of trying to figure out if you are in an ISR - and you have to check all three interrupts to be sure - makes it not worth the effort in many SKIPF cases.
Sorry I didn't post this a few days earlier.
I want to go back to this particular point, because I now have interrupts working in conjunction with multi-threading. If the interrupts had to use the same stack space as the thread, then a program could require up to three times as much stack space.
For an actual example, consider the attached program, which combines threads and interrupts (as usual, compiled for the P2 EVAL board, serial interface 230400 baud).
Each thread has a stack of ~100 longs, as does each interrupt - they need a reasonable stack size because they all call various library functions (e.g. to perform I/O).
If the interrupts used the same stack space as the executing thread that they happen to interrupt, then each thread would have to have a stack of 300 longs - (100 longs for the thread itself, another 100 in case interrupt 2 goes off, and another 100 in case interrupt 1 goes off, because interrupt 1 can interrupt interrupt 2). Since there are 100 threads executing, this program would use another 200*100 longs, or around 80kb of additional Hub RAM dedicated to stack space. Of course, this is a fairly pathological example!
The attached program is compiled in Native mode, but interrupts now also work in Compact and LMM execution modes.