51–60 of 89 posts
I never really got why back support should be an issue - its all x86 instructions, if only a subset of what is used today right? I'm curious to know exactly what makes supporting old cpus so hard.
I would have thought that support for this architecture would have been useful to keep, since a lot of rad-hardened systems (think space, satellite applications) still use it.
I'm into retrocomputing so these kinds of retirements always sting a bit. In realistic long term operations, deprecations don't hurt. I.e. your air traffic control system running on PA-RISC and HP-UX doesn't care that HP-UX only run on Itanium now. You keep running the old software and set up some kind of support schedule to keep the system patched during it's service life through the vendor or otherwise.
I can't blame them for wanting to drop it though, not only do you not have the full range of atomic operations, but also the MMU doesn't respect the WP bit from kernelspace which means special code in copy_to_user()
I wonder how long they will keep the 486SX alive now that it's the last one that requires 387 emulation.
Earlier quoted context omitted.
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…
http://www.theregister.co.uk/1999/12/27/hubble_telescope_get...
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.
Linux uses self modifying code (usually at startup) to efficiently support booting the same kernel on single an multiple processor machines.
Earlier quoted context omitted.
I'm into retrocomputing so these kinds of retirements always sting a bit. In realistic long term operations, deprecations don't hurt. I.e. your air traffic control system running on PA-RISC and HP-UX doesn't care that HP-UX only run on Itanium now. You keep running the old software and set up some kind of support schedule to keep the system patched during it's service life through the vendor or otherwise.
It's comforting to know others are interested in "retrocomputing". For some reason I like slow old computers too. (Not being sarcastic here at all)
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.
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 should see if it actually boots someday....
The 386sx was a fun processor. Lack of a math coprocessor was fun to work around. I'm surprised support lasted this long.