On: 386-DX/SX support nuked from Linux Kernel

[dietrichepp]

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

[daeken → dietrichepp]

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

[simias → daeken]

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 → simias]

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 → simias]

> 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 → simias]

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.