Sunday, January 10, 2010

First LLVM-made binary

A small step for a humble programmer, a huge leap for Liberty project 
(Me - right now)
 LLVM wrappers begin to be functional; please have a look at LLVM example directory and lauch make; after a while you will find:

  • llvm_example : the executable made by SmartEiffel (we are using latest version from subversion repository)
  • example.bc:   LLVM bitcode, produced by llvm_example
  • example.s:    ASCII assembler program text, compile from bytecode by llc - the LLVM static compiler
  • example:      an ELF relocatable, made by as, usually the GNU assembler

A lot of works remains to be done in LLVM, I expect to work out several idea on actual implementation of peculiar technical details of the Eiffel runtime during the wrapping of the rest of LLVM.
I would say that since Eiffel choice not to have namespaces we shall have no name-mangling problems.

Tuesday, January 5, 2010

We need bindings not wrappers...

Interfaces to foreign libraries have been traditionally called bindings or wrappers. I never cared too much about eventual differences in meaning, I used to use them as synonims; now I'm beginning to realize that they have different meaning.
Let's speak in Eiffel or C/C++: a WRAPPER is a tiny reference (i.e. unexpanded) object containing a pointer to the unde lying data structure, think about it as a glorified REFERENCE[POINTER]; a binding - in my humble opinion - shall be a way to directly use the actual data structure as an Eiffel object, turning that pointer into the actual reference used on the Eiffel side.
Needless to say this double layer - WRAPPER and wrappee, referred thorught "feature handle: POINTER" pratically means to manually manage memory inside each effective wrapper coupling it with deferred classes that implements memory policies like EIFFEL_OWNED, C_OWNED, GLOBALLY_CACHEDMIXED_MEMORY_HANDLING, or REFERENCE_COUNTED.
This is how wrapping has always been done in Eiffel, either in Eiffel (in EWLC or EWG) or with C glue code (elj).
To bootstrap Liberty we still need them and we will still need them a lot after Liberty will be ready.
My proposal is to allow better integration with foreign languages or object-models, like C-with-Gobject or C++.
Surely both models do not perfectly map Eiffel's object way; we still will need to instruct Liberty on how to handle those datatypes generated by foreign code,
SmartEiffe started to develop external types, something  that eventually bring us "real bindings".
We need "only" to allow the developer of a binding to provide object_size, generator and generator_type.
Those will be interfaced the object-model facility of the foreign language, for example with C++ Run Time Type Identification, the C++ typeid operator and its std:type_info object; Gobject also offers a comfortable type system that will fit.
Obviously there will be mismatches, peculiarities and headaches but it can be done. Other languages have done it, we can also.
There will a cost. The cost is "diverging" farther from ECMA; I read the standard a couple of months ago and I wasn't satistied by what I read about integration with other languages. I had the impression they don't care that much about integration. What I found there was a language that already diverged from what we learned to love as Eiffel.
We standed still, they walked away. We shall find and walk our trail. Perhaps different, perhaps useful for a later merge.
Let's keep writing wrappers and not binding to bootstrap.