Re: [Qemu-devel] [PATCH 5/8] tcg: Add interpreter for bytecode

[Stuart Brady <sdb@zubnet.me.uk>]

On Mon, Sep 19, 2011 at 09:24:47PM +0100, Stuart Brady wrote:
> On Sat, Sep 17, 2011 at 10:00:31PM +0200, Stefan Weil wrote:
> 
[...]
> > +            u64 = ((helper_function)t0)(tci_read_reg(TCG_REG_R0),
> > +                                        tci_read_reg(TCG_REG_R1),
> > +                                        tci_read_reg(TCG_REG_R2),
> > +                                        tci_read_reg(TCG_REG_R3));
> > +            tci_write_reg(TCG_REG_R0, u64);
> > +#endif
> > +            break;
[...]

> Unfortunately, this won't work on all architectures.

[...]

Stefan, have you had a chance to consider this, yet?

I think it would be nice to do this in a way that:

 * allows enabling TCI at runtime.

 * doesn't rely on a huge switch table or wrapper for every conceivable
   type of function.

   For example, if helpers have three argument types, i32, i64 and ptr
   and up to four arguments, together with return types of void, i32,
   i64 and ptr, we might have something like:
  
        4 * (3^4 + 3^2 + 3^1 + 3^0)
     == 376 wrapper functions (or cases).

   Most of these wouldn't be used for any given target.  This gets worse
   if we add a few extra arguments and types.  With up to six arguments,
   and an extra type, there'd be 26985 cases / wrappers. :-(

So, I wonder if it would be best to place this in the target and generate
a wrapper for each helper function.  When using TCI, we'd generate a call
to this wrapper function instead of the helper function.  No extra space
in the ops buffer would be required, since the wrapper function would
call the helper function directly, rather than taking it as a parameter.

This could be compiled out on those architectures for which the current
approach is okay.

If we wanted to allow enabling TCI at runtime, then we'd need to choose
between the wrapper functions and helper functions at translation time,
either in gen_helper_* or when generating the TCI bytecode by way of a
somewhat vile switch() statement...

Should I try to put something together?

Cheers,
-- 
Stuart