Hi, I am trying to figure out, how to build FFI plugin on macs for cog vm. the platforms/Mac\ OS/plugins/SqueakFFIPrims contains following files: Info-SqueakFFIPlugin__Upgraded_.plist SqueakFFI.xcodeproj.zip SqueakFFIPrims.proj.xml ppc-darwin-Carbon-UI.c ppc-darwin-asm-MacIntel.S ppc-global.h resources sqMacFFI.s sqMacFFIPPC.c sqMacIntel-Win32.c x86-sysv-MacIntel.c x86-sysv-asm-MacIntel.S something tells me that i don't need to compile ppc* files, because Cog doesn't works on that arch anyways.. so, i tried to use sqMacIntel-Win32.c and failed.. then tried to use x86-sysv-MacIntel.c and it fails to compile with same error(s): /platforms/Mac OS/plugins/SqueakFFIPrims/x86-sysv-MacIntel.c:127: error: ‘FFICallTypeCDecl’ undeclared (first use in this function) /platforms/Mac OS/plugins/SqueakFFIPrims/x86-sysv-MacIntel.c:128: error: ‘FFICallTypeApi’ undeclared (first use in this function) These constants are defined only in FFIConstants shared pool.. and somehow they should be made available to these .c files.. But our beloved VMMaker's code generator don't generating headers which can be included by other .c files, and all class var constants are just printed inside a body of generated .c file , like SqueakFFIPrims.c which means that these constants should be defined externally manually somewhere. So, it seems like FFI is broken for Mac+Cog. P.S. Eliot's default .xcodeproj for FFI plugin are not builds because its not including one of the files above, which making a build complete (otherwise you got undefined symbols). Please shed a light, if FFI for Mac + Cog were in working state at some day? Or i doing something completely wrong? Of course i can disable it from build and forget about it, since we have new stuff coming (of course if Santa decide that we were good boys), but still.. -- Best regards, Igor Stasenko AKA sig. |
Hi Igor, I discovered that a similar problem happens also in the I32ABI plugin sources, the file ppc32abicc.c (which, by name, shouldn't be present in my compilations) is in fact required and works (afaik) properly. Perhaps the name is just a "legacy name"? Perhaps you have the same kind of problem? Cheers, Esteban El 27/12/2010, a las 12:20p.m., Igor Stasenko escribió: > > Hi, > I am trying to figure out, how to build FFI plugin on macs for cog vm. > > the platforms/Mac\ OS/plugins/SqueakFFIPrims contains following files: > > > Info-SqueakFFIPlugin__Upgraded_.plist > SqueakFFI.xcodeproj.zip > SqueakFFIPrims.proj.xml > ppc-darwin-Carbon-UI.c > ppc-darwin-asm-MacIntel.S > ppc-global.h > resources > sqMacFFI.s > sqMacFFIPPC.c > sqMacIntel-Win32.c > x86-sysv-MacIntel.c > x86-sysv-asm-MacIntel.S > > > something tells me that i don't need to compile ppc* files, because > Cog doesn't works on that arch anyways.. > so, i tried to use > sqMacIntel-Win32.c > > and failed.. then tried to use > > x86-sysv-MacIntel.c > > and it fails to compile with same error(s): > > /platforms/Mac OS/plugins/SqueakFFIPrims/x86-sysv-MacIntel.c:127: > error: ‘FFICallTypeCDecl’ undeclared (first use in this function) > /platforms/Mac OS/plugins/SqueakFFIPrims/x86-sysv-MacIntel.c:128: > error: ‘FFICallTypeApi’ undeclared (first use in this function) > > These constants are defined only in FFIConstants shared pool.. and > somehow they should be made available to > these .c files.. > But our beloved VMMaker's code generator don't generating headers > which can be included by other .c files, > and all class var constants are just printed inside a body of > generated .c file , like SqueakFFIPrims.c > which means that these constants should be defined externally manually > somewhere. > > So, it seems like FFI is broken for Mac+Cog. > > P.S. Eliot's default .xcodeproj for FFI plugin are not builds because > its not including one of the files above, which making a build > complete (otherwise you got undefined symbols). > > Please shed a light, if FFI for Mac + Cog were in working state at > some day? Or i doing something completely wrong? > > Of course i can disable it from build and forget about it, since we > have new stuff coming (of course if Santa decide that we were good > boys), > but still.. > > -- > Best regards, > Igor Stasenko AKA sig. |
Look at the xcode project and what files it includes The history is that there was source code both for the api and the assembler from Linux and windows. The linux code had flaws, the windows code didn't work. You have to follow Apple's ABI instructions to the letter, other operating systems are more forgiving. sqWin32FFI.c is used x86-sysv-asm.S is used but revised to work on macintel OS sqMacFFI.s is used as a universal ppc support sqMacFFIPPC.c is used I note the x86-sysv-MacIntel.c *should* work but there is a flaw *somewhere* that causes it to crash when used with Croquet. On 2010-12-27, at 10:16 AM, Esteban Lorenzano wrote: > > Hi Igor, > I discovered that a similar problem happens also in the I32ABI plugin sources, the file ppc32abicc.c (which, by name, shouldn't be present in my compilations) is in fact required and works (afaik) properly. > Perhaps the name is just a "legacy name"? Perhaps you have the same kind of problem? > > Cheers, > Esteban > > El 27/12/2010, a las 12:20p.m., Igor Stasenko escribió: > >> >> Hi, >> I am trying to figure out, how to build FFI plugin on macs for cog vm. >> >> the platforms/Mac\ OS/plugins/SqueakFFIPrims contains following files: >> >> >> Info-SqueakFFIPlugin__Upgraded_.plist >> SqueakFFI.xcodeproj.zip >> SqueakFFIPrims.proj.xml >> ppc-darwin-Carbon-UI.c >> ppc-darwin-asm-MacIntel.S >> ppc-global.h >> resources >> sqMacFFI.s >> sqMacFFIPPC.c >> sqMacIntel-Win32.c >> x86-sysv-MacIntel.c >> x86-sysv-asm-MacIntel.S >> >> >> something tells me that i don't need to compile ppc* files, because >> Cog doesn't works on that arch anyways.. >> so, i tried to use >> sqMacIntel-Win32.c >> >> and failed.. then tried to use >> >> x86-sysv-MacIntel.c >> >> and it fails to compile with same error(s): >> >> /platforms/Mac OS/plugins/SqueakFFIPrims/x86-sysv-MacIntel.c:127: >> error: ‘FFICallTypeCDecl’ undeclared (first use in this function) >> /platforms/Mac OS/plugins/SqueakFFIPrims/x86-sysv-MacIntel.c:128: >> error: ‘FFICallTypeApi’ undeclared (first use in this function) >> >> These constants are defined only in FFIConstants shared pool.. and >> somehow they should be made available to >> these .c files.. >> But our beloved VMMaker's code generator don't generating headers >> which can be included by other .c files, >> and all class var constants are just printed inside a body of >> generated .c file , like SqueakFFIPrims.c >> which means that these constants should be defined externally manually >> somewhere. >> >> So, it seems like FFI is broken for Mac+Cog. >> >> P.S. Eliot's default .xcodeproj for FFI plugin are not builds because >> its not including one of the files above, which making a build >> complete (otherwise you got undefined symbols). >> >> Please shed a light, if FFI for Mac + Cog were in working state at >> some day? Or i doing something completely wrong? >> >> Of course i can disable it from build and forget about it, since we >> have new stuff coming (of course if Santa decide that we were good >> boys), >> but still.. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
In reply to this post by Igor Stasenko
Hi Igor, that's all legacy. The Cog sources require only ReentrantFFIPlugin (at least on x86). As far as other processors I've written ReentrantFFIPlugin to allow straight-forward porting to other platforms. I can consult if anyone is motivated to try and port to PowerPC, ARM etc. The essential idea is to use C's alloca to allocate the space for the outgoing arguments on the stack and hence do all the marshalling in C. Passing register arguments is done by explicitly passing the register args, leavign the rest to be passed on teh stack throguh the alloca'ed space.
In short, all that assembler support code is obsolete. best Eliot On Mon, Dec 27, 2010 at 7:20 AM, Igor Stasenko <[hidden email]> wrote:
|
btw... quick question: ReentrantFFIPlugin will obsolete I32ABI? Cheers, Esteban
El 27/12/2010, a las 4:46p.m., Eliot Miranda escribió: Hi Igor, |
On Mon, Dec 27, 2010 at 11:49 AM, Esteban Lorenzano <[hidden email]> wrote:
Only the callout functionality, not the data access or callback functionality.
HTH Eliot
|
In reply to this post by Eliot Miranda-2
Eliot , then i recommend to change ReentrantFFIPlugin>>moduleName ^ 'ReentrantFFIPlugin' and Interpreter>>primitiveCalloutToFFI accordingly to prevent any future confusion and mixture with legacy code in Cog. If you want, i can upload the patch right away.. oh yeah.. this will require moving some cross-platform sources too.. mv platforms/Cross/plugins/SqueakFFIPrims platforms/Cross/plugins/ReentrantFFIPlugin On 27 December 2010 20:46, Eliot Miranda <[hidden email]> wrote: > > Hi Igor, > that's all legacy. The Cog sources require only ReentrantFFIPlugin (at least on x86). As far as other processors I've written ReentrantFFIPlugin to allow straight-forward porting to other platforms. I can consult if anyone is motivated to try and port to PowerPC, ARM etc. The essential idea is to use C's alloca to allocate the space for the outgoing arguments on the stack and hence do all the marshalling in C. Passing register arguments is done by explicitly passing the register args, leavign the rest to be passed on teh stack throguh the alloca'ed space. > In short, all that assembler support code is obsolete. > > best > Eliot > On Mon, Dec 27, 2010 at 7:20 AM, Igor Stasenko <[hidden email]> wrote: -- Best regards, Igor Stasenko AKA sig. |
Btw, to avoid possible confusion we should also do something with this: external plugin ReentrantARMFFIPlugin generated as SqueakFFIPrims external plugin ReentrantFFIPlugin generated as SqueakFFIPrims external plugin ReentrantIA32FFIPlugin generated as SqueakFFIPrims or not.. :) It is good that ReentrantIA32FFIPlugin generates own code last, so it overrides any previously generated files, and compiles ok, since i run only on IA32. -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Eliot Miranda-2
Well actually the assembler for PPC exists as I wrote it for Alien, but not the part that does the callbacks. Although people *might* think PPC is dead, the United States of America's school systems are firmly entrenched in dead technology. Something about funding... On 2010-12-27, at 11:46 AM, Eliot Miranda wrote: Hi Igor, -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Free forum by Nabble | Edit this page |