The world's slowest Linux PC

I had one when they were pretty new, back in 1991.

Had MS-DOS reduced to the minimum, jumping into Windows 3.1 straight after booting and using Stacker to be able to double the hard disc contents.

By the time I came to use GNU/Linux, I was already on Pentium 75 Mhz and never imagine such 386sx would ever manage it.

More Previously:

https://news.ycombinator.com/item?id=3767410 (1054 days ago)

Except if you emulate them in JavaScript. I get 5.10 BogoMIPS: http://copy.sh/v86/?profile=custom&cdrom.url=http://k%C3%A6n...

This is actually pretty common. There was a time when not every CPU had a FPU and floating point operations were emulated in software if required. Or doing 64 bit integer operations on a 32 bit CPU. Or doing arbitrary precision arithmetics on todays CPUs. You do it just like in school, piece by piece, but instead of single digits you use the largest registers available. If you really like it slow you could of course also just use plain strings to represent numbers and do all math on a char by char, digit by digit basis.

There used to be bit-slice processors that chained together narrow (eg. 4-bit) chips to build a wider processor. This is pretty much a software emulation of that technique, but lacking the parallelism.

https://en.wikipedia.org/wiki/Bit_slicing

Commonly, to perform something like an arbitrary width addition, these CPUs have a carry flag that is set if an operation overloads, so that the carry can be added into the next addition. This way you can simply chain simple 8-bit additions to get the desired operation width. For example, a 16-bit addition (0x5555 + 0x1234 on 6502

    clc
    lda a
    adc b
    sta res
    lda a+1
    adc b+1
    sta res+1

    a:
        .byte $55, $55

    b:
        .byte $34, $12

    res:
        .byte $00, $00 ; reserved for result

The simple answer would be: by using memory. More bits means that the CPU can operate at larger amounts of data at once. For example shift would need to perform multiple 8bit operations but it's entirely doable (I hope the cpu he used has shifts with the carry flag)

Adding to some of these other comments, when IBM did their groundbreaking 32 bit System/360 in the 1960's, they started with a nice silicon transistor based logic family, but it pretty much ran at only one speed. So to deliver a family of computers with the same ISA, they microcoded the slower ones.

The very slowest one had 8 bit wide execution units, and presumably used similar techniques to deliver its 32 bit macroarchitecture. Per Wikipedia (https://en.wikipedia.org/wiki/IBM_System/360), the Model 30 in 1965 could execute "up to" 34,500 instructions per second, the hardwired Model 75 could do about a million. See e.g.: https://en.wikipedia.org/wiki/IBM_System/360#Table_of_System...

Sounds like that's exactly what he did.

For x86, older versions of Linux ran on a 386, but current versions require a 486, or a Pentium if you turn on stack protection (as most distro kernels do). (Almost nobody noticed.) However, drivers for ISA and similar still exist in the kernel, so you could likely get the most recent kernel running on a real 486, if you had one around.

The slowest systems still running Linux, though, are probably those running the m68k port. Many people doing development for that port use m68k emulators, which run many times faster than the fastest available hardware. However, at least in theory, you can run the m68k port on any m68k processor that has an MMU.

Almost certainly one of thing things supported by http://www.uclinux.org/.

The main thing is to get the ARM instructions working correctly, so that's not too bad. If all of those are correct, it should boot and do basic stuff. The next bit of work is to get the peripherals going.

Neat article! I love the box he put it in. The neatly labeled sections are somewhat fascinating and give interesting insight into how a CPU works. Things seem different when your CPU is a foot long and sits on the table I suppose...

Thanks for this link. It deserves a separate thread!