In the last mail Richard Earnshaw said:

> > my kernel hasn't crashed (but then again it didn't before) so I've not made
> > that worse.
> 
> Your kernel should *never* crash because of this bug.  The executable may 
> not function correctly, but if your kernel is crashing there is a bug in 
> your kernel.  End of statement.

It's not. I meant it as "I've not ballsed my compiler up"

> Don't forget you also need to fix up pointer-to-function calling, which 
> uses
> the sequence 
> 	mov	lr, pc
> 	ldr	pc, [reg, ...]
> For this it is important not to split the two instructions, so you will 
> need to align, do a padding nop and then emit the sequence.

I had forgotten this. I had a thought - improved messy version is:

	add	lr, pc, #4
	.align 3
	ldr	pc, [...]
	.align 3

which will become either

	add	lr, pc, #4	; return to .there
	andeq	r0, r0, r0
	ldr	pc, [...]
.there

or
	add	lr, pc, #4	; return to .there
	ldr	pc, [...]
	andeq	r0, r0, r0
.there


This is always 4 bytes longer, takes 1 extra clock cycle for a failed
conditional branch, but 50% of the time for a taken branch is no slower.

> 
> Finally, I think there is a similar problem with case dispatch tables 
> (which use ldrls pc, [pc, reg, lsr #2]).  Fixing these up is even harder, 
> so it would probably be better to just make them work in the same way as 
> the PIC dispatch tables (which use "addls pc, pc, reg, lsr #2" with a 
> table of branch instructions).

Aaaargh.

Hopefully from the DEC document I can figure out how to make the MMU work,
I'll do my best to do that, as 
a) this is getting really messy.
b) I'd like to be able to reliably run anyone else's (legal) binaries
   without needing to recompile to get the bodges in.

Nick