> which BTW proves again that Linux doesn't fit onto 8-bit micros.
How in the world does it "prove" that, when not only does it "fit", it fits in addition to an emulator? I don't see that it only runs _under_ an emulator proves any such thing.
While this is obviously a "hah, you think it's impossible? I'll show you," type achievement, and running Linux on an 8-bit is never going to be more than a curiosity, it's a neat proof of concept and could trivially be made much faster (through a hybrid approach: a lot of the Linux code could likely be ported quite easily, and a lot of it could probably also be jit'ed relatively easily (especially kernel-land - a special purpose jit whose only purpose is to jit the kernel would be vastly easier than a general purpose jit, not least because you can take a boatload of shortcuts (e.g. manual translation) in cases where a simple/trivial jit doesn't do well.
I think it's a fascinating solution - people have talked about doing ports to limited systems without MMU's etc. before, and it has usually meant severe tradeoffs that means lots of userland won't work (e.g. vfork instead of fork). This is a d'oh moment in that the "solution" if your goal is only to get a port running (rather than for it to be practically usable) has stared us in the face "forever" (there's been virtualization solutions using emulated CPU's since before Linux was around).
I meant the external DRAM thing - this chip would never be able to run Ubuntu without external RAM and bit-banging DRAM in software is more akin to "crawling" than "running" to be honest.
But yes, in a sense, you can run Linux on 8-bit micro or even a sufficiently long Lego brick Turing Machine.
So? It's not the first system to rely on software support for memory refresh. And many 8bit and even 16 bit systems relied on the CPU for other tasks that are usually offloaded to external chipset these days.
The ZX-81 ran the display. The C64 controlled the tape drive directly. The Amiga, which had a long list of support chips, still had the CPU directly handle decoding of data from the floppy.
It affects performance, sure, but if you're trying to shoehorn Linux onto an 8bit embedded CPU in the first place, you're not doing it for speed.
Comments
> which BTW proves again that Linux doesn't fit onto 8-bit micros.
How in the world does it "prove" that, when not only does it "fit", it fits in addition to an emulator? I don't see that it only runs _under_ an emulator proves any such thing.
While this is obviously a "hah, you think it's impossible? I'll show you," type achievement, and running Linux on an 8-bit is never going to be more than a curiosity, it's a neat proof of concept and could trivially be made much faster (through a hybrid approach: a lot of the Linux code could likely be ported quite easily, and a lot of it could probably also be jit'ed relatively easily (especially kernel-land - a special purpose jit whose only purpose is to jit the kernel would be vastly easier than a general purpose jit, not least because you can take a boatload of shortcuts (e.g. manual translation) in cases where a simple/trivial jit doesn't do well.
I think it's a fascinating solution - people have talked about doing ports to limited systems without MMU's etc. before, and it has usually meant severe tradeoffs that means lots of userland won't work (e.g. vfork instead of fork). This is a d'oh moment in that the "solution" if your goal is only to get a port running (rather than for it to be practically usable) has stared us in the face "forever" (there's been virtualization solutions using emulated CPU's since before Linux was around).
I meant the external DRAM thing - this chip would never be able to run Ubuntu without external RAM and bit-banging DRAM in software is more akin to "crawling" than "running" to be honest.
But yes, in a sense, you can run Linux on 8-bit micro or even a sufficiently long Lego brick Turing Machine.
> I meant the external DRAM thing
So? It's not the first system to rely on software support for memory refresh. And many 8bit and even 16 bit systems relied on the CPU for other tasks that are usually offloaded to external chipset these days.
The ZX-81 ran the display. The C64 controlled the tape drive directly. The Amiga, which had a long list of support chips, still had the CPU directly handle decoding of data from the floppy.
It affects performance, sure, but if you're trying to shoehorn Linux onto an 8bit embedded CPU in the first place, you're not doing it for speed.