Understand semantics of user mode

[snim2]

Although Revelation passes the kernel mode test case (interrupt_kernel_mode.c), the output of e-sim does not match the expected output of Revelation.

[snim2]

Notes [ http://blog.alexrp.com/epiphany-notes/ ] from say this:

User/Superuser Mode

Bit 2 of the STATUS register is documented as reserved, but actually means user/superuser mode, where it being cleared means user mode. This bit only has significance if (the documented as reserved) bit 25 of the CONFIG register is on, which tells the core to use user/superuser mode at all.

When user/superuser mode is in effect, an interrupt sets bit 2 of STATUS, and an RTI instruction unsets it. Among other things, when user/superuser mode is in effect, user mode is not allowed to issue GIE, GID, and RTI, and is not allowed to access system registers.

However, the unit test for user mode used to look like this:

/* Based on code by Ola Jeppsson @olajep
 * From: https://github.com/olajep/esim-test-bins
 */
#include <stdio.h>
#include <stdint.h>

void fpu_interrupt_handler() __attribute__ ((interrupt));
void fpu_interrupt_handler() {
    printf("fpu_handler:\tyou should see this message only once.\n");
}

int main() {
    register uint32_t r38 __asm__("r38"); /* Temp for adjusting system registers. */

    float a = 1e38;
    float b = 1e38;
    float c;

    uint32_t *ivt_usr, *ivt_exception; /* Interrupt vector pointers. */
    uint32_t addr_usr, addr_exception; /* Relative branch address. */
    uint32_t br32_usr, br32_exception; /* Relative address branch instruction. */

    ivt_usr = (uint32_t *) 0x4;
    addr_usr = (uint32_t) &fpu_interrupt_handler;
    addr_usr -= (uint32_t) ivt_usr; /* Adjust for user interrupt branch address. */
    addr_usr = (addr_usr >> 1);     /* Lowest bit is skipped (alignment). */
    br32_usr = 0xe8;
    br32_usr |= ((addr_usr & (0x00ffffff))) << 8;
    *ivt_usr = br32_usr;

    /* Clear imask. */
    __asm__("movt r40, 0");
    __asm__("mov r40, 0");
    __asm__("movts imask, r40");
    /* Enable fpu exceptions. */
    __asm__("movfs r38, config");
    r38 |= 14;
    __asm__("movts config, r38");
    /* Enable interrupts. */
    __asm__("gie");
    /* Trigger fpu interrupt. */
    c = a * b;
    /* Disable interrupts. */
    __asm__("gid");
    /* Disable kernel mode / activate user mode. */
    __asm__("movfs r38, status");
    r38 &= ~(1 << 2);
    __asm__("movts status, r38");
    /* Enable kernel / user mode. */
    __asm__("movfs r38, config");
    r38 |= (1 << 25);
    __asm__("movts config, r38");
    /* Enable interrupts (should do nothing). */
    __asm__("gie");
    /* Trigger fpu interrupt. */
    c = a * b;
    printf("Test complete.\n");
    return 0;
}

Running this test on e-sim gives this unexpected result:

$ e-sim -r 1 -c 1 revelation/test/c/interrupt_kernel_mode.elf 
ESIM: Initialized successfully
ESIM: Waiting for other cores... done.
fpu_handler:    you should see this message only once.
fpu_handler:    you should see this message only once.
Test complete.
ESIM: Waiting for other cores... done.
[INFO] core simulator 0x808 (32, 8) exited with status 0

which differs from the expected result that used to be in the Revelation test suite. This needs to be better understood before re-implementing it.