This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I really don't want to write a JIT/AOT myself

Note: This was originally posted on 11th August 2010 at http://forums.arm.com

It seems that I have to raise the chip performance through this way, and I was acknowledged of Ubuntu recently got some from arm.
I don't want to spent time uselessly at writing the samething again(wasting your time or mine). But can that JIT/AOT work on a chip with less than 20 KB ram? Is there anyone know the detail? Some article said it boosts speed to 14X, is that true?
Parents
  • Note: This was originally posted on 13th August 2010 at http://forums.arm.com

    In all honestly 20KB of RAM is not much if you have a "typical JIT" - assuming you can load the bytecode from Flash, then you need space for: output JIT'ted code, the JIT itself, any interpreter support, two stacks (one for JIT/interperter and one for code), and then any data your program is actually using.

    If you can restrict the bytecode to something simple (relatively flat mapping to the hardware ISA), and have a design with a very limited support library then it could be done. This type of micro-bytecode has found use in some boot-strap type code in many devices (BIOS chipsets often run a bytecode). Assuming you want to JIT something like full Java, then probably not possible in 20K, but then I've never really tried either.

    To be honest, It's harder to have a big ram than to have a big flash, isn't it?
    So taken in the trade off, we'd perfer some kind of mixed up codes, for better performance and for less money to spend.
    Even if we cannot really implement a fully functional AOT embeded, we could try to make something generate C code on PC. To understand this, I must tell you about some thing in our company...

    Our engineers provided the key system for our products in java form, so my group was focusing on the performance issues and some other things platform related. And, after several tests, we draw the conclusion ---- a native system could be faster. My leader choosed to hand-rewrite the system, while I choosed to make a AOT/JIT.

    That's the case. Isogen74, my working condition may limit the ram size to lower than 10 KB, how about that? :-)
Reply
  • Note: This was originally posted on 13th August 2010 at http://forums.arm.com

    In all honestly 20KB of RAM is not much if you have a "typical JIT" - assuming you can load the bytecode from Flash, then you need space for: output JIT'ted code, the JIT itself, any interpreter support, two stacks (one for JIT/interperter and one for code), and then any data your program is actually using.

    If you can restrict the bytecode to something simple (relatively flat mapping to the hardware ISA), and have a design with a very limited support library then it could be done. This type of micro-bytecode has found use in some boot-strap type code in many devices (BIOS chipsets often run a bytecode). Assuming you want to JIT something like full Java, then probably not possible in 20K, but then I've never really tried either.

    To be honest, It's harder to have a big ram than to have a big flash, isn't it?
    So taken in the trade off, we'd perfer some kind of mixed up codes, for better performance and for less money to spend.
    Even if we cannot really implement a fully functional AOT embeded, we could try to make something generate C code on PC. To understand this, I must tell you about some thing in our company...

    Our engineers provided the key system for our products in java form, so my group was focusing on the performance issues and some other things platform related. And, after several tests, we draw the conclusion ---- a native system could be faster. My leader choosed to hand-rewrite the system, while I choosed to make a AOT/JIT.

    That's the case. Isogen74, my working condition may limit the ram size to lower than 10 KB, how about that? :-)
Children
No data