386-DX/SX support nuked from Linux Kernel • Hacker News Board

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

#41

Post by dietrichepp » Wed, Dec 12, 2012, 10:13 AM UTC

daeken wrote: post #40

bdonlan wrote: post #29

Earlier quoted context omitted.

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…

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

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

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

#42

Post by daeken » Wed, Dec 12, 2012, 10:16 AM UTC

dietrichepp wrote: post #41

daeken wrote: post #40

Earlier quoted context omitted.

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

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

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

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

#43

Post by jdelsman » Wed, Dec 12, 2012, 10:18 AM UTC

386-DX was my first PC. This is incredibly sad, even more so because it makes me realize I'm getting old!

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

#44

Post by kzrdude » Wed, Dec 12, 2012, 10:18 AM UTC

j45 wrote: post #12

386's were the first computers I ever used Linux on. Man. I will say this much, a 386 sx/16 was a large part of learning learn how to get so much done with so little resources. It's amazing how Linux was more efficient than windows even then, while the decade of driver drought was being bridged.

Isn't this the platform Linus used for Linux when he started too?

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

#45

Post by fsiefken » Wed, Dec 12, 2012, 10:32 AM UTC

jmspring wrote: post #3

The 386sx was a fun processor. Lack of a math coprocessor was fun to work around. I'm surprised support lasted this long.

i remember using a coprocessor emulator i downloaded from a bbs, it actually worked in speeding up astronomical calculations!

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

#46

Post by fsiefken » Wed, Dec 12, 2012, 10:34 AM UTC

i still have an old toshiba 386 laptop i used 20y ago, pretty much outdated and outperformed by current hardware. I could run the latest linux on it but I am not sure linux 3.7 can be made to run comfortably in 4 MB ram.

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

#47

Post by simias » Wed, Dec 12, 2012, 10:40 AM UTC

daeken wrote: post #42

dietrichepp wrote: post #41

Earlier quoted context omitted.

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

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

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.

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

#48

Post by daeken » Wed, Dec 12, 2012, 10:55 AM UTC

simias wrote: post #47

daeken wrote: post #42

Earlier quoted context omitted.

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

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.

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.

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

#49

Post by lmm » Wed, Dec 12, 2012, 11:17 AM UTC

pdw wrote: post #37

astrodust wrote: post #2

To think that support for something so edge-case has been supported this long is remarkable. Even very basic embedded x86 processors are 80486 caliber. Those more feeble than that have no hope of running the current kernel in any meaningful fashion.

Support is a bit exaggerated, the 386 option hasn't compiled since the 3.2 release due to unconditional use of 486-only instructions ( https://bugzilla.kernel.org/show_bug.cgi?id=44931 ). Who knows if it actually worked before that.

It was working in '07; I gave up maintaining that system when glibc went 486-only.

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

#50

Post by dspillett » Wed, Dec 12, 2012, 11:29 AM UTC

SoftwareMaven wrote: post #32

asveikau wrote: post #11

Earlier quoted context omitted.

In 2000, someone gave me a 386 desktop that they were about to throw out, and I ran OpenBSD on it until 2005 or so. (I was a student, so getting new hardware was more of a big deal then.) To get it working I had to recompile the kernel (which I did on a "more capable" Celeron 366) without support for newfangled hardware such as USB and PCI in order to have enough memory to boot and log in in a tolerable amount of tim…

I loved my Celeron. I had a 300 which over clocked amazingly well to 450Mhz. In fact, those were the last days of my "dinking" with hardware. The Pentium and beyond offered such diminishing rewards that it wasn't worth it.

Celerons of that era were very easy to officially overclock generally because a great many of them were underclocked by Intel.

They ended up with far more of the more expensive 400+MHz capable parts than they expected to produce (presumably they were overly cautious when predicting how well the production process would work and therefor how many of the better rates chips thye'd get) but too few of the cheaper 300Mhz and 333MHz rated parts that were actually selling well - so they rebadged faster units as slower ones to fufil sales promises for the slower units.

This meant buying a machine based around a Celeron 300 or 333 (often referred to as "Silly-rons" at the time) was a lottery: you might have got one that is genuaninely expected not to be stable if run much faster, or you might have got one that Intel could have sold as a 450+MHz device.