On Sat, 6 May 2023, Michael Schmitz wrote:
In my mind, at the time I sent them, patch 1 was expected to mitigate
the impact of patch 2. It would have been surprising if the reverse
had somehow happened.
I did wonder if delaying signal delivery would cause fewer signals to be
delivered in total, and whether the remaining bus faults that do cause
signal delivery (format a) still cause any trouble because of eventual
unreliable USP.
Adding your patch 2 then might have mitigated these problems while not
placing too much of a burden on the stack.
If fewer signals get delivered in total, that's not a bug, right? It just
amounts to is slightly more signal latency on what is already a slow CPU.
Format 0xA bus errors happen between instructions according to the User
Manual. There's no possibility of hitting the stack corruption bug AFAICS:
"For efficiency, the MC68030 uses two different bus error stack
frame formats. When the bus error exception is taken at an
instruction boundary, less information is required to recover from
the error, and the processor builds the short bus fault stack
frame as shown in Table 8-7."
Anyway, I'm still in the dark as to why patch 1 is interesting. Was
that because you wanted to delay signal delivery to try to put more
pressure on stack memory by delivering multiple signals? You and I did
come up with an
No - it just eliminates temporary stack growth due to the format b bus
faults as entry into signal delivery.
alternative patch for bypassing signal delivery after certain
exceptions. Maybe that would work better.
Meaning skipping signal delivery on any bus fault? I haven't tried that
one yet.
Don't try that patch if you are hoping to see signal delivery after a
format 0xA exception -- you'd only ever get signal delivery after traps,
interrupts, FP exceptions and a few other obscure cases.
As with patch 1/2, I don't know why you'd want to use it.
