386-DX/SX support nuked from Linux Kernel
git.kernel.org
git.kernel.org
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.
So I was pretty grateful at the time that it was still working, even though what I was doing was, now I can say with the benefit of hindsight, pretty crazy.
I also kept it around for sentimental reasons, as it was the machine I did most of my early coding on. It didn't feel right to throw it out.
So thanks, Linux, for supporting my old junk hardware as long as you did! And congrats on losing ~400 lines of crufty code.
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.
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.
The other thing that made them so easy to over-clock was that, unlike the Pentium Pro, II and III, there was no on-chip L2 cache that would malfunction at higher speeds. All you were over-clocking was the CPU.
I had a dual-Celeron system that ran like a champ for the better part of ten years.
Only the first generation Celerons (which everyone hated) had no L2 cache. The second generation had 128KB of full-speed on-chip cache, which is actually why it overclocked well. The Pentium II and early Pentium III had 512KB of half-speed off-chip cache which struggled to keep up with the CPU when overclocking.
I should see if it actually boots someday....
(I've been searching for images of the chassis but to no success. I've never seen one, nor heard of it before today.)
And in the other direction, a PC Jr (also an 8088) maxed out at 128 KB, according to my references, though Wikipedia says there were third-party extensions to 736K. In any case, the Jr doesn't support the 8087 math coprocessor, so that's not what the author has.
I also have no idea if it still works. It was covered in quite a bit of dust and I wonder if the HD won't be stuck after all this time.
Didn't you get the memo?
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.
Turns out Linus is not the nostalgic type.
"Distro"? What's that? :-)
That said, it's time. Long past.
http://www.theregister.co.uk/1999/12/27/hubble_telescope_get...
On the 386 line, the SX/DX distinction was the equivalent of the 8088/8086 distinction for data bus width (NOTE: the 8086 was the wider processor, the cheaper 8088 was in the IBM PC).
I got a fair amount of grief about not having a math co-processor due to some programming friends and I were doing at the time.
That said, those were the formative days where getting dirty and playing with your machine (building your own rig) started for me. I've since given that up since most machines are fast enough these days for my uses.
http://www.sandia.gov/media/rhp.htm
Those satellites that are going up with the old radiation hardened 386 are going to have to run a version of the linux kernel 3.7 or earlier. I suspect they are conservative with regards to their kernel choice anyways, so that should be okay.
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.
Besides, when the machines take over, they may want to spare those who respected them ;-)
I hope they feed me and keep my cage clean.
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.
You've still got all the old kernels that do support it. And Debian certainly has historical archives (http://www.debian.org/distrib/archive) and I'm sure other distros do too, if you want all the other linux architecture.
I'm typing this from a 2004 PPC Powerbook running Ubuntu 10.04. There are a lot of packages and software I simply can't get anymore. But it's ok, because it doesn't have the power to run them anyway. It's frozen in time, and I know that. Anyone running on relying on 386 stuff should just stick with the older software that's working and pray they don't have a hardware failure. If the kernel starts packratting stuff it's going to be bloated and huge and it will hinder future development.
Maybe they should set a time limit on stuff, like 10 years before they drop support, or maybe 15 for the military and law offices.
Amazing little processor for its time.
Self modifying code is a can of worms. Many things can go wrong, and good luck debugging the mess.
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.
Linux uses self modifying code (usually at startup) to efficiently support booting the same kernel on single an multiple processor machines.
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.
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.
What does that mean? I thought speculative execution was a micro-architecture optimization (and the speculatively executed instructions won't be retired until the processor knows that it wants the side-effects).
In contrast, I've only seen barriers come up for x86 at the ISA-level (and even then, only for multiprocessors setups).
Along with some Amiga 500 and Amstrad PCW at school and friend's places.
Oh I'm becoming a bit nostalgic.
http://m.extremetech.com/extremetech/#!/entry/intels-50core-...