Re: pointers to variables
- Posted by mattlewis (admin) Aug 02, 2009
- 1198 views
This is possible. If you're calling your routines via c_func/proc, use the E_* data types when defining them. The parameters will be passed with the 'raw' object values. The original use for this was for calling euphoria translated dlls, but you can use it in other ways. In wxEuphoria, for example, I directly manipulate euphoria objects using C.
Hi Matt. Yes, I did consider such a method, but thought it could be quite complex. Let's see if I understand correctly.
- I would need to allocate a block of memory
- poke in a preamble to set up/access the stack frame? if required.
- poke in my code from the mini-assembler, including (hard)code to access E_* data types.
- poke in more code afterwards to tidy up and return the new E_* object
- feed the address of the block into define_c_func along with parameter info
- cross fingers and use c_func to call the routine
Would it work? what have I forgotten?
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. 
This still would not protect me from object implementation changes in new forms of Euphoria as I could not get at the E_* data type declarations from the mini-assembler and any accesses to the type would need hard-coded parameters.
You'll still be vulnerable to changes in the representation, though I don't think there's a terribly large risk here. At least not from reading. The structure has changed for 4.0, but you don't really need to worry unless you're allocating new objects. So the euphoria ABI, at least with respect to native data types has changed somewhat, but is also backwards compatible, at least for reading. We've added a pointer to the structure, which is usually null, but if not, tells euphoria how to manage auto-cleanup for the object.
I had to update wxEuphoria, which is written in C, and manipulates native euphoria data. The change was 2 or 3 lines, and now it works with both 3.1 and 4.0.
But it occurs to me that this would be the case anyway with a dll/so and therefore hesitantly conclude the E_* data type is a fixed representation of an object that the interpreter probably does not use internally. Please correct me if this is not the case.
I'm not sure what you're saying here. Euphoria objects take three forms:
- 31 bit integers
- doubles
- sequences
31-bit integers are what they are. The other two are actually structures, and the pointer is shifted, with a mask applied to indicate whether it points to a sequence or a double (atom). This requires that the pointers are 8-byte aligned. Take a look at execute.h for the details. And please ask any questions you might have about how to use them.
Has anybody tried constructing a dll/so in memory like this? It occurs to me this method would be made simpler by using an external assembler like MASM or such to build a proper dll/so from the source, and then simply treat it like any other shared library. This is not what I want, Towing a heavy full-featured macro assembler behind what should be a fast, lightweight include file or requiring it as a dependency is too ugly.
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
