Citer : Posté le 30/05/2025 20:13 | #

---

Add-ins run in privileged mode, so if they write somewhere they shouldn't it can break stuff (in the worst case brick the calculator).

---

Citer : Posté le 31/05/2025 08:04 | #

---

You may be right about that. I think interpreting is appealing especially for things like single-stepping in a debugger which I think an on-calculator assembler would definitely need. It certainly solves a lot of problems. On the other hand, I think I have come up with a way to sanitize the code that might work. I put all of the instructions that seem relevant in a spreadsheet: SH4 instructions. Here's what I would do:

Code memory
- The assembler writes machine code to a part of RAM that the assembly code can't read or write.
- Branch instructions to fixed targets work without modification but must take a named label as an argument rather than a number to insure they jump to a valid instruction: BF, BF/S, BT, BT/S, BRA, BSR
For branches there are two possible options:

Option 1
- There is no way for the user to access the PR register directly.
- A macro like PUSH_PR pushes PR onto a stack that the user can't access. POP_PR does the opposite and checks for stack underflow.
- Instructions that load an address from a register are excluded: BRAF, BSRF, JMP, and JSR.
- JMP and JSR can be replaced with an alternate JMP and JSR that take a label name instead of a register if the +/-4K range of BRA and BSR isn't big enough.

Option 2
- PR returns an ID number instead of an address so no problem if the user accesses and manipulates the ID. The ID is an index into a table of target addresses created by the assembler.
- Loading a label into a register loads the label's ID instead of its real address.
- BRAF, BSRF, JMP, JSR, and RTS all expect an ID number and check that it's a valid table index before jumping. Supplying the wrong ID number jumps to somewhere unexpected but all ID numbers are valid targets so no crashes.

Data memory
- The assembled program is allocated a block of memory for data that it can read and write which is aligned to it's own size, ie a 64K block starting at 0x....0000.
- All constant data like tables and strings are copied into this block at startup. No constant data is stored in code memory since the assembled program has no way to access it.
- Addressing for the data memory starts at 0, so each instruction that accesses memory is masked (0xFFFF if data is 64K) then added to the base address (0x....0000). There are a couple of ways to do the masking:

Option 1
- Two registers (R14 and R15 for example) are off limits. The assembler will error if either one is used in an instruction.
- One holds the mask and the other holds the base address. Address sanitizing is AND R14, Rm then ADD R15, Rm, so just two instructions in most cases and four instructions for @(R0,Rn) and @Rm+,@Rn+ addressing.

Option 2
- All registers are free for the user to use including R14 and R15.
- The masking code stashes R15 somewhere temporarily to free the register up. Is DBR free for this?
- Another possibility is GBR. The assembler can make a copy of GBR and restore it before calling any gint functions but not sure if GBR is also needed in interrupts.
- Another possibility is PR as long as it's free before BSR or JSR.
- After R15 is stashed somewhere, the mask and base are loaded from a constant pool. 6 instructions: store R15, load mask, and with address, load base, add to address, restore R15.
- (Anywhere after an unconditional jump (BRA, BSR, JMP, JSR, RTS) is ok for the constant pool since all branches have to be to named labels so no way to jump between an unconditional jump and the next label and accidentally execute constants as code. In the worst case, output the constant pool with a jump over it.)
- Since branches only go to named labels, an easy optimization is to skip storing and restoring R15 until it's needed or there's a jump which brings the masking code from 6 to 4 instructions.

Option 3
- Like option 2, all registers including R14 and R15 are free.
- Use LDC/STC Rm,Rn_BANK to hold mask and base. Does gint use the other set of R0-R7 for exception handling?
- This should be faster since there's nothing to fetch from the constant pool. Also, running out of room and putting the constant pool in a random place will work but is annoying.

Instructions
- Instructions with Rm,@-Rn addressing decrements the address by up to 4 after masking, so 4 extra bytes before the data memory need to be available.
- Instructions with @(disp,Rm),Rn addressing increments the address by up to 60 bytes after masking, so 60 extra bytes after the the data memory need to be available.
- The only logical place for GBR to point is the beginning of data memory which is offset zero, so GBR can be ignored even if gint doesn't need it in interrupts. @(R0,GBR) just becomes the equivalent of @(R0) and @(disp,GBR) just becomes @(disp).

Citer : Posté le 31/05/2025 16:53 | #

---

Yes, good point. I think this is the most performance you could get programming on the calculator with a language that is crash proof. I would expect any sort of interpretation to be 20x slower or more. The fastest way of interpreting is to convert the instructions to native machine code like a JIT with a few safety rails. This is a similar idea but doing it at assembly time instead of run time. An interpreter would have to do all the checks I'm doing here but would just be much slower. I also think an interpreter would leave out all the system instructions to modify VBR and do cache invalidation and so on, so I don't think any of the reductions there are a real loss except maybe the modified way jumps work. The non-jump instructions that do address masking would assemble and work identically on the PC without the masks as long as the programmer didn't make an address miscalculation that is hidden by the address masking.

I think you could still use R4 to measure the length of your run. If R0 and R4 both point to valid addresses in the 64K block, then the distance between them will always be correct and the same as if the addresses were unmasked. The masking actually has no effect at all unless your @R4+ runs off the end of the 64K block and the masking causes it to wrap around to the beginning of the block instead of corrupting something higher in memory. Wrapping is just the fastest behavior that prevents crashing. An option could also insert longer and slower code to check bounds and stop executing. I agree about @(R0,Rm). It's not clear which might be an address and which is an index so it doesn't make sense to convert both to addresses. It would need another register as you say.

Hmm, I don't get what you mean about extu.w. The 0xFFFF mask is just an example. As long as the base is aligned to the size of the data memory, the data memory can be any size that is a power of 2. The mask is just size-1. For a 32K block, the base might be 0x12348000 (note aligned to 32K boundary) and the mask would be 7FFF. ANDing and ADDing means any input address will always fall in the correct 32K range between 0x12348000 and 0x1234FFFF.

Yes, a permanent place to put them is a better idea. I could use a global variable addressed with GBR (assuming it's not used for something else) but then it has to go through R0 so maybe R0 should stay stashed. That's a bit of a bummer since R0 is used a lot.

Yes, pointing to the constants is a good idea. Otherwise, it has no meaning since the assembled program has no knowledge of any of the global symbols the C compiler uses the GBR to access. Setting it to zero would waste the @(R0,GBR) addressing mode but @(disp,GBR) would let you access the first 1K or memory in a single instruction which might be useful. Edit: when I say set BGR to zero, I mean set it to the base of the data memory so offset zero from the beginning of data memory.

Since the top goal is preventing a crash, it's not enough to make sure the address is in the correct range since it could still jump into a constant pool or the middle of masking code. The jump targets don't need to be functions; they just need to be labels which is what you would generate for a switch function anyway. For option 2 above, return addresses fed to PR would also get an ID number like labels. The programmer generally doesn't know or care what JSR puts in PR or what gets fed to RTS as long as execution flows as they expect, so it shouldn't matter whether the value is a real address or an ID number. The only time I can think of that it might matter is doing address calculations to load data out of code memory (which is already disallowed) or for calculating a jump into an unrolled loop like a Duff's device which I can live without.