On Wed, 2008-05-14 at 12:21 -0400, Swaroop Sridhar wrote:
> > 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.
>
> I think what you are saying here is that we can parametrize functions
> over layout, alignment, etc., but this will complicate their signatures?
>
> For example: we could have
>
> seek: (forall (fs 'b) (fn ('b) ()))
Umm. No, this isn't what I meant at all. I think what I was saying is
that we need to look again at having some mechanism for typealias.
There is a two-sided problem here. On the one hand, we must enable users
to properly define something like off_t for their target platform. On
the other, off_t is an integral type, and valid programs are likely to
run into typing problems when the type of off_t changes. Off the top of
my head, I don't see a good solution for this at the moment.
> This is definitely true. Since layout/alignment constraints are not
> syntax directed, I think that they will increase the amount of
> annotations that the user must provide in general.
I'm not concerned here about annotation at all. If you want a
non-conventional layout constraint, we clearly cannot discover it "by
magic".
> The following paper uses a type/effect system for parameterizing C-like
> programs over low-level layout/alignment constraints:
> ``A Theory of Platform-Dependent Low-Level Software'': Marius Nita,
> Dan Grossman, and Craig Chambers
> http://www.cs.washington.edu/homes/djg/papers/tpdlls.pdf
Thanks for that pointer.
> In a way, this problem can be partially alleviated by using conditional
> compilation. For example, we already have support for the most trivial
> form of architecture dependent conditional compilation in the form of
> `word' type, which varies by architecture.
That isn't enough for the problem I am thinking about. The example
use-case was that int32 is 16 bit aligned on Coldfire, but I had a
structure containing a lot of these where one part of the structure
really needed to be aligned at a 32-bit boundary.
> A similar approach is proposed in
> ``Automatic Transformation of Bit-Level C Code to Support Multiple
> Equivalent Data Layouts'': Marius Nita and Dan Grossman
> http://www.cs.washington.edu/homes/djg/papers/nita-cc08.pdf
I'll look at that too.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
