[Liboil] [announce] oil-0.1.0

[cee1]

2009/8/27 David Schleef <ds at entropywave.com>
>
> This is exactly the case where the liboil model breaks down.  If
> you have one public symbol for a function that might be used by
> multiple modules in a complex application, the modules would
> potentially fight over which approximation to use.
>
> Also, in my observation, changing the underlying approximation for
> an algorithm changes more than just the implemenation of the
> liboil-like functions that would be used: it potentially changes
> the optimal memory layout, function prototypes, iterators, etc.
>
> For example, the idct8x8_s16 and idct8x8lim10_s16 classes in
> liboil do the same operation, but the latter limits the calculation
> to the lowest 10 coefficients of the 8x8 DCT block, assuming the
> rest of the coefficients are zero.  If these were merged into the
> same symbol, the calling code would have to always zero the upper
> 54 coefficients in case the non-approximated code was called (say
> for testing, or for the case where another module overwrote the
> preferred implementation.)  This negates much of the reason for
> using the approximation in the first place.
>

I agree in this case.

Generally, we need the the model of "one public function symbol, multiple
implements", because we can't decide which implement is suitable at *the
time*.

liboil can't decide which implements are suitable at build time, so it
builds a series of of implements at build time and activates some at
runtime.

Orc builds implements at runtime, it can know which implements are suitable
at this stage.

But doing too many things at runtime, as I wrote,  will a) either pull too
many dependencies. b) 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"?
>
> The source code is not hidden.  Short answer is "no".
>
> It seems binutils doesn't export C-APIs, so native code generation will a)
fork a process and execute "as" or b) generate machine code directly.

Orc takes the second way, it may need to maintain a map of assembly to
native code ?

Regards,
cee1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/liboil/attachments/20090828/880c4274/attachment.htm