Yalo – Lisp OS running on bare metal x86-64 hardware

D-wav quantum prototype is running a full Lisp OS. I want to work there just to actually witness a working lisp machine

Thanks for an interesting project! I have also written some bare metal OS projects before and I have a few suggestions for you.

First of all, I recommend using a multiboot capable bootloader (GRUB is one, QEMU and Bochs have built in multiboot bootloaders). This will allow you to skip some of the arcade initialization code required. In particular, loading the code from a floppy is painful because most PCs these days don't have a floppy drive. So while you'll be able to test the code on emulators, running on real hardware require getting a floppy drive. With GRUB, all you need to do is put the binary image in your /boot and you can boot on it with real hardware.

When using multiboot, the bootloader will set up 32 bit identity mapped protected for you.

Many bootloaders also support setting up a graphics mode, which will save a lot of trouble, because you'll have to drop back to 16 bit real mode to access the BIOS interrupts to change the graphics mode.

I do understand the appeal of not using a bootloader and doing things from scratch but when it comes to getting things done, that's just not a good way to go.

I also recommend staying in 32 bit mode, it's just a lot easier. In 64 bit mode you'll need to deal with paging (no identity mapping is available) and this becomes a burden very early in the project when you will need to access memory-mapped i/o devices (in particular the APIC interrupt controller) and Intel Multiprocessor configuration, which are scattered around the physical memory address space.

When you have something that actually works, it is easier to go to 64 bit mode than it is to start from scratch with 64 bit long mode. I found this out the hard way and my hobby OS project[1] stalled because it was just too much work to get anything done in long mode.

In addition, I would recommend emitting debuggable elf files instead of flat binary files. Using the QEMU/Bochs monitor will take care of your most basic debugging needs but to go further, remote debugging with GDB is going to be very helpful.

Best of luck for your project!

[1] https://github.com/rikusalminen/danjeros

I did this.

I built the hardware (Z80 SBC), wrote the OS (tiny single tasking Unix like UZI180), started to write an editor (like ed). Then I got distracted with something shiny and abandoned it.

Think I blew 200 hours on that and don't even have the source now.

I've been doing this, working on the OS part now, eventually I'd like to write a small vi clone, a c compiler, x86 assembler and then maybe do an x86 clone in verilog/x86 emulator.

We've come a long way, but it's a bit tragic so many of our eggs are in what amounts to two baskets. One is the "Unix-ish" basket, where we have Linux, *BSDs, OSX, Haiku, and even Hurd. The other is the heirs to VMS, where we have Windows, which is completely opaque to research, and ReactOS.

It's nice to have people exploring OS ideas in other spaces as well.

I saw this from xach's tweet https://twitter.com/xach/status/427490779326451712

suggesting movitz isn't moving anymore, but maybe I'm reading it wrong.

Do you know how to try running Movitz? Many links on that page are broken.

From Github: "The system programming language is Ink, a new Lisp dialect which combines the elegance of Scheme and powerfulness of Common Lisp."

And no link! It's like eating chocolate in front of a child and not giving him any. Me want.

Yes, an Allan Kay "child". :)

That's a common idea in low-level Lisp programming. Note that you still get macros, so it's a lot nicer than writing straight-up assembly language.

Not entirely, although a Common Lisp function wrapper to NASM syntax does seem to play a big role.

Look here: https://github.com/whily/yalo/blob/master/doc/GettingStarted...

In some respects, the 1990s and 2000s were a massive regression over the 70s and 80s. For some of us, at least.

In the 80s, computer users were not segregated as producers and consumers as strongly as it happened with the consolidation of closed systems. They came with schematics, they openly explained every internal function and design.

Under the guise of simplification and layers of abstraction, most of the users and even developers have been progressively denied control over their computing devices. Smalltalk and LISP based systems proposed a leaky abstraction model were every user could delve as deep as he wanted into the system, which enforces a degree of openness that is very inconvenient for monetisation of the system itself. Which is why they were suppressed (by simply allocating resources on producer-consumer models, easy to sell and most importantly easier to monetise as the provider becomes the master).

Note that this culture is extremely hard to eradicate as people stick to what they know and a total shift is unlikely to meet with collaboration from the companies that profit from said control.

See, in 1970s this was the stuff of top-notch research labs and expensive computing centers. Same applies to multi-core multi-megaflops CPUs, advanced multi-user OSes that run multiple VMs while networking with computers on the other side of the globe. It was there in 1970s, too. Only today it's something that can run on your laptop, or a smaller device like the Intel Edison, for a few hundred dollars.

Can you notice the difference?

Another area where a massive copy-catting of 1960s and 1970s is happening today is space launch tech. And again, where 1960s had to spend a significant portion of national budgets, today's private firms do pretty well with a fraction of a valuation of a picture-sharing service, and turning a profit in the process.

The goals did not change all that much, but the means are now much more accessible.

Bret Vitor's talk is great, for those that still don't know it,

http://vimeo.com/71278954

I like to dig computer history, and when I look everything that was accomplished at Xerox and other places and what we got. The industry really moves at snail pace in some areas.

At Xerox the GUI systems were developed in Lisp, Smalltalk and Mesa/Cedar, the later being a systems programming language with automatic memory management.

Those systems had networking, GUIs, multiuser capabilities. Object embedding capabilities, the precursors of IDE and REPL environments.

Today we are still trying to re-invent those systems. How further would have we managed to be today, if those systems had been picked up as starting point.

Unlikely as everyone will still be busy porting all the stuff to Javascript.