On Wed, Mar 10, 2010 at 3:16 PM, Philipp Klaus Krause <[email protected]> wrote: > It's frustrating to see that for many architectures used in embedded systems > programmers are stuck with C, and there seems to be no alternatives in > sight. Let's take the Z80 for an example. An old architecture, still used in > low-end embedded systems.
Realistically, the Z80 is no longer used in embedded systems. Even if you want an 8-bit processor, that particular architecture is both expensive and baroque. Regardless, BitC isn't targeted at processors below 32 bits. For one thing, current technology GC simply doesn't work very well in 64KByte memories. For another, the 64K memory constraint of those processors is so tight that it leads to a completely different set of representation tradeoffs. I'm prepared to believe that allocation-free BitC programs could be made to work on 8-bit processors, and if somebody wants to take that up I would be happy to try to advise, but BitC isn't being designed with those platforms in mind. Even C had to be subsetted for processors in the "smart dust" class. On the bright side, it would be pretty easy to devise a small footprint runtime without breaking the language specification. That's an option I had never thought about, and perhaps it's worth a little bit more thought on my part. > I have heard of people try to use llvm's C backend for > cross-compilation, but I have not seen any reports of success, and if > usable at all it seems to be a pain to set up. The last I heard (and it has been quite a while), the C back end for LLVM was suffering from sustained neglect, and was known to have a bunch of issues. I haven't looked at it recently. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
