On Dec 27, 2007 2:40 AM, Johann MacDonagh <[EMAIL PROTECTED]> wrote:
> On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
> >
> >
> > > 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.
>
> Sorry, I didn't mean the tone you probably inferred from my statement.
> I'm just lost when it comes to what we're doing now.
I can understand that. I spent a couple months away from the project, about
6 months ago, and I was lost when I came back...
>
> > 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.
>
> And this is where I get lost. JIT code is nothing more than a
> real-time AOT compiler. Sure, there are a few optimizations it can
> make depending on the situation, but in general, it's the same.
>
> Generics can be AOT compiled. It's not currently implemented with
> Mono's AOT, but they're working on that
> (http://www.mono-project.com/AOT).
That, is very curious.
>
>
> > 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.
>
> To me the special part is the fact that the code was originally
> written in C#. It's easy to maintain, keep secure (requiring all user
> code to be safe), etc... Just because what the user is actually
> running is the actual machine code that the AOT created, doesn't mean
> that it's not elegant.
But anyone can dump machine-language code to disk. And machine-language code
can't be verified the way CIL can. CIL is safer that way. With AOTed
assemblies everywhere, there is no safety net. No gauruntee that a real .NET
language was used at some point in the past. And with IL - you can always
guaruntee that you can copy the DLL to a friends computer and it will simply
work or not work. No other hassles.
> > >
> > > 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.
>
> Now, when you say JIT, do you mean a full JIT implementation (JIT
> compiling methods as they're used), or do you mean JIT compiling the
> entire assembly just before it's executed?
Both are possible. With the same JIT. Right now DarxKies is working on the
runtime support (boxing/unboxing, stuff like that) - but telling the AOT
(the form of which that has been AOTed and embedded in the kernel), to take
a method and generate machine-language code, is already rather easy. The
only extra work that has to be done is teaching the AOT to reach out into
the RAM around it (instead of a kernel binary that its generating), to get
metadata to link the currently JITing code to.
>
> > > 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.
>
> I plan on using DarxKies's AOT compiler in the future. It's fantastic.
> However, I just need something quick that will generate the binary I
> need (it's mostly just with the header that I need).
DarxKies' AOT has been recently made very very quick. On my laptop, it
compiles the trunk kernel (plus a few local modifications) in 5.4 seconds.
Thats 20278 IL instructions, throughout 567 methods in 91 classes. On
a 1.4ghz machine.
-------------------------------------------------------------------------
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
