At present, flxg generates code for programs and plugins.
However, we can't easily do "ordinary" separate compilation.
In particular if you write some functions in Felix which, by design, resolve
down
to ordinary old C functions, it would be nice to be able to generate an
object file or static link library and just be able to link against it.
[Header files are another issue!]
Advanced Felix functions and procedures require the garbage collector
which is stored in the thread frame so they have to be passed the thread
frame. Each thing flxg generates typically contains two functions:
<modulename>_thread_frame_creator
<modulename>_flx_start
The first one is the C++ constructor for the thread frame, which
contains the program or library global variables, the garbage
collector, pointers to stdin,stdout,stderr files, and argc/argv
program arguments.
The second one is used to "initialise" the thread frame.
For a typical program, this initialisation is the actual
program execution, i.e. the side effects of the initialisation
make the client think they're running a program (when
by design, they're actually just initialising the thread frame).
You can think of the first function as the "new" and "mem-initialiser"
phase of construction of the thread frame object and the
start procedure as the constructor body. After both are run,
the frame is ready for other exported functions in the library
to use.
However, a bunch of ordinary C functions don't need the thread
frame by specification of "ordinary C functions" :)
So we could do a couple of things here. We could make the creator
return NULL, and that NULL gets passed to the start routine as well.
Or we think about just not defining these functions, then we'd get
a standard C object file out with no Felix crap in it.
It's easy to leave out the thread_frame_creator with run time loading.
Instead of calling the missing symbol we just return NULL.
[Code in various places would have to be updated]
Similarly if the start procedure is missing, we just return a NULL.
Note that if you have a stackable start procedure, which includes
both C++ objects that go on the stack, and C functions, the normal
wrapper invokes them and returns NULL anyhow. If you have a
real heap continuation for the scheduler to run, it returns the
procedure closure so it can be scheduled.
So there's some real transparency possible here. The main problem
might be that it is no longer possible to tell the difference between say
loading a C library by mistake and a Felix library. You could run
the C library and nothing would happen -- no error.
It's doubtful we want that for a program. However consider that
you can run a Felix generated CPython module as a Felix program
OR load it as a plugin OR link against it as a library OR use it as
from Python. It maintains separate entry points for these things.
So its not necessarily wrong to "run" a library.
On the other hand it's seriously wrong to make a C library with
extra crud in it!
Now, this is all very well, but for static linkage it's a whole new ballgame!
Now, when we link a Felix program we HAVE to have the expected entry
points in it. It's OK for them to return NULL, but they have to exist with
a fixed signature.
Well .. that seems to be the case .. but it isn't!!
In fact, to link flx_run against a Felix program is impossible.
The reason is that for static linking plugins, we have to prevent
a name clash. We can't have to "start" routines.
So actually Felix generates names as shown at the top, with
modulename qualifiers, so plugins can be statically linked.
But then, how does flx_run link against a program? It doesn't
know the name of the module it has to link to!
The answer is: flxg generates "static link thunks". These are
just global variables with fixed names that *contain* the
addresses of the start routines of a program. It's a couple
of lines of C code which is compiled and linked to act
as a bridge.
"Every problem in computer science can be solved
by adding one more level of indirection" :)
So now, the compiler actually knows the entry points of the module
to store in these variables .. and it knows if they exist. If they don't
the variables could just contain NULL.
So actually leaving the symbols out is quite viable for program static linkage.
For static linking plugins it's a bit trickier, because the client programmer
has to write the bridge.
So now, to Philosophy! What should we do? At present you can demand
felix generate a C callable function like this:
cfun fred (x:int) => x + x;
This one is certain to have the type you expect:
int (int,int)
However if you put GC in the function won't work as expected.
[I forget if Felix puts the thread frame pointer in to the parameters
or not .. :]
Felix will generate C functions automatically whenever possible,
but this forces it. The idea is that if you expect a C function and you
do something naught in it, it will break when the function is compiled
(not when the call is compiled).
Doing stuff "automatically" is the Felix way, and then provide overrides
to force what you expect if you really need it. So it makes sense to
build a C library if possible. The real problem is how to force it.
It could be done with a switch to flxg, but I don't really like that:
the output of flxg is supposed to be invariant( no modes, etc).
I particularly dislike ocaml -pack for this reason. It is very bad style
to have the semantics of a program changed by compiler switches.
The semantics should depend on the source, not how you compile it.
In particular Felix
requires package "library"
clause ensures the semantic dependence on an external resource
is IN the source code. So I really don't like a switch that changes
the code flxg generates, although a switch which changes formatting,
commentry, or adds a check for a constraint is fine.
Why does all this matter??
THE ABILITY TO GENERATE STANDARD C CALLABLE LIBRARIES
IN FELIX IS A "KILLER" ADVANTAGE.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
