I am coming to the reluctant conclusion that BitC needs a limited form of conditional compilation system. Let me give two illustrations of the problem:
1. Arch-dependent alignment I just spent two days hunting down a subtle C alignment problem. On the Coldfire CPU, int32 quantities are only aligned at 16 bit boundaries. Which is fine, except that the kernel re-entry stack pointer has to be aligned at a 32-bit boundary (this is a hardware restriction). By sheer dumb luck I had a structure that worked, and then I added a change that made it magically stop working. Other platforms have no such alignment constraint. This one is actually a nice problem to have, because (aside from the effect on sizeof()) alignment is non-semantic from a program analysis perspective. But the point is that real programs will require mechanisms that let them be parameterized to both the architecture and the target platform. 2. Debugging Elision In debugging some low-level (driver) Coyotos application code, I needed to introduce a bunch of printfs. In consequence, I had to give these applications a capability to a writable stream. In consequence, they are no longer confined, and in the production implementations they really need to be. It is easy enough to reconfigure the build to replace the logging cap with a null cap in production configurations, but in some cases it may be desirable to remove the debugging printf code entirely when no debugging I/O will be possible (note: probably not in this particular case, but in general). Now both of these use cases boil down to setting some constant value and then writing code that is conditional on that value. This can be handled through the module include system. The case that scares me more is the case where platform dependencies force us to change the type signatures of procedures. For example, the seek() system call on a 64-bit filesystem platform has a different signature than the one on a 32-bit filesystem platform. The problem with these cases is that they touch the type system, and that raises issues about type propagation, inference, and compatibility. Thoughts on how to handle this? shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
