rswier / swieros

A tiny hand crafted CPU emulator, C compiler, and Operating System

swieros

A tiny and fast Unix-ish kernel (based on xv6), compiler, and userland for fun, education, and research.

Virtual CPU with full user/supervisor and virtual memory support, fast enough to support self-emulation.

Fast C-subset compiler allowing on-the-fly compile-and-go of all applications.

Network clients & servers, remote OpenGL, GUI applications, and many other nifty features.

Runs under Windows or Linux.

See the 00README.txt for full details and a step-by-step walkthrough tutorial.

swieros's Issues

64-bit port

Rob,

I forked swieros and ported eu.c (user mode emulator) to 64-bit over the weekend. It works well, and built an alternative boot that uses the 64-bit user-mode emulator to run a 32-bit previously-compiled bin/c (c compiler) to compile bin/c.c, then have the new bin/c compile etc/os.c, etc/mkfs.c and then run the emulator to run etc/mkfs to build the file system. It all works great. The next step is to port the protected mode emulator em.c to 64-bit and then everything should be working.

After taking a hard look at the C compiler, I think it is far easier to leave it as 32-bit, as well as of course the v6 OS, since they seem pretty dependent on sizeof int == sizeof int *.

The mechanism I used to port eu.c is very basic: none of the "pointers" or 32-bit pointer code were changed. Instead, all pointers are treated as 32-bit offsets to memory returned by a rewritten sbrk() in linux/libc.h, which initially allocates 64MB once using malloc and now supports break shrinkage as required by the C compiler. A single real pointer to the base of this memory is stored in a "unsigned char *mem" global and then added to any 32-bit "pointer/offset" to be used as a real pointer for each emulation instruction. Thus the execution cost is only a single 64-bit pointer add for each instruction executed. This would also be the case for 32-bit, where previously the sbrk() allocation was added once before start, now its added each instruction execution. So it is slower in 32-bit mode. But it has the advantage of very little changing, which promotes reliability.

The same mechanism can be used for the protected mode emulator, which I plan to port shortly. This approach allowed the C compiler to remain entirely unchanged, and the sbrk() improvement only affects host-compiled programs, since lib/libc.h was not changed either.

I have tested the c compiler recursively compiling the c compiler compiling a program, as well as recursively running the user mode emulator running the user mode emulator running a program :)

I didn't create a pull request since I'm not finished, and wanted your input as to what you think of this approach.

Which instruction set does the virtual CPU based on?

Hello, rswier.
I'm interested in your project and now looking into it.
It seems that the virtual CPU is based on neither x86 nor arm instruction set. Is it an instruction set that defined by yourself? Is there any documentation about the hardware/software interface?
Thank you.

Use busybox?

Hi,

You may want to take at replacing glibc with uClib
And possibly replace your custom commands with busybox

FWIW/

Keenan

How to add debugger for this OS?

hi, rswier,
Great project!
Any idear about adding debugger in em simulator for OS debug?
Thank you!