[bitc-dev] Conditional compilation
Jonathan S. Shapiro
shap at eros-os.com
Wed May 14 07:55:32 CDT 2008
I am coming to the reluctant conclusion that BitC needs a limited form
of conditional compilation system. Let me give two illustrations of the
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
This one is actually a nice problem to have, because (aside from the
effect on sizeof()) alignment is non-semantic from a program analysis
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?
More information about the bitc-dev