search for: foojit

On Tue, Nov 16, 2010 at 9:39 AM, James Molloy <James.Molloy at arm.com> wrote: > Hi, > > I've been watching the MC-JIT progress for some time, and #2 certainly > looks like the best idea to me. I think however you've missed an important > selling point of the "FOOJIT" architecture: > > * The use of a custom object file format directly enables the use of > ahead-of-time compilation (using the JIT to recompile dynamically). Not only > this but it allows the resaving of any functions that may have been > JIT-optimised during runtime so they can...

Hi, I've been watching the MC-JIT progress for some time, and #2 certainly looks like the best idea to me. I think however you've missed an important selling point of the "FOOJIT" architecture: * The use of a custom object file format directly enables the use of ahead-of-time compilation (using the JIT to recompile dynamically). Not only this but it allows the resaving of any functions that may have been JIT-optimised during runtime so they can be used immediately nex...

...code in the right place and update various state information. This is the most obvious approach, is roughly similar to the way the existing JIT works, and this is the way the proposed MC-JIT patches work (see MCJITState object). It also happens to not be the approach I want to take. :) #2 (aka FOOJIT) - MC grows a new "pure" backend, which is designed around representing everything that "can be run" on a target platform. This is very connected to the inherent capabilities of the hardware / OS, and is usually a superset** of what the native object format (Mach-O, ELF, COFF) c...

...9:39 AM, James Molloy <James.Molloy at arm.com> wrote: >> >> Hi, >> >> I've been watching the MC-JIT progress for some time, and #2 certainly >> looks like the best idea to me. I think however you've missed an important >> selling point of the "FOOJIT" architecture: >> >> * The use of a custom object file format directly enables the use of >> ahead-of-time compilation (using the JIT to recompile dynamically). Not only >> this but it allows the resaving of any functions that may have been >> JIT-optimised during...

...us state information. > > This is the most obvious approach, is roughly similar to the way the > existing JIT works, and this is the way the proposed MC-JIT patches > work (see MCJITState object). > > It also happens to not be the approach I want to take. :) > > > #2 (aka FOOJIT) - MC grows a new "pure" backend, which is designed > around representing everything that "can be run" on a target platform. > This is very connected to the inherent capabilities of the hardware / > OS, and is usually a superset** of what the native object format > (...

...s is the most obvious approach, is roughly similar to the way the > > existing JIT works, and this is the way the proposed MC-JIT patches > > work (see MCJITState object). > > > > It also happens to not be the approach I want to take. :) > > > > > > #2 (aka FOOJIT) - MC grows a new "pure" backend, which is designed > > around representing everything that "can be run" on a target > > platform. This is very connected to the inherent capabilities of > > the hardware / OS, and is usually a superset** of what the native >...

...the most obvious approach, is roughly similar to the way the > > existing JIT works, and this is the way the proposed MC-JIT patches > > work (see MCJITState object). > > > > It also happens to not be the approach I want to take. :) > > > > > > #2 (aka FOOJIT) - MC grows a new "pure" backend, which is designed > > around representing everything that "can be run" on a target platform. > > This is very connected to the inherent capabilities of the hardware / > > OS, and is usually a superset** of what the native ob...