Sleigh Banked registers (CP register sets the location of the bank)

[rnd-ash]

I am trying to improve @esaulenka C166 module, to add support for Infineons C167 CPU.

One of the main issues that I am facing is that the CPU has banked registers, where setting the CP register will determine where in memory these registers lay. Currently, the definitions of these registers are set to the default value of the CP register (0xFC00):

define register offset=0xFC00 size=2
	[ r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 ];
define register offset=0xFC00 size=1
	[ RL0 RH0 RL1 RH1 RL2 RH2 RL3 RH3 RL4 RH4 RL5 RH5 RL6 RH6 RL7 RH7 ];

Is there any way to let sleigh change the offset of these registers on the fly? It should be noted that the value of the CP register can be set to any value, so I can't just define a large bank of registers which would be a colossal mess anyway.

There is a specific instruction scxt which changes the value stored in the CP register.

[astrelsky]

You can access a register indirectly through the register address space. Unfortunately the decompiler will emit a ton of warnings about ignoring this indirection (which is what you want). Assuming that the scenario in which the default register bank is not used is rare, you can use a context register to control whether or not they are accessed indirectly. You will need to use a table for all your registers in every constructor though.

An example of the register table and accessing the registers indirectly through the register address space can be seen here. https://github.com/astrelsky/RL78_sleigh/blob/master/data/languages/rl78_tables.sinc

Setting the register bank context register can be seen here. https://github.com/astrelsky/RL78_sleigh/blob/master/data/languages/rl78_map2.sinc#L556

[rnd-ash]

Whilst this might work, the issue here is that with the C166 does not use defined banked GPRs. The GPR registers can be ANYWHERE in memory, using the Context Pointer as the address to start from.

The scxt instruction explicitly sets the Context Pointer, however, the Context pointer can also be updated using MOV and other instructions, making it very difficult to know when explicitly the address of the GPRs has changed.

[GhidorahRex]

It depends on how the registers are being used by the code. Given the fact that it's a context pointer, is it primarily being used for context switching?

You may try not modeling it at all and seeing how the code looks if you just leave the registers as normal registers - this would work if most of the context switching occurs around functions.

You can also model them one step further as updating the register values as a memory read for each context switch. For scxt it might look like this:

macro save_regs() {
local addr = CP;
*:2 addr = r0;
*:2 (addr + 2) = r1;
*:2 (addr + 4) = r2;
...
*:2 (addr + 0x1e) = r15;
}
macro restore_regs() {
local addr = CP;
r0 = *:2 addr;
r1 = *:2 (addr+2);
r2 = *:2 (addr+4);
...
r15 =*:2 (addr+0x1e);
}
:scxt CP, data is ... {
  save_regs();
  CP = data;
  restore_regs();
}

Have a separate constructor for mov and other instructions that can modify GPRs to do the same. Several processors do something similar for register windowing. I believe the SPARC module does something like this.

You could also look at how the pic16 does register banking with the BSR register.

[rnd-ash]

To clarify, i think this explains it better. R0-R15 are the 16 General purpose registers on the CPU

CP = 0xF200

R0 is at address 0xF200
R1 is at address 0xF202
...
R15 is at address 0xF21E

CP = 0xFC00

R0 is at address 0xFC00
R1 is at address 0xFC02
...
R15 is at address 0xFC1E

Its worth pointing out CP register can be any arbitrary value, so using defined banks would not work.