l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: figure vs. libvk [was: Portability]


From: Gordon Matzigkeit
Subject: Re: figure vs. libvk [was: Portability]
Date: 05 Nov 2000 21:10:21 -0600
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

>>>>> Farid Hajji writes:

 FH> Thanks for the hint. This is really interesting, but, as you've
 FH> put it, quite ambitious. I've just downloaded the latest figure
 FH> release and will have a look at it.

Please don't be put off by the state of the code, remember that it's
still pre-0.1. :) Better things are coming soon.

 FH> libvk is not intended to be a _binary_ interface, but a true API.
 FH> At least, its public interface should remain constant across
 FH> different platforms/ukernels.

My words were not very clear.  What I meant is that with a traditional
``C API,'' you are actually specifying a strict interface.  The
advantage of having a compiler is that you can customize the glue code
according to how the interface is used on a per-application or even
per-invocation basis.

So, one application may transfer lots of blocks of memory to other
tasks.  That may be hard to notice and optimize at compile-time, but
with the appropriate profiling, an in-process compiler could notice
such a trend, and put more work into optimizing memory transfers.

That's the kind of scenario I'm after with Figure... programs that may
be slower to get going, but optimize themselves over time.

But I only mention that as an example of how Figure differs from
defining a cross-platform API.  Your approach (hand-written
interfaces) will probably be better in this specific case just as
hand-written assembler will be better than a higher-level language.

That's all just food for thought.  Please do post your summary of
cross-platform interfaces in the Hurd, when you have time!

-- 
 Gordon Matzigkeit <address@hidden>  //\ I'm a FIG (http://fig.org/)
Committed to diversity and freedom \// Try Emacs (http://fig.org/gnu/emacs/)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]