On Wed, Mar 10, 2010 at 2:28 PM, Michal Suchanek <[email protected]> wrote: > Remember, Java is used on cellphones and even chip-cards.
300 Mhz to 1 GHz ARM7/9 with 64 MB of RAM don't really qualify as constrained embedded platforms at all, on which many critical applications run. Java Card is a peculiar beast that is quite different from Java. In many ways, it's a different language with a similar syntax and some common tools. See http://en.wikipedia.org/wiki/Java_Card#Java_Card_versus_Java > Besides that I read something about targeting assembly just a moment ago. The point he is implicitly making, is that it's a lot more work to support a new platform if you need to write a new assembly target than if you can simply reuse the existing C target. Some embedded targets have semantics quite different from x86, which would demand from the BitC assembly generator to be quite generic (alignment, ordering, etc.), in order to support many possible modes. If you target C, you rely on the work already done by the vendor with its C compiler to get the semantics of the target right (which can be a bit tricky). LLVM is in many way very close to C in terms of the language semantics it can express easily (e.g. out of the box, it supports only Unix and Windows C calling conventions, plus a "fast" one). It is true that it's more generic, and that it is extensible (although this implies extending the various LLVM assembly emitters as well). Targeting assembly instead of C in the main BitC implementation will not be a huge obstacle to supporting common embedded targets like ARM or PPC. It would make it somewhat harder to support others that are less mainstream. Nothing would prevent interested parties to develop a C target later down the road, however. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
