On Sun, 2008-11-16 at 00:44 +0100, Florian Weimer wrote: > Given the Ada/GNAT experience, I don't think representation > requirements at the language level are a good thing. There are just > too many ambiguities, and it's rather difficult to fit these > requirements on existing backends (but GNAT managed to do it even for > the JVM). > > If you write your own backend, this may not be an issue. But it will > make porting to anything else very difficult. > > IMHO, a library-based solution which combines address arithmetic with > bare-metal loads and stores is more desirable. But you'd need some > form of compile-time meta-programming to ensure safety while > preserving succinctness.
I believe this discussion around VMs has overlooked what I believe is one primary design objective for BitC: a language capable of direct hardware access, and capable of running on bare-metal. A language for kernels and embedded platforms. I believe there is nothing in the current language preventing a BitC program to be compiled to run in a freestanding environment, for instance (and that would have been on purpose). If being able to target a VM is a very good thing, it cannot come at the cost of losing the kind of low-level control you sometimes need in the environments BitC is concerned about. If all the hard low-level stuff is outsourced to a library, presumably written in C, isn't it somewhat besides the point? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
