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. > 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). > 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. > > > > 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? > > 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). > 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 > > ------------------------------------------------------------------------- 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
