* Eric Rannaud: > 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).
Let me repeat that forcing explicit representation decisions on existing backends is rather difficult. It doesn't matter whether you traget CLR, JVM, LLVM, GCC, or any other independently developed backend, you basically end up treating objects with explicit representation of a sequence of bytes anyway (unless you are very lucky and the backend happens to offer the level of control you need, but it can deviate again if you don't control the backend). For instance, if you're doing memory mapped I/O, and you load values from to subsequent addresses, the backend may decide to merge the two loads into a larger load, confusing the device. > If all the hard low-level stuff is outsourced to a library, presumably > written in C, isn't it somewhat besides the point? What I was proposing is to have some low-level intrinsics for pointer arithmetic, loads and stores (which would be translated to bare-metal instructions if possible, exactly as requested), and some language layer on top of that for making it safer to use. This would remove a lot of complexity from the spec while not affecting usability, I think. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
