AndrewAPrice wrote:
Not a serious product proposal, but just a thought. I've seen CPUs written in HDLs running on FPGAs, I've seen Doom run CPU-less on FPGAs. Would it be possible to build an OS in, say VHDL or Verilog?
Building drivers and a window manager in a HDL seems a little overkill (more power to you though, if you can) mostly because any update or new device would require reprogramming the FPGA. Instead, I was thinking it might be more practical to implement a CISC architecture where the are microkernel-like instructions, with the CPU running all drivers, services, user programs in isolated address spaces and system calls are basically CPU instructions.
From a strict mathematical standpoint, any Turing-complete language/device/system can be used to implement any other Turing complete system.
And from the perspective of a userspace program, system calls already do look very much like single CPU instructions. The program has no more visibility as to what goes on in kernel space than it does as to what the CPU microcode is doing. Indeed, the opposite approach to what you're proposing can be, and has been, used to implement cheap, low-performance versions of an architecture: simply don't implement the most expensive instructions in the architecture (in terms of silicon area and microcode space), and then have the OS catch the illegal instruction trap and emulate the instruction. This effectively turns an instruction into a system call.
It's really considerations of flexibility (might people want more than one implementation of this?) and resources (can the needed algorithms be implemented in hardware in the space available) that determine what services are provided by the CPU vs. the OS, and, as illustrated above, the resource part can vary between different implementations of the same architecture. I doubt a full CPU-OS will be practical in the foreseeable future: system calls differ widely in their complexity, and Moore's law seems to be running out of steam, so you might move some low-hanging fruit into an ISA, but the heavier system calls will likely remain prohibitively expensive to implement in hardware. And considerations of flexibility may prevent many things that could be moved into an ISA from actually being implemented in hardware. For example: If you're putting together an new OS API for your ISA, then that will limit the portability of software written for that API to other ISAs. If you're using an existing API (Windows, POSIX), then that will complicate porting software for other operating systems than the chosen system to your ISA.