Re: pointers to variables
- Posted by prickle Aug 02, 2009
- 1238 views
Yes, you'll need to make sure you deal with the stack correctly. This depends on your calling convention, and whether you use any. If you use cdecl, you won't need to clean up the arguments that were passed on the stack. Once you have your code poked into memory:
constant my_asm = define_c_func( "", {"+", my_asm_ptr}, {E_OBJECT}, C_INT )
The above would set up a handle for using c_func() to call your asm that took a euphoria object as a parameter and returned an int. There's really no finger crossing required. 
I have done this before (though it was a while ago, and I don't have the source any more). The biggest hurdle for me is just writing the assembly code.
Matt
Fabulous. Thanks heaps Matt. This is the method I will pursue. As far as the assembly is concerned, I do not expect to write much either, or rather write it all up front 
. I intend to bring my JIT compiler up to date. At the moment, it is not much more than a dynamic expression evaluator that compiles to x86 FPU mnemonics. I would like to bring it up to a standard comparable to GNU Lightning or PyCORE to make it more generally useful to people other than me.
It needs better variable handling and more general purpose statements to make it an actual language. The code it generates is by no means optimal but it tries to minimise loads and stores by evaluating as much as possible using the FPU's own stack. I also wish to support MMX, SSE and the upcoming AVX SIMD architectures.
Don't expect anything soon of course. The codebase for the expression evaluator is ugly, dusty and looks completely alien to me despite the fact I wrote it. It's resurrection is currently still in the planning stage.
The evaluator was primarily used to build the NickFrac screen saver. Kind of defeated the purpose, maxxing out the FPU in spikes of activity while spending most of the time waiting for pixels to be shuffled into Windows' GDI. The DOS version of the screensaver (unreleased) runs full speed though. The evaluator is currently for asm users, as activities like looping still need hand coded x86. It is undocumented, unwieldy and unfinished which is why I never released.
It may be appropriate to start a new thread in order to invite discussion on this matter. I believe I have demonstrated the efficacy of this method as a way of bringing real performance to Euphoria with a high-level language model. The possible benefits of a full function JIT compiler for Euphoria would appear to extend far beyond my own goal, a proper fractal explorer.
Is this the kind of thing people want, or is it just me?
Nick
