[Liboil] [announce] oil-0.1.0

[cee1]

2009/8/27 David Schleef <ds at entropywave.com>

> On Wed, Aug 26, 2009 at 08:43:59PM +0800, cee1 wrote:
> > ORC concerns how to define a higher level assembly code and translate it
> to
> > native assembly code for each architecture. (dave, am I right ?)
>
> That's about 10% of what Orc does.  Orc, plus a .orc file to
> describe liboil functions, is a complete replacement for liboil.
> (Er, sort of.  Orc can't create code for about 10% of liboil
> functions.)
>
> > ORC can also be thought as something in the toolchain. A "complier" (ORC)
> > plus a "test tool" (oil), I don't think there is any overlap between ORC
> and
> > oil.
>
> Orc has testing built in.  Not only does the Orc test suite create
> a bunch of functions, execute them, and compare the results to
> reference functions (similar to liboil), the command-line parser
> (orcc) will also create a test program for a developer to put in
> their own test suite to do the same level of testing on any function
> he/she writes.  And if you want to be overly careful and do all
> the tests at runtime, you can do that, too.
>
> The only major feature of liboil that is missing from Orc is speed
> testing.  In Orc, speed testing is only a minor feature, since
> it's only relevant when hacking on the code generator.  And my
> manual tests indicate that the generated code is so fast that the
> code generator is not a concern.  There are more interesting
> low-hanging fruit.
>
> Even in the new Orc world, there is a place for something like
> liboil, for those cases where people still need some hand-crafted
> assembly.  Keep in mind that simple hand-crafted assembly can be
> accomplished using user-defined Orc opcodes.  For those cases
> where you really need to write 100's of lines of assembly, the
> tools in liboil are extremely useful.  But forking is unlikely to
> be the answer -- the correct answer is likely to export a few
> internal functions in the API and build tools around that.
>
> Liboil is now in desperate need of an ABI bump and thorough cleaning
> to remove any functions that can be done with Orc, under the
> assumption that the remaining bits of liboil would have any value.
> I have very little interest in doing this.  So a lot of the things
> you want to do are welcome in mainline liboil.  And if there's an
> ABI bump, things like splitting the library into parts could be
> acceptable as well.
>
>
>
> dave...
>
> Hi dave,Thanks for the explanation.

Some thoughts:
1) liboil and oil defines a model: a public function symbol which is bound
to one of a series implements. Orc will generate only one proper implement
for such a function symbol(again, am I right?). This applies well to the
case of inline assembly optimization, but what if approximation algorithm
optimization? I think we still need the model of one public function symbol,
multiple implements.

2) Does Orc perform runtime test like liboil? Sometimes, developers may want
to customize the process of testing, e.g. embed oprofile to do performance
analysis. So extension-friendly APIs make sense, but performing runtime test
will a) may not be accurate. b) either pull too many dependencies. c) or
have some duplicate code to implement some features(e.g. OilString in liboil
and GString in glib)

3) How to generate code in runtime? fork a process and exec "as"?

Regards,
cee1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/liboil/attachments/20090827/c5e58b77/attachment.html