I'm poking at https://github.com/ozkl/soso trying to figure out where it first switches from Ring 0 to Ring 3. I want to rip out all of that protection stuff and just run everything in Ring 0. Just as an exercise for starters, but also eventually because I have.. notions.

After various attempts to grep, the current plan: I'm going to just try to write to some protected address at various points in the kernel, and binary-search my way to the solution. Let's see how this goes.

https://github.com/akkartik/mu#readme

On the language side I've been thrashing a fair bit:

• Between the OS side vs the language side.
• Between building an interpreted, dynamically-typed language in machine code vs a compiled, statically-typed memory-safe language that I can build the interpreted language out of.
• Between building a Lisp interpreter vs a better shell (in the spirit of Oil shell).
• Between making local vars in the compiled language function-scoped vs block-scoped.

permalink

Update on the Mu computer

We now have structured control flow (with goto statements 😂 )

Compare this screenshot with the ones in the previous message of this thread.

At this point I think I've climbed as far up the ladder of abstractions as I can with just syntax sugar. The next step up will be a new language. It'll still look the same: registers, curly braces, one operation to a line. But operations won't be x86 opcodes anymore. Registers and operands will have types.

permalink

Update on the Mu computer

A few days ago I found out about a hobbyist OS called Soso.

Today I've gotten Mu running on it well enough to make it a first-class supported platform alongside Linux.

https://github.com/akkartik/mu#readme

LoC of C I depend on thus goes down from 12M to 33k.

It's not a complete replacement, though. I still plan to work with Linux, particularly for its networking support. But it's so cool to have a minimal stack supporting graphics!

permalink

Update on the Mu computer

Syntax sugar for function calls is done. Here's factorial with no sugar, addressing modes and function calls, respectively.

Time now to start building a proper language, to occupy C's niche on this new stack. Type-safe, memory-safe, manual (but safe) memory management, manual (but safe) register allocation.

Though I might build a toy Lisp first. I figure I've earned some fun. Seeing a computer boot into a REPL would qualify.

https://github.com/akkartik/mu#readme

permalink

How SubX code has evolved over the past year

2018/Jul/30

2019/Sep/03

The first thing that pops out is that lines have gotten narrower.

Or have they? Scroll down and some long lines start to show up. Even if you ignore trailing comments. Check out the screenshot. Lines wider than 80 characters translate to 2-byte jump instructions. I wonder if I've lost my sense of proportion somewhere along the way.

permalink

Update on the Mu computer

Now that we have a notation for addressing modes, we're designing syntax for function calls.

It's easiest to parse if we start with a paren and avoid commas. However, the similarity to s-expressions is only skin deep. There can only be 2 levels of parens, and args can't do arbitrary arithmetic.

Pseudocode
Uses the just-created addressing mode notation!

More info: https://github.com/akkartik/mu#readme

permalink

More deletions later, LoC in my fork of the Linux kernel are down from 27.1M to 12.3M. Goal is to only support lowest-common-denominator devices.

https://github.com/akkartik/mu#readme

(My line-counting was way off earlier.)

permalink

Reason #83 to fork the Linux Kernel

I get to see my name and picture on a git log alongside Linus Torvalds's.

https://github.com/akkartik/kernel#readme

permalink

Update on the Mu computer

Now that we have a bootstrapped (quasi-) language and (kinda) bootstrapped OS, we're finally starting to think about less error-prone notations.

This week two of us built a notation for x86 addressing modes:

• direct: %ecx
• indirect: *ecx
• indirect with displacement: *(ecx+4)
• indirect with index, scale and displacement: *(ecx + edx<<3 + 4)

Not yet sure this is a good approach. But it'll be fun to playtest.

Here's before and after screenshots for factorial.subx.

Before:

After:

(project link)

permalink

Now that I have the beginnings of a whole new computer, I'm at a loss for what to work on next. (One of the items is H's suggestion of socket syscalls.)

Today's little mini-experiment: a program to print out random numbers in an infinite loop. Works fine on Linux or Mac, but only prints zeroes when packaged up with my kernel fork and run on Qemu or Linode. Looks like I need to do something to initialize /dev/random.

(More details)

Here's my complete current list of ideas, just for triggering serendipity:

• Test /dev/random without my kernel changes
• Test framebuffer syscalls
• Client socket helpers
• A compiled language -- kinda like my previous prototype (https://github.com/akkartik/mu1#readme)
• Some sort of storage. Either ramdisk (volatile) or local disk (needs mount) or S3 (needs sockets)
• An interpreted language. Either a subset of Oil or a straight-up Lisp. Needs storage.

permalink