The Moxie Blog

I’ve committed the PC-relative branch instruction changes upstream. But this is just one of many ISA improvements that need to happen. Here are a handful of other ideas off the top of my head. None of these projects should be particularly difficult.

• Shorten load/store offsets to 16-bits. They are currently 32-bits, but for all of the benchmarks I’ve looked at the upper 16-bits are always 0×0000 or 0xffff. If the compiler ever really wants to use an offset > 16-bits, it should revert to computing the target address in registers. I don’t expect that much code would require this.
• Introduce shift instructions with immediate operands. There’s plenty of opcode space for us to add 16-bit shift instructions that include a 5-bit immediate shift value (so we can shift up to 32-bits in either direction). Right now we load a 32-bit immediate shift value into a register which burns that register as well as wastes 32-bits of code space per shift.
• Get the compiler to generate 16-bit immediate loads. All immediates are 32-bits right now, but the vast majority of these constants are < 16 bits long.
• Push/pop multiple registers to the stack with one instruction. Although we have 16-registers, the ABI doesn’t have us pushing all 16 to the stack on function entry. We should be able to have a single 16-bit instruction that pushes/pops all of the relevant registers in one go. The instruction would include a bitmap identifying the registers we need to push/pop. ARM has something like this. The only drawback I can think of is that it could increase interrupt latencies as we’d probably have to retire the entire instruction (~10 memory writes/reads) before servicing an interrupt.
• Many register rich ISAs include one register that is hardwired to zero. We could try this to see if it makes a difference, but I doubt it would be a win. Another idea would be to create a cmpz instruction to compare a register to zero so we don’t have to burn a register for this common operation. Maybe cmp1 might even make sense. This is easy to measure.

Those are some of the obvious ones, and all I have time to write about now.

My first go at exceptions is working well. The basic idea is that moxie will have a single exception handling routine whose address lives in special register 1. You set the exception handler like so:

void install_handler(void (*handler)(void))
{
  printf ("Installing handler 0x%x\n", (unsigned) handler);
  asm("ssr %0, 1" : : "r" (handler));
}

When the processor hits an exception, it performs a standard function call to the handler. We return from the handler just like it was any old function, since it currently uses the standard C ABI. The exception type will be found in special register 2. The current exception types are as follows:

#define MOXIE_EX_DIV0 0 /* Divide by zero */
#define MOXIE_EX_BAD  1 /* Illegal instruction */
#define MOXIE_EX_IRQ  2 /* Interrupt request */
#define MOXIE_EX_SWI  3 /* Software interrupt */

In the case of IRQ and SWI exceptions, the interrupt number will be found in special register 3. I don’t have instructions yet to disable or enable interrupts, but those are an obvious next step. Here’s a sample exception handler:

void handler (void)
{
  int et;

  /* Get the exception handler from special register 2.  */
  asm("gsr %0, 2" : "=r"(et) : "0"(et) );

  switch (et)
    {
    case MOXIE_EX_DIV0:
      printf("DIVIDE BY ZERO EXCEPTION\n");
      break;
    case MOXIE_EX_BAD:
      printf("ILLEGAL INSTRUCTION EXCEPTION\n");
      break;
    case MOXIE_EX_IRQ:
      {
        int irq;
        asm("gsr %0, 3" : "=r"(irq) : "0"(irq) );
        printf("INTERRUPT REQUEST %d\n", irq);
      }
      break;
    case MOXIE_EX_SWI:
      {
        int swi;
        asm("gsr %0, 3" : "=r"(swi) : "0"(swi) );
        printf("SOFTWARE INTERRUPT REQUEST %d\n", swi);
      }
      break;
    default:
      printf("UNKNOWN EXCEPTION 0x%x\n", et);
      break;
    }
}

The handler for DIV0 and SWI may also want to know where the exception happened. This can be determined by pulling the return address off of the stack and subtracting the appropriate instruction length (2 for div and 6 for swi).

I’ve implemented support for this in the qemu port, and the test directory in moxiedev contains a simple program to exercise this new functionality. I think we’ll want to hook up some peripherals in qemu to the IRQ system soon.