It's a good example of a minimal system, but it's more academic than an example of something that illustrates a useful system. It's arguable whether much could be done with it in real time. There's no TCP/IP stack, and even if networking did exist, most connection types would time out.
I'm interested in the minimal computing resource needed to run a full network stack and recent software. So far, I've run an m68030 with 10 megs of memory and a 16 bit memory bus (Mac LC II) multiuser with networking. 24 megs in a VAXstation VLC is enough to compile plenty of real software. Even a real 11/780 from 1977 can still run sshd and negotiate a connection before a timeout.
I found even a Vaxstation 3100 with the m42 cpu and 12MB of RAM was enough to work with. Sometime within the last five years, I installed NetBSD by netbooting from a Linux mopd server (because I didn't have a working 512-byte block SCSI cdrom). As a computer, it was quite reasonably usable. Not fast by any means. I didn't have anything but a serial console to work with, so no gui. I thought the best thing in the world would have been to browse the Internet on the machine, but I gave up on it because I couldn't Lynx to work.
All of this seems under-powered today, but was actually more horsepower than a comparable PC capable of running Windows 95.
If you ever want to put VMS on that VAXstation 3100 m42, it's pretty neat to play around with. DEC people were sharp, like the Bell Labs and Berkeley people, and did a lot of things differently than Unix did. VMS was perhaps less agile, but more consistent. If you can get hold of VAX C for it, you might be amused to find that some of the documentation for system libraries has examples in BLISS instead.
BTW, don't underestimate an old workstation with only 12MB of RAM: they were often used for technical software that today people might write to require machines with 100x that much RAM.
(I did a little work on the VAXstation, for technical software. I also kludged up a gateway to one, from a TCP/IP LAN, through an Ultrix box that was also on DECnet, since no one had paid for a TCP/IP stack. A lot of important software was optional, little was free, and the printed manuals you could find were precious.)
I fully intend to do so. I have the VAX VMS ISO and hobbyist license around somewhere and have spent a little time fooling with it under emulation. I first used it nearly 30 years ago, and have been missing versioning filesystems ever since. For all of the strengths of Unix-like systems, notably their longevity and versatility, as I think I've written elsewhere on this forum, VMS just seems so much more fully engineered, designed and deliberate in contrast.
(It seems you had a great hack to get VMS connected. Was that used for file sharing only, or could you do more with it?)
.iso is perfect -- TK50 drives are scary in how they operate, and I'd be scared to put a rare tape into one.
I gatewayed remote logins from arbitrary hosts, and I probably used a stock DECnet facility to transfer/share files between a VAX/VMS and Ultrix MIPS box, possibly direct to NFS volume mounted from a SPARCserver onto Ultrix. I think there was at least one NFS implementation (TGV?) for VMS at the time, but didn't have it.
I have this bucket list idea of getting the lowest-powered chip I can find that's still fast enough to give me a nice little *nix environment in which I can use Vim, Tmux, and also SSH into things, then sticking it into a laptop shell and filling the rest of the space with batteries.
I wonder if one could achieve like a month of battery life for such a glorified typewriter/thin client.
On a recent project I played around with some SoCs that could do something like this.
I wound up using a Renesas RZ/A1L, it's an ARM-A9 core with 3MB of SRAM on the die. You attach it to an inexpensive quad-lane SPI NOR flash part and it will boot Linux with just those two parts. The flash serves as a filesystem and I believe you can also XIP the kernel off the NOR part if you choose.
We even ran Qt on it with an XGA LCD and it was poky but it worked. It could probably do what you're looking to do.
That's probably the lowest-end part I'd say would work for something like this. You can run Linux off a cheaper Cortex-M with some amount of work, but it's not pleasant. The iMXRT1050 does look interesting, though.
Just curious, what would you use vim for on a device like that? Presumably it won’t be able to do much beyond what you outlined so unless you plan on using it as just a not taking device/typewriter, why not just have an embedded ssh client with tmux?
Not much more than a few Hertz, AFAICT. It should be enough to use a terminal - someone even installed X and ran XFCE on a Kindle, but it looks pretty weird.
I've been messing around with an Arduino this week to make my own IoT device. It has enough power to negotiate a https connection, so presumably it could run SSH and Vim. I think they are very efficient in terms of power usage.
Another easy way to play around with Linux fit onto very modest hardware (but not 8-bit microcontrollers), which is very popular and very useful, is OpenWrt on a cheap old home WiFi router: https://en.wikipedia.org/wiki/OpenWrt
(If you want to pick up an old router for $20, WNDR3700v2, WNDR3700v4, WNDR3800, and select later ones in that family are a good starting point. The OpenWrt wiki pages for them will give specs and suggest what hardware revs are better.)
Myself and several project mates used an Atmel AVR in early 2003 to build an mp3 player. We didnt bother with the storage integration instead to just opt to stream the mp3 file from a host PC over a UART. IIRC, we only had 32k RAM & 32k ROM to work with (we werent using a Mega chip, I'd have to dig through notes to find the model).
Knowing what we went through to get that mp3 player working (which we delegated the actual decoding to a dedicated chip) with just the AVR, what Dmitry accomplished with this is amazing. Many props.
Edit: this was a senior level college project for a BSEE, not work related.
I'd imagine that a modern kernel has a lot of pointless fat in it and that the 5-hours figure could be reduced if perhaps only slightly, with appropriate optimization effort. It might even be useful to deliberately have such a super-slow (but reliable, since it runs on highly deterministic microcontroller-class HW) benchmark in the mix, as you would be able to make very precise and fine-grained measurements about how even seemingly-unrelated changes might impact performance within the kernel, whether for the better or worse.
I believe that the idea would not be relevant in "general purpose benchmarking improvements" due to the vast differences in micro architecture between this CPU and modern CPU's.
The pipelining and internal optimizations differ greatly.
I have probably commented this before, but the nommu support was merged all the way back in 2.5.46, so a mmu is certainly not a requirement for running Linux.
A 32-bit architecture is not really a requirement either, you just need a compiler that can be told to use 32-integer types and pointers. You probably also have to modify the compiler to generate accesses to your external ram for loads and stores.
The real thing preventing you from running Linux on 8-bit micros is the requirement of a von Neumann architecture (or something that looks like it). These small MCUs usually don't even have a way of loading code at runtime which makes it impossible to run any sort multitasking without interpretation.
But the 8069 is a microprocessor (CPU). This is a microcontroller. Radically different architecture and (typical) use case.
They don't have MMUs because they are designed to directly address a much smaller ram space. On an the micro in the article, this is only 16K. They are also designed to execute machine code directly, and automatically from an on-board or external ROM, whether a masked ROM (rare these days), an EPROM, or an EEPROM/NVRAM of various kinds. They are not designed to use an OS at all.
The 6809 was 8 bits, in the same way Z80 and 6502 and 6800 were: 8 bit data bus, 16 bit address bus.
It had a few 16 bit instructions: arithmetic on data in registers, or loading/storing a 16 bit register (8 bits at a time). I think the Z80 did as well.
I wonder what would be the ideal Linux compile target for running on interpreter style emulators (as contrasted to binary translation style).
I guess the machine instructions should be as high level as possible, to reduce the interperter dispatch overhead. Of course then you'd need to port Linux and gcc to your hyper-CISC...
Interesting. Making it run RISC-V rather than ARM would provide slightly quicker emulation, I believe. (And indeed, more generally, running a RISC-V VM provides a quick way of enabling modern 64-bit code to run even on hardware that's restricted to a 32-bit address space. Given that there's a lot of such hardware around, even of quite recent vintage, this can be practically helpful.)
> What many do not realize is that the company ships over 1 billion processor cores within its products each year and is moving toward 2 billion per year.
> Last year, Western Digital made the amazing claim that they will transition their consumption of silicon over to RISC-V, putting one Billion RISC-V cores per year into the marketplace.
Yup, of course. Today it "exists" as a supported architecture in Linux, however... so it makes sense as a suggestion to whoever may want to try something broadly similar, but in a way that can even be practically useful. (Almost all current ISAs other than RV itself have historical warts that can slow down not just hardware implementations but emulation a lot... that's one of the reasons RV was made in the first place!)
> Almost all current ISAs other than RV itself have historical warts
RISC-V doesn't have historical warts only because it's too new for any warts it has to be considered historical.
> that can slow down not just hardware implementations but emulation
RISC-V shuffles the immediate bits on its instruction encoding to speed up decoding the immediate in hardware, but this slows down decoding the immediate in software. This will in the future probably be considered one of RISC-V's "historical warts".
> RISC-V shuffles the immediate bits on its instruction encoding to speed up decoding the immediate in hardware
You're right that this might be a problem, in principle. Surprisingly enough, however, RV is actually more than competitive as a system-level virtual ISA. People have experimented with this on existing emulation platforms, and that was the result they got.
Sadly the software is proprietary. Indicating for "commercial use" means it is proprietary.
When already doing something for Linux kernel, it would be advisable to promote the same license as the Linux kernel, such as GNU General Public License 2.
Promote free software and advance of free software.
2016: https://news.ycombinator.com/item?id=12537653
2014: https://news.ycombinator.com/item?id=8791812
2013: https://news.ycombinator.com/item?id=5581851
2012: https://news.ycombinator.com/item?id=3767410