[Next][Index]
Re: ILU for VHLL FFI [was: RFD: Programming Language Feature Matrix]
In article <LTH.96Jan17095953@blackrabbit.cs.uoregon.edu> lth@blackrabbit.cs.uoregon.edu (Lars Thomas Hansen) writes:
> There is already a system which does this for C++ and which targets
> Aubrey Jaffer's scm, by compiling the C++ definitions into
> scm-compatible C++ code which can then be linked into the interpreter;
> see
> http://www-white.media.mit.edu/~kbrussel/Header2Scheme
>
> However, Larry's (Dylan's) solution is much nicer, and I've been
> planning something similar for some time, only slightly more reusable.
> The basic idea is to provide a program which takes C header files (C++
> is probably a must at some point but a truly daunting task) and produces
> an easily machine-readable and -parsable intermediate form
> (s-expressions, say) which can then be converted to the quirks of an FFI
> for whatever Scheme system you're using (or to ILU ISL, for that matter)
> using a ``code generator'' written specifically for the task. Many of
> the code generators will probably be similar in structure, so one can
> expect some reasonable amount of sharing of labor even here.
>
> The current plan is to attempt to use the lcc front end for this
> project, although I have not looked at the code carefully enough to
> _know_ that it will be straightforward.
Another possible codebase to draw from is the LCLint toolset:
http://www.sds.lcs.mit.edu/lclint.html
LCLint
LCLint is a lint-like tool for ANSI C. It can be used like a traditional lint to detect
certain classes of C errors statically; if formal specifications are also supplied, it
can do more powerful checking to detect inconsistencies between
specifications and code.
Without specifications, LCLint does many of the checks done by a traditional lint.
It reports unused declarations, type inconsistencies, use-before-definition,
unreachable code, ignored return values, execution paths with no return, likely
infinite loops, and fall-through cases. It provides options for stricter type-checking
than standard C (e.g., char and bool types can be treated as distinct from ints.).
It does not do much of the portability checking (e.g., pointer alignment) done
by typical lints.
...
I haven't looked at the code, but it compiled and ran "out of the box" when
I was using it.
It has at least one novel feature: it groks macros. It doesn't lose
information in the pre-processing stage.
Dan
--
Daniel W. Connolly "We believe in the interconnectedness of all things"
Research Scientist, MIT/W3C PGP: EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
<connolly@w3.org> http://www.w3.org/pub/WWW/People/Connolly/