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