I never really got why back support should be an issue - its all x86 instruction...

bdonlan · on Dec 12, 2012

It's not just instructions - it's CPU bug workarounds, too. For example, some 386s did not honor the write-protect bit in the page table when in supervisor mode. Now, since Linux normally does copies from kernel to userspace by writing straight to userspace and letting the WP bit detect writes to read-only memory, it's a problem if the WP bit doesn't work (it'd let you overwrite write-protected userspace memory). So Linux had a check that tested (at boot time) whether WP worked properly in supervisor mode, and if so it would set a flag to perform a slower, software-checked copy. This adds overhead to _every_ copy from kernel to userspace, as it needs to check this flag, and branch to the fallback implementation.

daeken · on Dec 12, 2012

That seems... odd. Why wouldn't you just swap implementations at startup, if it's a non-negligible performance hit?

dietrichepp · on Dec 12, 2012

How? If you use function pointers, you end up paying more than the cost of a branch.

daeken · on Dec 12, 2012

Simplest way: have two implementations, copy the proper one into place (and relocate if necessary). No overhead.

simias · on Dec 12, 2012

Or you know, use a flag. And if it becomes a performance issue later on after some profiling, consider a more complicated approach. Don't underestimate your CPU's branch prediction.

Self modifying code is a can of worms. Many things can go wrong, and good luck debugging the mess.

daeken · on Dec 12, 2012

This is all resting on the assumption that the flag does actually have an impact, which was an argument in the original comment.

As for self-modifying code, the dangers are way overstated IMO. Having written a lot of it as well as reverse-engineered and debugged code using self-modifying code heavily, I look at it as just another tool in the chest. It's pretty easy to chop your limb off using self-modifying code, but having audited a whoooole lot of static code, I'd say that argument applies to just about any tool.

onedognight · on Dec 12, 2012

> Self modifying code is a can of worms. Many things can go wrong, and good luck debugging the mess.

Linux uses self modifying code (usually at startup) to efficiently support booting the same kernel on single an multiple processor machines.

csense · on Dec 12, 2012

Branch prediction? On a 386?

AFAIK the first Intel CPU to have branch prediction was the Pentium 2 -- which was released many, many years (I'd say ~12 years) after the 386.

fafner · on Dec 12, 2012

Sorry, but how can you not get this? The smallest subset defines what you can use at least in the core. You have to add workarounds to make it work. Which takes up time of developers and increases the code complexity. Every configuration option increases the test complexity.

Therefore if an architecture is no longer needed then nuke it. What's the point of hanging on to 386? I doubt that any new machines today are shipped with 386 CPUs. Even embedded radiation hardened special systems are now having better CPUs, such as Pentium-compatible or some PPC.

And the systems still running are certainly not upgrading to a new kernel.

rythie · on Dec 12, 2012

That's a bit like saying, why not support IE1 (which by the way is newer than the i386) because it's just a subset of IE10.

yuhong · on Dec 12, 2012

The x86 features in question are relatively small but pretty important nowadays. CMPXCHG and XADD are important atomic operations, for example.