[bitc-dev] C integration

Ben Kloosterman bklooste at gmail.com
Tue Nov 2 23:02:54 PDT 2010

Thanks Shap , 

Not too concerned on the GC integration at this point ( apart from not
breaking)  , the C circ buffer will be statically allocated and we will
custom write messages into this via stack ( so even no memcpy ).   The GC
will only be an issue for me if 
	it faults on an unknown reference 
	I copy stuff from the GC heap and it compacts concurrently 
	I copy stuff from the GC heap and it collects before completion (
easily solved by a dummy stack reference)
neither of which apply at this point ( I think) . 

Probably when BitC  produces the LLVM  tree I may have some issues but as
long as it outputs c ( which you intended to retain at least for a while)
it will work for the moment. 

This is my plan I think it will work with Bitc as it develops  
- Get BitC working
- update my C code remove some useless C++
- integrate BitC to call C circ buffer
- Convert and extend tests in BitC and record some notes  on BitC
- Basic BitC message pump and message Dispatch code
- BitC IPC Scheduling interaction  ( some more C)
- BitC runtime asynch extensions
- Sample apps Java and C# wrappers

I won't push it very far in terms of language at all,  I have looked at AOT
compiled C# for systems programming and its almost there but doesn't quite
tick the boxes ( though IMHO is still better than C and C++ for this) .


 >-----Original Message-----
 >From: jonathan.s.shapiro at gmail.com [mailto:jonathan.s.shapiro at gmail.com]
 >On Behalf Of Jonathan S. Shapiro
 >Sent: Wednesday, November 03, 2010 2:40 AM
 >To: bklooste at gmail.com; Discussions about the BitC language
 >Subject: Re: [bitc-dev] C integration
 >On Mon, Nov 1, 2010 at 12:44 AM, Ben Kloosterman <bklooste at gmail.com>
 >> Trying to work out how the C integration works...
 >Me too! :-)
 >So first, you should know that there really *isn't* any serious C
 >integration yet. There are a couple of runtime support routines, and
 >these simply won't work in their present form given concurrent GC.
 >They are enough for bring-up, nothing more. We need to understand the
 >GC environment in more detail before we can really address that. For
 >now, the best thing to do is not integrate any more C code than we can
 >The .bits files have nothing to do with C integration. Where a .bits
 >file exists, it is typically an implementation module that implements
 >the functionality of some interface.
 >The present "support" is part of the "black magic runtime", and it
 >consists of two parts:
 >1. For some functions declared in prelude.bitc, the corresponding
 >implementations are *macros* in runtime.h. These are generally
 >low-level intrinsics. Use of macros allows us to re-use the function
 >syntax and processing mechanisms without incurring a call overhead.
 >2. For "legitemate" external functions, the model is that you declare
 >the function in bitc with:
 >  def foo(args-with-types) : type external "optional external name"
 >Such a function may not be polymorphic. If no external name is
 >provided, the bitc mangling scheme prevails. You'll see a few of each
 >in prelude.bitc and in the vector library.
 >However, the interaction model between these functions and the runtime
 >is largely undefined at this point, and can't really be nailed down
 >until we have a sufficiently complete understanding of what GC options
 >we eventually want to support. There is no finalization model yet, for
 >For purposes of header synthesis, the process looks like this:
 >1. Set up some interface. The functions that you want to implement in
 >C should be specified as "external".
 >2. Set up a "gathering" interface - this is an otherwise empty
 >interface that imports all of the interfaces of your library. An
 >example is in libbitc/bitc-runtime.bitc. The purpose of this file is
 >to act as a root for instantiation and header synthesis.
 >3. Run bitc in header generation mode on your "gather" file. This will
 >produce the header[s] you need to import into your C code for linkup.
 >Hope some of that is helpful.
 >No virus found in this incoming message.
 >Checked by AVG - www.avg.com
 >Version: 9.0.864 / Virus Database: 271.1.1/3230 - Release Date: 11/02/10

More information about the bitc-dev mailing list