In fact, I said that because I already noticed the AOT compiler uses it. A modularized AOT would have a hard time implementing the sequence of the current AOT compiler exactly the same way. If the AOT compiler does not know what an optimization module actually does, it can't use it in custom loops. So we can implement this by executing all modular optimizations in sequence and repeating that until nothing changes.
The problem I see with that approach is: say optimization 1 likes to see the code in form 1, and optimization 2 likes to see the same code in form 2. Then they will both keep changing the same instructions to their point of view. The loop will continue forever. The current AOT does not have this problem because it can choose which optimizations are looped together. Somehow we should make those modular optimizations complementary, so they don't keep undoing and redoing eachothers work. Insite Mees-Delbeke VOF Zomerstraat 29A 9270 Laarne Telefoon: 09 367 96 34 GSM: 0478 44 96 04 E-mail: [EMAIL PROTECTED] Site: http://www.insitehosting.be -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Lahti Sent: donderdag 30 augustus 2007 7:49 To: sharpos-developers@lists.sourceforge.net Subject: Re: [SharpOS Developers] Proposal Yeah, I put a lot of effort into Scott's message before I realized the thread had grown larger than I thought. What Chriss said sums up much of my points. > Where optimizations in the block/SSA domain could be sequentially > executed and the sequence repeated until the code no longer changes. This is done in the AOT, but it's not readily apparent. On 8/29/07, Johann MacDonagh <[EMAIL PROTECTED]> wrote: > Here was my original idea for the AOT compiler. I started work on > this before Chriss came in and showed off his work. And then as time > flew by (and I was assigned to three research projects this > semester), I completely ran out of time and energy to keep this > project running. > > Anyway, my idea was very simple, but inefficient: > > If you look at the IL code, it's completely stack based. You push on > values, pop values off, different operations do different things to > the stack, etc... why not translate the IL into simple x86 stack > operations? > > For example, when you: > > int i = 5; > > in C#, the IL pushes that value onto the "IL stack". Why not simply > translate that into an x86 push operation? In fact, almost all IL > commands can easily be translated to simple x86 operations. The only > real issue is with the decimal type (80-bit ?), which doesn't > translate well to x86. > > The only thing we would have to standardize on is the memory layout > of an assembly. Is there a header which includes the entry points? Is > there a table which includes locations of all the classes and > methods? etc... We'd use a standard set of registers for each > operation. Meaning, when we want to do the IL add operation, we pop > the last two values from the stack off into a documented set of > registers, add them, and then push them back. As time went on, we > could combine common sets of operations for more efficiency. > > Like I said, I ran out of time and Chriss's solutions seemed to work > better at the time. Another issue was my frustration with developing > in MonoDevelop. Now I'm running Visual Studio through a VM on my > MacBook Pro (btw: svn supports conversion from CRLF's to LF's > automatically, so we can easily incorporate Windows and *nix > developers). > > Chriss's AOT compiler does a lot more than my simple compiler would > (mostly dealing with optimizations). If I had more time I'd love to > test out my idea though. > > Johann > > On Aug 29, 2007, at 2:27 AM, Chad Z. Hower aka Kudzu wrote: > > >> I don't think anyone here is questioning your contributions. I for > >> one > >> think you've done a great job with developing something like the AOT. > > > > After some pretty hefty review I have some pretty hefty thoughts on > > AOT. But > > Id like to talk to Chris 1:1 and get some more backgrounders before > > spewing > > my thoughts about. > > > > But I'll say this. AOT is core to this project. It needs to be > > modularized, > > opened up and heavily worked on. I also believe significant > > portions need > > thought about and likely redone. But if we modularize it a bit more > > and some > > of us help, the load wont all be on Chris and we can do it. > > > > > > > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a > > browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > SharpOS-Developers mailing list > > SharpOS-Developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > SharpOS-Developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
