68LC040 line F stack frame

[Thomas Richter]

Here comes a quite technical question on the "unimplemented floating point" exception the 68LC040 generates. The stack frame, a type-4 stack frame, contains an field that includes the effective target address of the decoded instruction. This is in particular tricky if the (not implemented) floating point instruction uses a pre-decrement or post-increment addressing mode, i.e. a mode "with side effects". Does anyone actually know (Toni?) whether the 68LC040 updates the address registers on such a mode before (or after) throwing the instruction, or what the stacked ea is in such a case? For the 68060 (and derivative), the address registers are NOT udpated, and in case of extended or packed decimal operands, even invalid. For the 68040 (not the LC), the ea can be taken from the rather lenghy FPU state frame, and thus, the question is not relevant. Hence, I'm only checking for the 68LC040.

[paraj]

I can't say whether this is the correct behavior, but at least for simple cases WinUAE handles it the same for 040 and 060. I.e.

    move.l  #4,a0
    fmove.l fp0,-(a0)

Stacked ea = 0, a0 unchanged (4).

You can see that in put_fp_value2 (in fpp.cpp) mode=4, old register value is saved in mmufixup[0] and fpu_mmu_fixup is set to true. The address (ad) is set to the updated value. fault_if_no_fpu then restores the old register value and passes the ea onto the function that builds the stack frame (Exception_build_stack_frame in newcpu_common.cpp).

[Toni Wilen]

Yeah, it most likely is not modified but I don't think I have tested it using real LC040 model. (I do have 68LC040RC25 chip but no compatible accelerator boards, at least without getting slower crystals..)

[paraj]

Some supporting evidence for that theory is netbsd's floating point emulation code seems to expect that (https://github.com/NetBSD/src/tree/t.../arch/m68k/fpe). Note that the code appears to distrust the stacked EA/nextpc (the latter for good reason https://mail-index.netbsd.org/port-m...1/04/0002.html).

[Thomas Richter]

Thanks folks!

In the meantime, I checked the FPU emulation in an older linux kernel, it also seems to expect that the address registers are not modified, and the code modifies the registers itself. For the 68060, there is code in the FPSP, and there it is also assumed that the address registers are not modified, though the stacked EA is wrong in some cases. Strange that Mot did not document this in any place.