OSDev.org

Posted: **Sun Apr 20, 2008 5:18 pm**

So I've been away from the board for a little bit but I finally have something to show for 4 months of work: the imaginatively titled testa. That's right, after 4 months I have created an os which can display a H in yellow on a red background in the corner of the screen...

What is more exciting though is that this is an os written in Microsoft's CIL (i.e. what c#, vb.net etc are compiled to) which has been filtered through my own native code compiler tysila (written in c#) to a position-independent elf64 executable loadable by tload (a little stub which takes over from grub to load elf64 images).

Now to get it working with c#. I think I'll try the mono version, visual c# seems to make too many assumptions.

I know its all been done before etc, but hey, its fun. No peeking at the Singularity source either. I've certainly learned a lot about compiler design and especially how to do it badly.

Source is under a bsd licence here.

Regards,
John.

Posted: **Sun Apr 20, 2008 6:24 pm**

It causes a triple fault in Qemu:

Code: Select all

qemu: fatal: triple fault
EAX=e0000011 EBX=0002bdc0 ECX=c0000080 EDX=00000000
ESI=0002bf64 EDI=0002bf65 EBP=0020bfd0 ESP=0020bfd0
EIP=002012bb EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300
CS =0008 00000000 ffffffff 00cf9a00
SS =0010 00000000 ffffffff 00cf9300
DS =0010 00000000 ffffffff 00cf9300
FS =0010 00000000 ffffffff 00cf9300
GS =0010 00000000 ffffffff 00cf9300
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00160000 000007ff
IDT=     00000000 000003ff
CR0=e0000011 CR2=002012bb CR3=00101000 CR4=00000020
CCS=00000004 CCD=e0000011 CCO=LOGICL
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

Posted: **Sun Apr 20, 2008 9:41 pm**

It may be a problem witch QEMU.
I'm no expert, but when it comes to 64 bit, QEMU, in my experince, doesn't work very well.

Posted: **Mon Apr 21, 2008 12:39 am**

Use qemu-system-x86_64

jnc100: Where is the code in your repository? I can find tysila but not any IL code.

Posted: **Mon Apr 21, 2008 6:16 am**

4 months for displaying a letter on the screen? I don't think it's worth the trouble. You must be really motivated. So what's next?

EDIT: I'm serious! Do you plan to do more with the project or have you had enough?

Posted: **Mon Apr 21, 2008 8:37 am**

AlexExtreme wrote:Use qemu-system-x86_64

If that was ment for me I am perfectly aware of this.

Posted: **Mon Apr 21, 2008 8:44 am**

Odd......it triple faulted once and now it's fine...and I used 86_64 both times

But now it seems to work.

-JL

Posted: **Mon Apr 21, 2008 9:04 am**

Zacariaz wrote:
AlexExtreme wrote:Use qemu-system-x86_64
If that was ment for me I am perfectly aware of this.

No, I meant piranha.

Posted: **Mon Apr 21, 2008 12:37 pm**

piranha wrote:It causes a triple fault in Qemu:
...
Odd......it triple faulted once and now it's fine...and I used 86_64 both times

Hmm, that's odd and slightly worrying. To be honest, I hadn't tried the code in qemu, only bochs. I've just run it through my qemu-system-x86_64 (version 0.9.0 for win32) 15 times with success every time.

AlexExtreme wrote:jnc100: Where is the code in your repository? I can find tysila but not any IL code.

Well the code was only a test case, and is a bit ugly (you need to create defines for pretty every base type under the sun, as there isn't a standard library yet) but it basically boils down to:

Code: Select all

 .assembly testa {}
 
 .method static public void main() cil managed
 {
        .entrypoint
        .maxstack 2
        ldc.i8          0x00000000000b8001
        ldc.i4          0xCE
        call            void poke(native uint, int8)
        ldc.i8          0x00000000000b8000
        ldc.i4          0x48
        call            void poke(native uint, int8)
        ret
}

.method static public void poke(native uint, int8) cil managed
{
        /* the hex bytes are the CustomAttribute prolog (0x0001) followed
           by a PackedLen string (i.e. the length, followed by a utf8 encoding,
           followed by two null bytes.  In this case it refers to 'poke_I1'.
           This means that calling the function void poke(native uint, int8)
           actually does not call a function, but rather emits the builtin
           function poke_I1 inline which does as you would expect */
        .custom instance void Cli.BuiltinFunction::.ctor(string) = ( 01 00 07 70 6f 6b 65 5f 49 31 00 00 )
}

and yes, I realise a 'poke' function isn't exactly type safe, but its pretty much impossible to write an os without using such a function a few times. In future, the vga memory will be an array with bounds checks at an arbritary location in virtual memory (mapped from b8000).

zaleschiemilgabriel wrote:4 months for displaying a letter on the screen? I don't think it's worth the trouble. You must be really motivated. So what's next?

Two letters!

Regards,
John.

Posted: **Mon Apr 21, 2008 1:39 pm**

It works fine on 0.9 (Linux 386).

I am writing an os in a safe bytecode language myself, so I know it's hard to get to a point where your kernel can do something impressive. Unlike you I wrote my own language and toolchain (source to bytecode compiler, bytecode to native (jit or aot) compiler, assembler and linker). I thought about using java or .net, but I found that java has too many limitations (no unsigned integer types etc.) and .net is very bloated (it uses the pe file format that I don't want to support; the internals of .net are rather complex, too). It was quite a bit work to get my language running (~40k lines to get a kernel + jit compiler for userland applications working) but now I can add all extensions that I need for the kernel and jit compiler to it (native memory access, manual memory management & object construction).

Posted: **Mon Apr 21, 2008 4:39 pm**

AlexExtreme wrote:
Zacariaz wrote:
AlexExtreme wrote:Use qemu-system-x86_64
If that was ment for me I am perfectly aware of this.
No, I meant piranha.

I am aware of this. See my above post.

-JL

Posted: **Tue Apr 22, 2008 7:32 am**

Hi, in case you didn't know; there are other CIL based OS's out as well, such as www.sharpos.org.
Keep up the good work!
Cheers

Posted: **Tue Apr 22, 2008 1:02 pm**

Latest revision (204) now works with code produced by visual c#. As an example, the previous test rewritten in c# is:

Code: Select all

namespace testca
{
    class Program
    {
        static void Main()
        {
            Kernel.Kernel.poke(0xb8000, 0x49);
            Kernel.Kernel.poke(0xb8001, 0xCE);
        }
    }
}

namespace Kernel
{
    public class Kernel
    {
        [Cli.BuiltinFunction("poke_U1")]
        public static void poke(ulong addr, byte val) { }
    }
}

test code source is here

@Korona: seems like you have an interesting project going too. Do you have any releases or a website?

Regards,
John.

Posted: **Tue Apr 22, 2008 5:34 pm**

Hello! I'm from the SharpOS project and wanted to let you know that there are already a few projects working on this: SharpOS, Cosmos, Ensemble... we are starting a forum for talking about managed OS projects at http://mosa.ensemble-os.org/.

SharpOS : http://sharpos.org/
Ensemble: http://ensemble-os.org/ (might be down temporarily)
Cosmos: http://gocosmos.org/

Posted: **Thu Apr 24, 2008 3:37 am**

Hi,

I'm very interested in this project and would love to have the time to commit to my own OS to do a managed code kernel. I shall watch the development of your wiki with interest to see how it develops.

It seems to me that many "successful" (and commercial) OS's out there are based on a monolithic design (I hope this isn't too much of a generalisation). It seems like all managed OS's are, as you would expect, microkernels which have gone one step further. From background reading, it seems like this is because server isolation brings performance penalties in the way of having to use IPC rather than function calls to communicate between the microkernel components.

At the risk of a thread hijack (this seems the most appropriate place), I would be interested in whether people generally feel that computing power has come along enough that a microkernel, let alone a managed code microkernel, is viable as a widely used desktop OS?

I suppose if you look at Vista's ring 3 drivers, the answer has to be 'yes', but I'm not too familiar with Vista's internals (is it a hybrid OS?).

Cheers,
Adam

OSDev.org

My first CIL OS...

My first CIL OS...

Oh uh

Other managed OS's

Other projects