> > > > 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.
>
> I see what you're saying. Well, my overall plan was to ship a AOTed
> system for the lowest common denominator for each processor
> architecture (x86, PPC, etc...). The actual installation procedure
> would have the plain IL assemblies and would AOT them to the specified
> system.
>
But thats the beauty of it! There is nothing about what we are currently
planning, that doesn't make this impossible. I personally don't favor it,
but there are certainly cases where AOTed is the only thing that makes
sense. (Like embedded in devices, and other restrictive situations.)
>
> The operating system will still verify the IL assembly before allowing
> it to run. For my implementation, we have to assume that the kernel
> and mscorlib and safe. Additional assemblies (especially user made
> ones), will be verified, AOTed (with the AOT binary cached away
> somewhere), and ran.
But verifying the IL and verifying machine-code resultant from an AOT
operation are two different things. Particularly, one is possible, and one
is not. ;-) You would have to decide on some way to protect the AOTed code.
Make it user-inaccessible. I don't know that .NET actually does this, but I
would think it should be required in our situation.
>
>
> > > > >
> > >
> > > > > 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.
>
> So, I guess my question is, is there any tangible benefit to JIT
> compiling vs AOT compiling?
AOTed code runs faster. JITed IL is most effecient for the natural mixture
of metadata and code, not to mention verifyability.
> > > 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.4seconds.
> > Thats 20278 IL instructions, throughout 567 methods in 91 classes. On a
> 1.4
> > ghz machine.
>
> I didn't mean quick in that sense. I meant something i can quickly
> throw together to generate exactly what I want. Once we know that it
> works, and we decide to do so, we can tweak Darx's AOT (essentially,
> AOT'ed binaries need a header so the operating system can plug in
> links to external libraries, and a few other things).
I know DarxKies' AOT outputs a COFF symbol table. As far as PE binaries and
the like, I know nothing about - but I think there might be some
possibilities for that. I mean, we will want a normal "ngen" type AOT
functionality eventually, anyway.
-------------------------------------------------------------------------
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
