hgesser.com/ulix/

The Implementation of the ULIX Literate Operating System

header

Navigation

Privates

Publikationen

Studium

Software

Sonstiges

Blaue Links: intern
Rote Links: extern

Suche Linux-Bücher bei
Amazon.de


Subscribe ULIX: Literate Unix

A diary documenting the implementation of ULIX-i386

Welcome to the ULIX blog.

Ulix (Literate Unix) is a Unix-like operating system developed at University of Erlangen-Nürnberg. I use D. E. Knuth's concept of Literate Programming for the implementation and documentation. The goal was a fully working system which can be used in operating system courses to show students how OS concepts (such as paging and scheduling) can be implemented. Literate programs are very accessible because they can be read like a book; the order of presentation is not enforced by program logic or compiler restrictions, but instead is guided by the implementer's creative process.

Ulix is written in C and assembler for the Intel architecture. The literate programming part is handled by noweb.

On this page I document my progress with the implementation.


Navigation: 2015 | 2014 | 2013 | 2012 | 2011


Preparations for User Mode (13.08.2011)


In order to create user mode processes (without implementing a program loader right now) I compile simple C programs (with a main() function) to object files and link them with a ld linker script with OUTPUT_FORMAT set to binary, creating a .com file. (I use this ending in memory of simple DOS programs and because yesterday the original IBM PC turned 30 years.) Then comes some Unix shell script magic which pipes the binary through hexdump, fmt, and sed in order to create a char array declaration like this:

static char procbin[] __attribute__ ((aligned (4096))) = {
0x83, 0xec, 0x10, 0xc7, 0x44, 0x24, 0x0c, 0x00, 0x00, 0x00,
0x00, 0xc7, 0x44, 0x24, 0x08, 0x01, 0x00, 0x00, 0x00, 0xeb,
0x10, 0x8b, 0x44, 0x24, 0x08, 0x01, 0x44, 0x24, 0x0c, 0xff,
0x44, 0x24, 0x0c, 0xff, 0x44, 0x24, 0x08, 0x83, 0x7c, 0x24,
0x08, 0x09, 0x7e, 0xe9, 0xb8, 0xcd, 0xab, 0x00, 0x00, 0xcd,
0x80, 0x8b, 0x44, 0x24, 0x0c, 0x83, 0xc4, 0x10, 0xc3, 0x00
};
That can be pasted into the Ulix source code and will create a page-aligned block holding the program. This is then mapped to page 0, and user mode is entered with an IRET to address 0: The program starts.
In order to check what code has been produced by the compiler, I use the disassembler udis86.

Resources used:
udis86 disassembler library with udcli client, http://udis86.sourceforge.net/

[ Path: | persistent link ]


Physical RAM mapped, hexdump (13.08.2011)


I've done some preparations for user mode: physical RAM (I assume 64 MByte RAM) is now mapped to 0xD000.0000-0xD3FF.FFFF. That's helpful when I know the physical address of some data, but not the virtual one. I noticed that it's easy to forget that page directory entries need to point to physical addresses, not virtual ones. I kept wondering why I got segfaults :)
There is now a "frame list" (actually just a bitmap). It can be asked for the status of any frame (im RAM), and for each frame the status can be set to free or used.
Another new function is hexdump() which displays (virtual) memory contents in the same format as the shell command hexdump does for text files. It was fun to compare its output with the output of 'hexdump ulix.bin'. My temporary shell (the hard-coded main loop for now) cannot yet parse arguments to commands, so hexdump will display contents of three memory areas selected in the code; in a future version it will accept start and end addresses and show the memory region's contents.

[ Path: | persistent link ]

Copyright © 2011-2015 Hans-Georg Eßer; Server: Debian Linux, Apache Web Server, blog page powered by blosxom :: the zen of blogging, Theme: Hazard Area 1.6 (modified), created by Bryan Bell, Copyright © 2000-2006 Weblogger.com.