Introduce gas-sh4dsp-prizm target for fx-CG[10|20/50] calculators

[seija-amanojaku]

This PR introduces a backend to compile freestanding and "libb-ful" B programs for fx-CG10/20/50 calculators (with CPUs based on a FPUless SH4).

EDIT: Division and modulo are implemented as calls to intrisic_div and intrisic_mod. To be completely frank, I think this is the best way to pull things off, since the SH-4 architecture is designed in such a way that division is best kept as an external routine.

It also effectively requires a working SuperH crosscompiler/fxgxa to generate a .g3a executable.

[seija-amanojaku]

Most tests here do build properly (except for one due to PCrel issues), although I'd probably need to setup a proper basic SH-4 "emulator" to be completely sure.

[seija-amanojaku]

Just fixed PCrel issues relating to loading litterals, which now makes pretty much all tests at least build :3
I think that at this point, this is pretty much a decent target

[seija-amanojaku]

i hate delay slots

[seija-amanojaku]

Got most of CI working out for this target (at least through nektos' act)

[lephe]

This looks fun. Absolutely random remarks, may help, may not: linker script ROM size 2 MB, nothing "new" there any more, RAM always 512 kB (mapped by MMU), the small offset is related to data the OS puts in there but you can ignore it. All SH reads from memory are sign-extended and immediate-mov is too. PC-relative moves and branches in delay slots is an exception, if you trust your compiler to produce correct code there's no need to worry about it.

The detect_calculator is slightly weird, the constant in the middle of the function is unusual (also .align 4 is 16, and the zero write is dead?) Usually one would write something like:

_detect_calculator:
    mov.l   .L_ilram, r4
    mov     #69, r0
    mov.l   r0, @r4
    mov.l   @r4, r4
    cmp/eq  r0, r4
    rts
    movt    r0

.balign 4
.L_ilram: .long 0xE5200000

No need for rts after jmp in the syscalls since jmp is a tail call - the syscall code will itself return to your caller.

Please ping if you get something fun to work 👀

[rexim]

@seija-amanojaku sorry that it's taking so long to come to any conclusion on this PR. It's extremely cool, but depends on too much of exotic stuff. It either has to become more self-contained, or I need to finish decoupling the codegens from the compiler so we can put it in a separate repo. I'm slowly working on the decoupling.

[nullnominal]

@seija-amanojaku sorry that it's taking so long to come to any conclusion on this PR. It's extremely cool, but depends on too much of exotic stuff. It either has to become more self-contained, or I need to finish decoupling the codegens from the compiler so we can put it in a separate repo. I'm slowly working on the decoupling.

There is also bytecode in #184 for that