An incredibly primitive operating system, with just two instructions: compile (1) and execute (0).
It is heavily inspired by Frank Sergeant 3-Instruction Forth and is a strip down exercise following up SectorForth, SectorLisp, SectorC (the C compiler used here) and milliForth.
Here is the full OS code in 46 bytes of 8086 assembly opcodes.
↫ 10biForthOS sourcehut page
Yes, the entire operating system easily fits right here, inside an OSNews quote block:
↫ 10biForthOS sourcehut page
50b8 8e00 31d8 e8ff 0017 003c 0575 00ea5000 3c00 7401 eb02 e8ee 0005 0588 eb47b8e6 0200 d231 14cd e480 7580 c3f4
How do you actually use this operating system? Once the operating system is loaded at boot, it listens on the serial port for instructions. You can then send the instruction 1 followed by a byte of an assembly opcode which will be compiled into a fixed location in memory. The instruction 0 will then execute the program. There’s also a version with keyboard support, as well as a much bigger version compiled for x86-64.
Something like this inevitably raises the question what an operating system really is, and if this extremely limited and minimalist thing can be considered as one. I’m not going to deep into this existential discussion, mostly because I land firmly on the side that this is indeed just as much an operating system as, say, Windows or MorphOS. This bit of code, when booted, allows you to operate the system.
It’s an operating system.
If DOS was an operating system, this is an operating system.
That said, if you want to persist data to permanent storage, this is not getting you much further than a magnetized needle and a steady hand.
DOS was much better than a lot of people give it credit for. It was definitely more sophisticated than many other OSes of the time
Definitely not an operating system, but an IPL (initial program loader). This is exactly how early computers like the Altair 8800 and IMSAI 8080 worked: the CPU started halted or in single-step mode, you hand-entered a short IPL using the switches on the front of the machine, then the IPL would load the real program over a serial connection to a tape reader.
Also, just in case the description provided by the author fooled you into thinking that it’s doing more than it really is, where it says “a byte of an assembly opcode to be compiled”, it really means “a byte of machine code to be copied”. You must assemble the code on your host computer first, and then it is merely copied into the virtual machine over serial. There is no compilation going on in the virtual machine.
Lastly, I don’t see any way to contribute to the source code, but I managed to get it down from 46 bytes to 41 bytes:
B8 00 7E 8E D8 8E C0 31 FF 1E 57 E8 0F 00 3C 01 74 05 3C 00 75 F5 CB E8 03 00 AA EB EE B4 02 31 D2 CD 14 F6 C4 80 75 F5 C3
Full assembly listing:
bits 16
cpu 8086
[ORG 0x7c00]
EXECUTE equ 0x7e00
init:
mov ax,EXECUTE
mov ds,ax
mov es,ax
xor di,di
push ds
push di
loop:
call getchar
cmp al,1
jz compile
cmp al,0
jnz loop
retf
compile:
call getchar
stosb
jmp loop
getchar:
mov ah,0x02
xor dx,dx
int 0x14
test ah,0x80
jnz getchar
ret
Author here: Great! Feel free to send your patch on https://lists.sr.ht/~hocwp/10biForth-discuss.
A README update is welcome as well.
djhayman,
Before TI decided to lock down their programmable calculators you could actually type in assembly mode programs without data cables and without exploits. I did this with a TI86. They shun it now.
It’s even more primitive than an IPL. I think this is what it is called a RIM loader.
This “OS” is pretty much just the tiney ROM routines that would bootstrap and set up those old machines, post reset, to listen to the switches to load the single-stepped code to boot into. Except this is just listening to the serial port.
Yeh, this is more like what we would call a bootloader today. The bare minimum code needed to suck the actual program you want, from the media it is stored on.
Whether of course you count a bootloader as an operating system is largely a matter of opinion.
My opinion is an operating system needs to be a human readable interface for loading arbitrary programs from. If it’s a set of fixed programs with no way to load alternatives on demand without external/chained software (like some bootloaders), it’s not an OS. If you have to feed it machine code by hand, it’s not an OS. If it loads up a dedicated application on boot without option to load other utilities/software first (think games console games), it’s not an OS.
BASIC is an OS (on something like the C64 or BBC Micro), you can load arbitrary programs from media from within BASIC
MS-DOS is an OS
The Playstation 2 firmware is an OS (you can load ROM programs for CD/DVD playback, manage memory card save data, or arbitrary games from disk)
GRUB is an OS (you can feed it commands to load OSes from any media)
EFI Firmware is an OS, you can load and run code directly from the shell
Old school BIOS is an OS, you can load code from multiple drive sources, some removable.
10biForthOS is NOT an OS. It lacks the “human readable” criteria.
Maybe we should call it a hypervisor? or hyperloader? 🙂
Hyperloader is very nice.