[squeak-dev] help needed with the new FFI plugin...
richi.moran at gmail.com
Fri Jul 22 16:08:54 UTC 2011
Yes, indeed. Right now, for most use cases we use the SerialPort class, but
we still have some FFI code for other stuff hanging around. I plan to write
it as a plugin as soon as I have the time.
On Fri, Jul 22, 2011 at 10:37 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
> It's not part of Etoys yet. If its low-level interface indeed requires FFI,
> then that interface would have to be rewritten as plugin for Etoys to
> include it.
> - Bert -
> On 22.07.2011, at 14:55, karl ramberg wrote:
> What about the Physical Etoys project ?
> On Fri, Jul 22, 2011 at 2:20 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>> On 22.07.2011, at 02:10, Eliot Miranda wrote:
>> > On Thu, Jul 21, 2011 at 4:57 PM, Igor Stasenko <siguctua at gmail.com>
>> > On 22 July 2011 02:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> > > Hi All,
>> > > today I committed the threaded FFI plugin along with the threaded
>> VM and
>> > > hope to be able to support people in doing threaded FFI work on the
>> > > platforms really soon now (Esteban, amongst others, this means you ;)
>> > > But to put the image-level code that uses the new FFI plugin into
>> > > production the standard VM needs to be upgraded to not crash with the
>> > > ExternalFunction image changes the new threaded FFI plugin wants. The
>> > > change is that ExternalFunction changes size, gaining a stackSize inst
>> > > which is used to tell the FFI plugin how much stack spacer to reserve
>> > > marshalling (its computed on first use). The best way for this to
>> happen is
>> > > to start using the ThreadedFFIPlugin as the standard plugin in the
>> > > Interpreter VM. The ThreadedFFIPlugin overall is simpler than the old
>> > > plugin (no assembler support code) and better (fully reentrant). But
>> > > this to happen we may need to implement the platform=specific parts of
>> > > the ThreadedFFIPlugin (still entirely Smalltalk code) for PowerPC and
>> > > (and perhaps others, SPARC??). I understand what has to be done and I
>> > > explain it to anyone interested in working on the problem, but I don't
>> > > any hardware with which I can test the results so its pretty pointless
>> > > doing the work and producing something inevitably broken. So are
>> > > people out there who would be interested in doing the port to PPC and
>> > > It means fleshing out the classes
>> > > ThreadedARMFFIPlugin ThreadedFFICalloutStateForARM
>> > > ThreadedPPCBEFFIPlugin ThreadedFFICalloutStateForPPC
>> > > and having a solid understanding of how alloca works to do stack
>> > > and how the ABIs on ARM and PPC pass registers.
>> > > here's hoping there are a few good low-level people who would be
>> > > Let me know.
>> > I wonder if you find anyone today using these archs, not saying using
>> > squeak/pharo on them + knowing low-level details + wanting to help :)
>> > Right, chances are thin. But then if no one is interested then the work
>> doesn't need to be done. Bert, you mentioned the other day that PPC was
>> still relevant for etoys. But am I right in thinking etoys never uses the
>> Right. Etoys should run on both ARM and PPC, but it does not use FFI.
>> - Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev