Hi Ivan,
Thank you for sharing your insights!
> > It would mean that Linux/e2k can hardly conform to
> > POSIX well, as Bruno said, because POSIX requires different signals for
> > different cases and incompatibilities can't be forgiven on the reason of
> > speculative computations in the CPU.
> The compiler would know how to
> replay the faulty speculative computation, so it would be able
> generate code to do this non-speculatively and trigger the real fault.
Yes, you need to think at the kernel and the compiler together.
As I understand it, the general approach in such cases is to:
1) See in the hardware manual whether there is a way to retrieve the
exception details (exception code, and memory address in case of a
memory access) from the speculative execution. If so, use it in the
kernel, in linux/<arch>/mm/fault.c.
If not:
2) Implement a proposed solution in the compiler that results in
discarding the speculative execution results when there was an
exception during speculative execution.
3) Implement another proposed solution in the compiler that completely
disables speculative execution for instructions that may produce
exceptions (and leave it enabled only for guaranteed exception-free
instructions, such as integer arithmetic instructions).
[It is not unheard of that processor features get completely disabled.
For example, OpenBSD/x86_64 disables hyperthreading, which many
people previously thought to be a valuable processor feature.]
4) Benchmark the performance impact of 2) and 3) on programs. Choose
the one with less impact.
5) If the impact is high, then invent a compiler option that allows
the application developer to choose among POSIX compliant code or
fast code. [This is the approach used e.g. for floating-point instructions
on alpha in GCC: The instructions provided by the hardware are not
IEEE 854 compliant, and the workaround that GCC adds to make it
it IEEE 854 compliant is so much of a performance hit that it is
only enabled through a compiler option.]
Bruno
