Re: Preliminary libffi progress
- Posted by petelomax Oct 22, 2022
- 793 views
If ffi replaces dll.e, and Phix doesn't need to call dll.e, are there going to be more compatability issues when using Andy's (copious) output of libraries, eg SDL2, raylib and so on? If ffi is going to make things easier for Euphoria, is it going to make things more difficult for Phix? Or will Phix users just be able to call ffi, and have the same access to libraries using it for Euphoria?
I don't think so? I plan to keep the existing std/dll.e library around for a while and just mark its routines with deprecate until it's finally removed. I cannot speak to Phix as I've honestly no idea how DLL interfacing works there.
The Phix equivalent of dll.e is actually builtins\VM\pcfunc.e and that's a) likely to stay around a while (see below) and b) quite probably capable of having a new define_c_type() and whatever added to it.
After all, everything in that file and much more besides was all reverse-engineered from scratch to match Euphoria as closely as possible, in the first place.
Generally speaking, as long as things clearly crash on the right source code line, and force something like the following (only with lower-level code), that'll do, in my view.
--/* puts(1, "Eu prints this, Phix does not\n") --*/ --/* */ puts(1, "Phix prints this, Eu does not\n")
Are we looking at a separation fork event?
I've always maintained that this project (the "OpenEuphoria" group) maintains the reference implementation for Euphoria and that Phix is a dialect of that. If Pete wants to maintain Phix's compatibility with Euphoria that's great, but I'm not concerned about the reverse.
-Greg
Agreed. I'm not planning a separation fork event just yet, but I won't rule one out. If you really want to be worried, Phix supports the following right now (and has done for quite some time):
elsif platform()=LINUX then #ilASM{ mov eax,[var] shl eax,2 push eax call "libc.so.6","getenv" add esp,4 lea edi,[pRes] call :%pStoreMint }
Which is wholly incompatible with Euphoria, and may one day become the preferred manner of Phix interfacing with so/dlls.
As I mentioned, should it go that way it might force a whole layer of extra work on top of Andy and anyone else's output,
but as long as Phix can output the right, clear, meaningful, and genuinely helpful error messages, I'm not worried at all.
One thing I'm not planning is incorporating ffi.c or whatever it is into the phix executable like I believe Greg is planning,
maybe there could be (and I wouldn't deliberately stop) an ffi.dll knocking about for the few cases that actually need it.