Thanks to Eike for re-sending this to the list. There are a bunch of things
in here, so I'm going to hit a couple of them quickly and break out topics
for some others.

On Mon, May 14, 2012 at 1:25 PM, Eike Scholz <[email protected]> wrote:

> To test the runtime environment I decided to write my last prototype in C
> using the runtime-environment
> the generated code will used. Further C gives me a rough metric on bad
> design decisions that are not
> easy to implement. I avoid C++ though I really miss templates and
> overloading - but C++ abi just
> caused to much trouble, and C is easier to access from other
> languages,like C,Fortran, Python.
>

All of this makes sense. You will discover shortly that closures are a pain
in the ass to do sensibly this way. Fee free to grab the closure trampoline
code from the BitC tree. Look for the various arch-specific files
make_procedure_object.c down in libbitc/arch. Be advised that the one for
PowerPC is wrong, and that it isn't easy to do a decent trampoline
implementation for PowerPC because there are no free registers in the
calling convention for OSX. Now that Apple has moved to Intel, perhaps it
no longer matters.

To handle this problem, I introduced an allocation type, e.g.  the
> metacore-programmer
> can force allocation to occur on the call stack, like C automatic
> variables.
> i.e.
>
>    tmp var  x:FooDataType ;
>
> will force x of data-type FooDataType to be allocated on the stack. In
> conjunction with call by ref procedures
> this allows write C style code regarding local memory. This temp memories
> allows closures and
> dictionaries for (type) classes to be be allocated on the stack if
> possible, by using some simple form of
> allocation-type-inference.
>
> A generic allocation
>
>  var x:Foo ;
>
> will allocate memory onto the heap.


This has been done in several languages. It is generally referred to as an
unboxed type. Microsoft CLI refers to these as "value types".


> Of course the type system prohibits returning a pointer to temporary
> memory.
>

We started with that restriction too, but there are compelling reasons to
do pass by reference on such types, one of which is to be able to correctly
type the constructors. We came to feel in BitC that the right solution was
to expose region types.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to