On Thu, 21 Jan 2016 08:07:06 +0800
Ben Coman <btc(a)openinworld.com> wrote:
> Intended usage is not a semaphore. Intended usage is a mutual
> exclusion primitive (i.e. a lock)
exclusiveAccess acquire
$0.02,
-KenD
I think you reintroduced the old comment that does not make sense any more
as the NewSpeak ABI plugin was merged into the Smalltalk one now that
immutability is in the main VM.
+ !IA32ABIPlugin commentStamp: '<historical>' prior: 0!
+ This plugin implements the Alien foreign-function interface, a small
elaboration on the Strongtalk FFI. This version of the plugin differs from
the NewsqueakIA32ABIPlugin in not supporting immutability.
- !IA32ABIPlugin commentStamp: 'eem 1/25/2016 11:59' prior: 0!
- This plugin implements the Alien foreign-function interface, a small
elaboration on the Strongtalk FFI.
==> not correct.
2016-01-28 17:44 GMT+01:00 <commits(a)source.squeak.org>:
>
> Esteban Lorenzano uploaded a new version of VMMaker to project VM Maker:
> http://source.squeak.org/VMMaker/VMMaker.oscog-EstebanLorenzano.1672.mcz
>
> ==================== Summary ====================
>
> Name: VMMaker.oscog-EstebanLorenzano.1672
> Author: EstebanLorenzano
> Time: 28 January 2016, 5:38:59.720208 pm
> UUID: 3ed1ee79-ae66-44d8-8366-67899098dfab
> Ancestors: VMMaker.oscog-eem.1671
>
> added an option for #primDrainOSEventQueue because it just have sense for
> NewspeakVM (and it makes Windows build fails if present).
>
> =============== Diff against VMMaker.oscog-eem.1671 ===============
>
> Item was changed:
> InterpreterPlugin subclass: #IA32ABIPlugin
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: 'VMBasicConstants'
> category: 'VMMaker-Plugins-Alien'!
>
> + !IA32ABIPlugin commentStamp: '<historical>' prior: 0!
> + This plugin implements the Alien foreign-function interface, a small
> elaboration on the Strongtalk FFI. This version of the plugin differs from
> the NewsqueakIA32ABIPlugin in not supporting immutability.
> - !IA32ABIPlugin commentStamp: 'eem 1/25/2016 11:59' prior: 0!
> - This plugin implements the Alien foreign-function interface, a small
> elaboration on the Strongtalk FFI.
>
> Call-outs are performed by a small number of primitives, one each for
> the four different kinds of return linkage on x86. The primitives are
> var-args. Each primitive has a signature something like:
> primFFICall: functionAddress <Alien> result: result <Alien> with:
> firstArg <Alien> ... with: lastArg <Alien>
> <primitive: 'primCallOutIntegralReturn' module: 'IA32ABI'>
> which arranges to call-out supplying the arguments to the function
> pointed to by functionAddress, copying its return value into result. The
> call-out primitives are as follows:
>
> primCallOutIntegralReturn call a function which returns up to 8 bytes in
> %eax & %edx, taking up to the first 4 bytes from %eax. i.e. if the
> sizeof(result) is 4 or less only bytes from %eax will be returned, but if
> more then the first 4 bytes of result will be assigned with %eax and
> subsequent bytes with %edx, up to a total of 8 bytes.
>
> primCallOutPointerReturn call a function which returns a pointer in
> %eax. Assign sizeof(result) bytes from this pointer into the result.
>
> primCallOutFloatReturn call a function which returns a 4 byte
> single-precision float in %f0, assigning the 4 bytes of %f0 into result.
>
> primCallOutDoubleReturn call a function which returns an 8 byte
> double-precision float in %f0, assigning the 8 bytes of %f0 into result.
>
> !
>
> Item was changed:
> ----- Method: IA32ABIPlugin>>primDrainOSEventQueue (in category
> 'primitives-Windows-VM-specific') -----
> primDrainOSEventQueue
> + <option: #NewspeakVM>
> <export: true>
> self ioDrainEventQueue!
>
>
Esteban Lorenzano uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-EstebanLorenzano.1673.mcz
==================== Summary ====================
Name: VMMaker.oscog-EstebanLorenzano.1673
Author: EstebanLorenzano
Time: 28 January 2016, 6:57:24.889696 pm
UUID: 2770aa15-cadd-42f6-924f-95034ccb7f82
Ancestors: VMMaker.oscog-EstebanLorenzano.1672
restoring correct IB32ABIPlugin class comment
=============== Diff against VMMaker.oscog-EstebanLorenzano.1672 ===============
Item was changed:
InterpreterPlugin subclass: #IA32ABIPlugin
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: 'VMBasicConstants'
category: 'VMMaker-Plugins-Alien'!
+ !IA32ABIPlugin commentStamp: 'EstebanLorenzano 1/28/2016 18:56' prior: 0!
+ This plugin implements the Alien foreign-function interface, a small elaboration on the Strongtalk FFI.
- !IA32ABIPlugin commentStamp: '<historical>' prior: 0!
- This plugin implements the Alien foreign-function interface, a small elaboration on the Strongtalk FFI. This version of the plugin differs from the NewsqueakIA32ABIPlugin in not supporting immutability.
Call-outs are performed by a small number of primitives, one each for the four different kinds of return linkage on x86. The primitives are var-args. Each primitive has a signature something like:
primFFICall: functionAddress <Alien> result: result <Alien> with: firstArg <Alien> ... with: lastArg <Alien>
<primitive: 'primCallOutIntegralReturn' module: 'IA32ABI'>
which arranges to call-out supplying the arguments to the function pointed to by functionAddress, copying its return value into result. The call-out primitives are as follows:
primCallOutIntegralReturn call a function which returns up to 8 bytes in %eax & %edx, taking up to the first 4 bytes from %eax. i.e. if the sizeof(result) is 4 or less only bytes from %eax will be returned, but if more then the first 4 bytes of result will be assigned with %eax and subsequent bytes with %edx, up to a total of 8 bytes.
primCallOutPointerReturn call a function which returns a pointer in %eax. Assign sizeof(result) bytes from this pointer into the result.
primCallOutFloatReturn call a function which returns a 4 byte single-precision float in %f0, assigning the 4 bytes of %f0 into result.
primCallOutDoubleReturn call a function which returns an 8 byte double-precision float in %f0, assigning the 8 bytes of %f0 into result.
!
Esteban Lorenzano uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-EstebanLorenzano.1672.mcz
==================== Summary ====================
Name: VMMaker.oscog-EstebanLorenzano.1672
Author: EstebanLorenzano
Time: 28 January 2016, 5:38:59.720208 pm
UUID: 3ed1ee79-ae66-44d8-8366-67899098dfab
Ancestors: VMMaker.oscog-eem.1671
added an option for #primDrainOSEventQueue because it just have sense for NewspeakVM (and it makes Windows build fails if present).
=============== Diff against VMMaker.oscog-eem.1671 ===============
Item was changed:
InterpreterPlugin subclass: #IA32ABIPlugin
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: 'VMBasicConstants'
category: 'VMMaker-Plugins-Alien'!
+ !IA32ABIPlugin commentStamp: '<historical>' prior: 0!
+ This plugin implements the Alien foreign-function interface, a small elaboration on the Strongtalk FFI. This version of the plugin differs from the NewsqueakIA32ABIPlugin in not supporting immutability.
- !IA32ABIPlugin commentStamp: 'eem 1/25/2016 11:59' prior: 0!
- This plugin implements the Alien foreign-function interface, a small elaboration on the Strongtalk FFI.
Call-outs are performed by a small number of primitives, one each for the four different kinds of return linkage on x86. The primitives are var-args. Each primitive has a signature something like:
primFFICall: functionAddress <Alien> result: result <Alien> with: firstArg <Alien> ... with: lastArg <Alien>
<primitive: 'primCallOutIntegralReturn' module: 'IA32ABI'>
which arranges to call-out supplying the arguments to the function pointed to by functionAddress, copying its return value into result. The call-out primitives are as follows:
primCallOutIntegralReturn call a function which returns up to 8 bytes in %eax & %edx, taking up to the first 4 bytes from %eax. i.e. if the sizeof(result) is 4 or less only bytes from %eax will be returned, but if more then the first 4 bytes of result will be assigned with %eax and subsequent bytes with %edx, up to a total of 8 bytes.
primCallOutPointerReturn call a function which returns a pointer in %eax. Assign sizeof(result) bytes from this pointer into the result.
primCallOutFloatReturn call a function which returns a 4 byte single-precision float in %f0, assigning the 4 bytes of %f0 into result.
primCallOutDoubleReturn call a function which returns an 8 byte double-precision float in %f0, assigning the 8 bytes of %f0 into result.
!
Item was changed:
----- Method: IA32ABIPlugin>>primDrainOSEventQueue (in category 'primitives-Windows-VM-specific') -----
primDrainOSEventQueue
+ <option: #NewspeakVM>
<export: true>
self ioDrainEventQueue!
Hi guys,
OK, I have a first working version and so I wanted to share it with you.
I have not yet the time to start writing the doc since I just finished the
first pass on the code. Tomorrow I will start with the doc. But I thought
some of you may be interested in taking a look even without formal "doc"
(and some feedback/iteration may avoid re-writing docs..).
If you have no clue what I am talking about, then this summary is for you:
*----------*
*When we use FFI to call a certain library it's quite common that we need
to pass as argument certain constants (for example, SIGKILL to kill()).
These constants are defined in C header files and can even change it's
value in different paltforms. *
*These constants also are sometimes defined by the C preprocessor and so
there is not way to get those values from FFI. If you don't have the value
of those constants, you cannot make the FFI call. *
*----------*
I have tested the tool in OSX and CentOS using latest Pharo 5.0. It won't
work in Windows right now. As usual, all classes and methods have comments
and there are enough tests.
At the end, I decided the C program will output a very naive Smalltalk
literal array kind of thingy. The tool then parses that output and directly
creates a init method (which is compiled into the SharedPool class) for
that platform which is then called automatically at startup (only if
initialization is needed).
As for real examples, I started to write constants for libc: signal.h (to
use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... xxx()) ,
and errno.h. You can take a look to the package 'FFICHeaderExtractor-LibC'.
Note that for running the tests you need 'cc' findable by path in OSX and
'gcc' in Unix.
To load the code in a latest Pharo 5.0, execute:
Metacello new
baseline: 'FFICHeaderExtractor';
repository:
'github://marianopeck/FFICHeaderExtractor:master/repository';
load.
Any feedback is appreciated.
I will start writing the doc now.
BTW: Big thanks to Eliot Miranda which helped me answering noob questions
and providing useful code and guidelines.
Best,
On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com>
wrote:
>
> Hi Denis,
>
> On Jan 23, 2016, at 7:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com>
> wrote:
>
>
> 2016-01-22 22:35 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>:
>
>> Let's measure this. Let's say we have 8 platforms (that's an
>> underestimate, because different Linux distributions may have different
>> values for certain constants), but 8, which is 4 basic platforms times 32-
>> & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86
>> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64
>> 64-bit, and soon enough there will be more. Further, there may be
>> different versions over time.
>>
>> So each of those initialization methods has
>> - 1 slot for the global variable to be assigned
>> - 1 slot for the literal value to assign to it
>> - 3 bytes of bytecode per initialization for small methods, 4 for large
>> methods. Let's say 4.
>>
>> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20
>> bytes. So the overhead per constant for all platforms is 96 bytes per
>> constant in 32-bits and 160 bytes per constant for 64-bits. A full system
>> with sockets, files, a database connexion etc could easily exceed 100
>> constants. I think it would be nearer 1000. So the overheads are in the
>> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low
>> but it's also pure overhead. Every GC has to visit them. Every senders
>> and implementors has to visit them, but they offer nothing of value.
>> Whereas the small parser for whatever notation is used to store the
>> constants externally (if they are needed in a given deployment) has a small
>> constant overhead; its simple code.
>>
>> Further, you still need the machinery to export the constants to be able
>> to generate these initialization methods. If you've got the machinery and
>> you don't need the methods why bother to generate the methods?
>>
>> As the Scots say, many a mickle makes a muckle.
>
>
> Thank's Eliot for such detailed explanation. It makes sense.
> But personally I prefer Smalltalk solution although Smalltalk itself is
> pure overhead comparing to C.
>
>
> I can see the draw of the pure Smalltalk. Simplicity and brows ability.
> But imagine a tiny headless image deployed on containers, say 2mb. Now
> 100kb of initialization code doesn't look so good :-). Anyway I'm beating
> a dead horse. Mariano is generating initialization methods.
>
>
> My question was raised by Mariano idea to save ston files in methods. I
> think it can reduce problems which you described.
> But then literal array syntax can be more suitable than ston.
>
>
> I just want to be clear, I'm neutral about the notation used to export
> info from the C file. Liberal array syntax, chunk source format, ston,
> xml. It doesn't matter as long as it's convenient at expressing an
> attribute dictionary from names to attributes such as value, size, offset.
> Don't get hung up on the specific notation. If one were to go with the
> external file the only real requirements are that it be reasonably compact
> and quick to parse. That might kill xml but leave plenty of other
> candidates.
>
>
> _,,,^..^,,,_ (phone)
>
>
--
Mariano
http://marianopeck.wordpress.com
On Sun, Jan 24, 2016 at 5:10 AM, <vm-dev-request(a)lists.squeakfoundation.org>
wrote:
> Send Vm-dev mailing list submissions to
> vm-dev(a)lists.squeakfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
> or, via email, send a message with subject or body 'help' to
> vm-dev-request(a)lists.squeakfoundation.org
>
> You can reach the person managing the list at
> vm-dev-owner(a)lists.squeakfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Vm-dev digest..."
>
>
> Today's Topics:
>
> 1. Merging FFI and Alien (Esteban Lorenzano)
> 2. Re: Merging FFI and Alien (Luc Fabresse)
> 3. Re: Merging FFI and Alien (Esteban Lorenzano)
> 4. Re: Merging FFI and Alien (Luc Fabresse)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 24 Jan 2016 12:57:36 +0100
> From: Esteban Lorenzano <estebanlm(a)gmail.com>
> Subject: [Vm-dev] Merging FFI and Alien
> To: Squeak Virtual Machine Development Discussion
> <vm-dev(a)lists.squeakfoundation.org>
> Message-ID: <52303C25-8296-4871-A81B-A770C72428CC(a)gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> Recently I’ve been talking with Eliot and we came to the conclusion that
> FFI and Alien repositories needs to be merged.
> Our rational is that 1) both are different ways of doing the same (often
> with same primitives) and much more important 2) Alien contains the the “de
> facto” callback mechanism supported by the VM.
> Keeping them separated and treated as two different things is negative and
> an important source of confusion for people willing to do FFI this days.
> So, here is my proposal (already talked with Eliot).
>
> 1) unify http://source.squeak.org/FFI and
> http://www.squeaksource.com/Alien into http://source.squeak.org/FFI
> That means copying into FFI repo all Alien history.
>
> 2) Rename Alien package into FFI-Alien (extract the Alien-Win32 category
> into its own package)
>
> 3) Create a ConfigurationOfFFI who takes properly FFI and FFI-Alien, etc.
>
> That means also deprecate Alien project in squeaksource (which usually is
> just put a WARNING text in home page :P)
>
> So… if nobody has a anything against this plan, I will do it next week :)
>
> cheers!
> Esteban
>
> ------------------------------
>
> Message: 2
> Date: Sun, 24 Jan 2016 13:38:55 +0100
> From: Luc Fabresse <luc.fabresse(a)gmail.com>
> Subject: Re: [Vm-dev] Merging FFI and Alien
> To: Squeak Virtual Machine Development Discussion
> <vm-dev(a)lists.squeakfoundation.org>
> Message-ID:
> <CAAR4Pr6djsskF5jr77Ntgf=UM0CjGv8v7t+hwvYik=
> eXuUMQZQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Esteban,
>
> Question: why not "just" introducing Alien's callbacks in FFI and rename it
> (e.g. FFI-callbacks)?
>
> That would be simpler, no?
> - no Alien's history in FFI repo
> - not the full Alien's code (callout mechanism, ...) in FFI codebase
> - ...
>
> Cheers,
>
> #Luc
>
> 2016-01-24 12:57 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>:
>
> >
> > Hi,
> >
> > Recently I’ve been talking with Eliot and we came to the conclusion that
> > FFI and Alien repositories needs to be merged.
> > Our rational is that 1) both are different ways of doing the same (often
> > with same primitives) and much more important 2) Alien contains the the
> “de
> > facto” callback mechanism supported by the VM.
> > Keeping them separated and treated as two different things is negative
> and
> > an important source of confusion for people willing to do FFI this days.
> > So, here is my proposal (already talked with Eliot).
> >
> > 1) unify http://source.squeak.org/FFI and
> > http://www.squeaksource.com/Alien into http://source.squeak.org/FFI
> > That means copying into FFI repo all Alien history.
> >
> > 2) Rename Alien package into FFI-Alien (extract the Alien-Win32 category
> > into its own package)
> >
> > 3) Create a ConfigurationOfFFI who takes properly FFI and FFI-Alien, etc.
> >
> > That means also deprecate Alien project in squeaksource (which usually is
> > just put a WARNING text in home page :P)
> >
> > So… if nobody has a anything against this plan, I will do it next week :)
> >
> > cheers!
> > Esteban
>