[Liboil] [announce] oil-0.1.0
ds at entropywave.com
Wed Aug 26 12:01:58 PDT 2009
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
> 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
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
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.
More information about the Liboil