lua-users home
lua-l archive

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

On Monday 31 January 2005 03.44, skaller wrote:
> On Mon, 2005-01-31 at 13:20, David Olofson wrote:
> > > This would simplify the core, slow down processing due
> > > to the indirection, and make things extensible,
> > > since you can replace the 'add' function.
> > 
> > Dunno if it would slow things down all that much, actually... 
> > through function pointers are slightly slower, but switches and 
> > conditionals aren't exactly free either. 
> Sure but I actually meant the bytecode should call a *Lua* function
> not a C one.
> I.e. it should treat
>  a + b
> just the same way it treads
>  add (a,b)
> right now. The standard library would predefine 'add'
> to work just the same as 'a + b' does right now..

Well, that would just be an implementation detail. At least, EEL calls 
C and EEL functions the same way, and that could be extended to work 
for operators as well. One would just have two pointers for each 
operator "hook"; one C function pointer that may point directly to a 
native implementation, and one pointer to a bytecode function object.

To install a bytecode operator, on would just set the bytecode 
function pointer to it, and then point the C function pointer to a 
function that performs a VM call instead of actually performing an 
operation. No performance penalty for native implementations!

> However since lookup in Lua is dynamic .. you could replace it
> at run time :)

That works with a raw array of function pointers as well. ;-)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> -'
   --- --- ---