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) .
Ben
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>On Behalf Of Jonathan S. Shapiro
>Sent: Wednesday, November 03, 2010 2:40 AM
>To: [email protected]; Discussions about the BitC language
>Subject: Re: [bitc-dev] C integration
>
>Ben:
>
>On Mon, Nov 1, 2010 at 12:44 AM, Ben Kloosterman <[email protected]>
>wrote:
>> 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
>help.
>
>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
>example.
>
>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.
>
>
>shap
>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
>03:34:00
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
