On Sun, 2008-11-16 at 13:47 +0100, Florian Weimer wrote: > 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).
Well, it was my understanding that BitC representation requirements were essentially those of C, and therefore would not be difficult to implement on C-like backends (GCC, LLVM, etc). > 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. That's a problem you can have in C anyway, as some hardware will perform this kind of merges. You need memory barriers for that. > > 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. I suppose the challenge is to guarantee that you do not, indeed, affect usability. It appears difficult to find a set of low-level operations that would be universal. Sticking to C-like semantics more or less guarantees everything can be done. Also, this topic raises the question of inline ASM. The amount of inline ASM needed in an operating system kernel to guarantee correctness in a number of situations is quite large. GCC __asm__ with its operand constraints seems often adequate. I am not sure what BitC will do in this respect, but I don't see how inline ASM can be left out. Some amount of language support is necessary; GCC provides register typing, register location constraints, and maps C expressions to ASM operands (section 5.34 of 'info gcc'). As much is needed for correctness and optimization support. BitC could conceivably provide more, with a labeling system to give as much semantic as possible to an expression which is by itself beyond BitC's grasp. This is not incompatible with what you suggest. Instead of a fix set of intrinsics, you provide a specification language for externally implemented operations, when these cannot be properly understood through a simple functional interface, as in the classical "Threads cannot be implemented as a library" problem. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
