Re: define_c_func/proc and 64-bit return types
- Posted by mattlewis (admin) Jul 30, 2012
- 1343 views
C_DWORDLONG is the wrong constant... but strangely, C_DWORDLONG and C_LONGLONG both point to the same value in my copy of 4.1 ! I'll have to ask Matt about it sometime, when he's around...
In 4.1, C_LONGLONG is set to #03000002 - but that hex constant won't work in 4.0, since support for it is lacking in the backend.
Several things needed to be changed. In particular, things like C_INT and C_LONG were treated the same way in 4.0, which is a valid assumption for a 32-bit OS, but not for 64-bits.
I'm not sure what the intent of C_DWORDLONG was originally, but I must have suspected it was meant to be a 64-bit integer, and updated it accordingly. Note that the 64-bit types should work on 32-bit 4.1.
Another problem I've run into is a series of functions that take and/or return the following structure by value!
struct x {
float a;
float b;
float c;
float d;
}
Now, I can pass four floats to the function quite easily, but I'm thinking this 128-bit return value may be a problem for Euphoria. 
Hmmm....how does this actually work with the compiler? What's the convention?
So at this point I may have two options:
- Modify the source of the library to return int64_t and this quad-float structure by reference, then provide my custom-built library instead of the original.
- Write a shim library in C that links to the original library, reads the troublesome values and returns a pointer to them.
I agree with Jim. The shim is probably easier to deal with, though still a PITA. It might be easier, actually, to build the shim, then see if you can't rip out the machine code, poke it into memory and call it that way. That would alleviate the requirement of having to ship an extra, platform dependent binary.
Note, however, that Windows has defined its own 64-bit calling convention that is subtly different than what's specified by the AMD64 spec (or whatever it's properly called).
Matt
