> Why is everyone so adamant about JIT compiling code? If you notice,
> Microsoft themselves tends to AOT compile assemblies (see SQL Server
> 2005 Manager). My original plan when I started this project was to AOT
> everything. When a user downloads a library / application, it comes in
> an IL assembly. The first thing the operating system does it AOT
> compile it.
Most of us were not around when you formulated your "original plan", so you
can't blame us for not knowing for *sure*. Sorry dude.
But honestly, the JITing is what makes the project semi-special. If you are
AOTing stuff all the time, then you are literally perverting C# into some
cleaner-than-thoughart form of C++. Seriously. And as a side note, you can't
AOT generics code. There still has to be a JIT in the background to handle
generics when they are encountered.
Microsoft (and even Mono) both AOT core assemblies. (But if you apply my
generics comment, you'll know that even the AOTed assemblies, in both cases,
still rely on a VES with JIT.) But there is no reason that our OSes GAC
won't have AOTed copies of installed assemblies. AOTing is considered an
*extra*, *optional* step. We lose all the joy in what we are doing if we AOT
everything.
>
> So, yes, in my model, init is AOT compiled as EIC, and the kernel and
> mscorlib and AOT compiled as EDC.
Well, I think thats what all of us are planning to do right now. Except
thats where we draw the line at AOTing (other than the JIT). And everything
else gets JITed.
If you ignore features such as reflection, exception handling, and a
> few others, the only thing a running .net assembly needs is a stack
> and a heap. The stack stores both the values of structs (which
> includes the primitive types), and pointers to instances of classes.
> The actual instance of the class is stored on the heap. So, if I have
> this C# code:
>
> int i = 5;
> object o = new Object();
>
> The stack will contain both the Int32 value 5, and a pointer to the
> object class. The heap contains the actual object class, which is
> empty. For each object on the heap, we need to store the number of
> pointers to it, so the garbage collector can do it's job. Haven't
> figured out the best way to do that yet.
Actually, .NET and Mono don't do reference counting in that since. They
actually, on each collect, scan all fields for object reference and
cross-reference with what is allocated. Sounds rough, I know. And I'm not
sure what SharpOS is going to do yet.
> Anyway, I'm going to attempt to write a simple AOT, just something
> that does exactly what I need. Hopefully I can have a prototype of
> what I'm trying to do and we can see if it's a viable course.
>
Well, we already have an AOT. And it still doesn't do everything you want it
to do (and DarxKies has put alot of work into it, you should definitely
check it out). And it doesn't do anything any different really, other than a
couple hacks so that we can generate arch-specific statements (because we
need to interface with hardware), and do some namespace remapping (so that
our arch-specific code is abstracted properly). Nothing fancy, hard, or
deleterious to any OS AOTing needs.
As far as the AOT works, you haven't described anything that we aren't
already working on. I mean, obviously you are welcome to give it a shot. But
by the time you've pulled something off, we'll be further along our current
track, which honestly isn't that far off from what *you* would rather do.
The only thing different is when you want to see IL compiled into machine
language. Not how. You could always just stick around, and when the AOT gets
good enough, you can start a branch/sub-project of SharpOS, that would
essentially be the same as SharpOS, with only slight differences to
operating parameters, as far as making it work the way you want to. It would
take minimal effort to keep your branch updated, and we'd have all the same
code in common.
But thats just a suggestion. And this is open-source after all, so just keep
in mind: SharpOS is GPL v3 with Classpath Linking Exception for Libraries.
Good hunting!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
