Hi Finn,
Am 06.05.2023 um 14:46 schrieb Finn Thain:
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.
I'm not saying it's a bug, and I had expected more latency. I haven't
seen any significant difference in either number of signals, and signal
latency is hard to gauge without instrumenting the signal code to add a
timestamp when the signal is raised. No significant impact on execution
time of the tests at any rate.
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."
Right - I was thinking an exception raised by another instruction than
the one currently executing could cause USP to become unreliable but all
that does is make the fault address differ from USP (for an instruction
executing that uses USP). Your current patches don't use the fault
address at all.
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.
As it turns out, I had already tested that one, and it caused signals to
be delivered on interrupts mostly instead of bus error exceptions. Never
ran stress tests on that one at the time.
Cheers,
Michael
