December 2015 - Pharo-dev - lists.pharo.org

[ANN] Pharo Consortium Sponsored Development Effort
by Mariano Martinez Peck Dec. 23, 2015

Dec. 23, 2015

Dear all, I am tremendously happy to announce you that Pharo Consortium will sponsor yet another development effort. In this particular case, it's my honor to carry on such an effort and I will be developing and improving a few things and ideas. All the contract and paperwork has already been done so it's time to start working. Regarding the developments itself, we discussed about these topics: 1) Experiment with a simpler yet more limited OSProcess alternative to execute OS commands. 2) Improving FileSystem in order to better deal with some POSIX stuff like symbolic links, unix file permissions, etc etc. I have already started with 1). OSProcess is super complete and it involves some packages (OSProcess / CommandShell) as well as some VM plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features (like forking the running image) but we would like to focus only in executing OS commands. In addition, OSProcess dates from quite some years ago when many of the current infrastructure features did not exist yet. So the idea is to think a simpler alternative to execute OS commands, using new features such as threaded FFI (for example, for reading async from pipes), pinned objects, etc. We want to use FFI as much as possible rather than VM plugins. >From the image side, we are thinking about an API which would look like a builder-like API (FileSystem, XStream, etc). We have been discussing with David Lewis (OSProcess author) as well as with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc in order to agree in a project that would be worth doing (otherwise we would continue using existing tools). And they have all been very kind with me providing positive discussions. I will soon do a survey to measure the most common use cases of OSProcess and related tools. If you have any thought, question, feedback, or whatever, please let us know. Finally, note that I will be doing this project together with another client's project (Quuve) and my life does not have much free time these days...so please be patient!!! Best, -- Mariano http://marianopeck.wordpress.com

13 36

[SecureSession] version 74 is out with compression enabled
by Robert Withers Dec. 23, 2015

Dec. 23, 2015

Check it in the crypto repo. Next up? refactor over to new frames. On deck? ReedSolomon -- . .. ... ^,^ robert Go Panthers!

1 0

[pharo-project/pharo-core]
by GitHub Dec. 22, 2015

Dec. 22, 2015

Branch: refs/tags/50509 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 317ca8: 50509
by GitHub Dec. 22, 2015

Dec. 22, 2015

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 317ca8b4c21dff0d48cdd2f16fdec4bbf9ea76cc https://github.com/pharo-project/pharo-core/commit/317ca8b4c21dff0d48cdd2f1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-22 (Tue, 22 Dec 2015) Changed paths: M Monticello.package/MCVersionLoader.class/instance/loading/loadWithNameLike_.st A Monticello.package/MCVersionLoader.class/instance/private/announceLoadStart_.st A Monticello.package/MCVersionLoader.class/instance/private/announceLoadStop_.st A Monticello.package/MCVersionLoader.class/instance/private/announceLoad_do_.st A Monticello.package/MCVersionLoader.class/instance/private/basicLoadWithNameLike_.st A Monticello.package/MCVersionLoaderStarted.class/README.md A Monticello.package/MCVersionLoaderStarted.class/definition.st A Monticello.package/MCVersionLoaderStarted.class/instance/accessing/label.st A Monticello.package/MCVersionLoaderStarted.class/instance/accessing/label_.st A Monticello.package/MCVersionLoaderStarted.class/instance/accessing/versionLoader.st A Monticello.package/MCVersionLoaderStarted.class/instance/accessing/versionLoader_.st A Monticello.package/MCVersionLoaderStopped.class/README.md A Monticello.package/MCVersionLoaderStopped.class/definition.st A Monticello.package/MCVersionLoaderStopped.class/instance/accessing/label.st A Monticello.package/MCVersionLoaderStopped.class/instance/accessing/label_.st A Monticello.package/MCVersionLoaderStopped.class/instance/accessing/versionLoader.st A Monticello.package/MCVersionLoaderStopped.class/instance/accessing/versionLoader_.st M Morphic-Widgets-Basic.package/SimpleButtonMorph.class/instance/accessing/label.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50508.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50509.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50508.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50509.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/accessing/acceptAllowed.st Log Message: ----------- 50509 17287 SimpleButtonMorph>>#label is really bad for nothingâ¦ https://pharo.fogbugz.com/f/cases/17287 17186 Monticello Load-Announcements https://pharo.fogbugz.com/f/cases/17186 16887 Debugger context menu broken https://pharo.fogbugz.com/f/cases/16887 http://files.pharo.org/image/50/50509.zip

1 0

[OT] SpaceX's Falcon 9 - There and back again
by Sven Van Caekenberghe Dec. 22, 2015

Dec. 22, 2015

This is a really great achievement: SpaceX successfully launched a rocket and deployed 11 satellites after failing earlier this year. But best of all, they landed the first stage back on earth! Consider the actual physics involved, mind boggling. http://www.wired.com/2015/12/spacex-just-landed-rocket-ground-first-time/ http://arstechnica.com/science/2015/12/by-making-a-historic-landing-spacex-… Sven

3 3

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)
by Richard Uttner Dec. 22, 2015

Dec. 22, 2015

2015-12-21 23:48 GMT+01:00 Richard Uttner <richard.uttner(a)gmail.com>: > This is my first contribution to the DevList and I hope you forgive me > that it sounds more like "I see something we dont need" than the other way > round, but there will be more positive posts of mine concering the Unicode > debate (which I will postpone to the New Year in order to be able to > respond quickly). > From a developer's point of view that is dealing with more than one > environment (3 Smalltalk environments including Pharo, where I am a newby) > and a handful of other languages, I dont like to reuse interfaces that are > hard to remember and understand though the task done by them is so easy > that I can write it down in one simple #inject:into-line 10 times faster > than looking it up in the implementors browser. Furthermore, something like > #inject:into: will work forever and never be deprecated! Fullstop. > Next thing that is easily overlooked is the semantics. I am not that good > in mathematics, but I would suppose that summing up does by definition not > need a neutral element - only an implementation that can be written down in > 2 lines needs it. A mathematically correct implementation of summing up > anything (including nil ... see reason below) that implements #+ would be: > > Collection:>>#sum > | undef result | > undef := result := Object new. > self do: [:each | result := result == undef ifTrue: [each] ifFalse: > [result + each]]. > "(Sorry for the incomplete mail .... Gmail in Browser apparently has a keyboard shortcut for sending the mail if caret key is pressed along with spaces ...weird ... :() Continuing with missing return statement for above:" ^result (Why I am using "Object new" instead of nil: I would not recommend implementing #+ in nil, but not prohibit it in a general interface, if somebody needs it in an own extension. Thus relying on nil would spoil this theoretical possibility unnecessarily.) The reasons for writing it down like above are: - no sideeffects with possibile overflows (think of a collection containing one element near maxval that is added twice like in the other proposed solutions, and then subtracted finally) - no need to implement #- in special classes that are no numbers but want to use #sum - no need for a neutral element Main disadvantage of my proposed implementation is the fact that we hardly can distinguish a valid result from an invalid one if we dont use nil. What I think is the main reason for all argueing around this interface is simply: Though it sounds reasonable to define something like #sum for Collection at first sight, in fact its semantics is too blurry - we need to pass the desired result in order to reasonably handle empty collections. For most practicable application cases, this can be done instead by simply injecting 0. So please avoid so many new methods that developers have to study in order to understand their respective limit conditions (and primitives are even worse - how will coercing be done if the result gets large? Will it fail on Fraction elements? ...?) So my personal summary is: No implementation of #sum - variants in Collection due to vague semantics and no real advantage against directly using #inject:into. Best regards, Richard > > 2015-12-21 18:00 GMT+01:00 <pharo-dev-request(a)lists.pharo.org>: > >> Send Pharo-dev mailing list submissions to >> pharo-dev(a)lists.pharo.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org >> or, via email, send a message with subject or body 'help' to >> pharo-dev-request(a)lists.pharo.org >> >> You can reach the person managing the list at >> pharo-dev-owner(a)lists.pharo.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Pharo-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Dimitris Chloupis) >> 2. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) >> 3. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Mariano Martinez Peck) >> 4. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) >> 5. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Dimitris Chloupis) >> 6. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Thierry Goubier) >> 7. Re: #sum:, #detectSum:, #sumNumbers: (Tudor Girba) >> 8. [pharo-project/pharo-core] (GitHub) >> 9. [pharo-project/pharo-core] e8216b: 50508 (GitHub) >> 10. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Denis Kudriashov) >> 11. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Ben Coman) >> 12. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e >> acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) >> 13. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Thierry Goubier) >> 14. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e >> acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) >> 15. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Robert Withers) >> 16. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (phil(a)highoctane.be) >> 17. Re: [ANN] Multiple Desktop support for Pharo 5 (H. Hirzel) >> 18. No refactoring for equal/hash generation (Denis Kudriashov) >> 19. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Denis Kudriashov) >> 20. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Mariano Martinez Peck) >> 21. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored >> Development Effort (Robert Withers) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 20 Dec 2015 17:17:42 +0000 >> From: Dimitris Chloupis <kilon.alios(a)gmail.com> >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium >> Sponsored Development Effort >> Message-ID: >> <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj= >> uBE4UAM4tAVZcrA(a)mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> how the communication is happening via Fuel , does it save to a fuel file >> or it does it through memory some way ? >> >> On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis(a)mail.msen.com> >> wrote: >> >> > On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: >> > > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: >> > > > Fuel I assume enters here the equation as a data exchange format , >> the >> > > > problem I have with fuel is that its not backward compatible which >> for >> > me >> > > >> > >> > Fuel works well in this case. Version compatibility is not an issue, >> > because >> > when you fork an image/VM the two cooperating images are essentially >> > identical. >> > >> > > Once you have a set of OS processes running Pharo how they talk to >> each >> > other >> > > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, >> > JSONRPC, >> > > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. >> > >> > Any of those would work, but Fuel is a good way to enable all kinds of >> > objects to be copied from one image to another through a stream. In the >> > case of RemoteTask, all of the results of a remote computation can be >> put >> > into a single result object (an array or a dictionary or whatever), and >> > that result can be passed back to the parent image by reading the single >> > object. So - fork a copy of the image, have it do some work, and read >> the >> > result object from a stream. You know you are done when you have read >> > exactly one object. >> > >> > Dave >> > >> > >>

2 1

SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)
by Robert Withers Dec. 22, 2015

Dec. 22, 2015

I updated with all the feedback and here is a version 1.0 pdf specification. I appreciate any comments or suggestions you may have for this. https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 Thank you, Robert On 12/20/2015 10:51 AM, Robert Withers wrote: > More, sorry. I left out the msgSize in the FEC spec. Let me reorder > the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly... > > > ---Default non-FEC msgSpec + header + payload layout: > > - 8bytes (X) messageSpecification... > - > - (32bits...) > - 4bits tagging > - 6bits multicastSymbol > - 6bits messageVersion > - 2bits sanguinity > - 6bits headerType "Implies Y header size. NOTE: except for FEC > encodings" > - 8bits unused > - (32bits...) > - 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - > 8bytes msgSpec (X = 8)) > - > - Ybytes message header > https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 > - > - Zbytes message payload > > > > Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit > alignment: > > - 8bytes (X) message specification... > - > - (32bits...) > - 4bits tagging > - 6bits multicastSymbol > - 6bits messageVersion > - 2bits sanguinity > - 6bits FEC message type "NOTE: this means different layout" > - 2bits rsMode > - 6bits partial blockCount > - (32bits...) > - 4bits blockCount "NOTE: for 1MB encoded/982KB data - > blockCount * blockCodeBytes = Z" > - 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - > 8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data" > - 8bits primitivePolynomial spec (good for our current rsModes) > - > - Y = 0 > - > - Zbytes-sized payload > > Ok, that's what it is I think, this proposal. > > robert > > > > On 12/20/2015 10:33 AM, Robert Withers wrote: >> ---Default non-FEC msgSpec + header + payload layout: >> >> - 6bits multicastSymbol >> - 2bits sanguinity >> - 6bits messageVersion >> - 6bits headerType "NOTE: except for FEC encodings" >> - 4bytes messageSize >> - Xbytes header >> - >> - (messageSized - headerSize - 7specBytes) Bytes-sized payload >> >> >> Special FEC coded 64bit <msgSpec + header> + payload layout, for >> 64bit alignment: >> >> - (32bits...) >> - 6bits multicastSymbol >> - 2bits sanguinity >> - 6bits messageVersion >> - 6bits FEC message type "NOTE: this means different layout" >> - 2bits rsMode >> - (32bits...) >> - 10bits blockCount "NOTE: for 1MB encoded/982KB data" >> - 20bits messageSize "NOTE: this can specify 1MB data plus >> - 8bits primitivePolynomial spec (good for our current rsModes) >> - 4bits tagging >> - >> - (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's >> blockCodeBytes) Bytes-sized payload > -- . .. ... ^,^ robert Go Panthers!

1 1

Ephemerons
by Esteban A. Maringolo Dec. 21, 2015

Dec. 21, 2015

Hi All, Elliot ;-) Do we have Ephemerons in Pharo? Will we have them? I'm migrating from VW some code that uses it, and if we're not going to have them I'd like to delete the code or package it separately and hopefully it will work if Ephemerons are added later to Pharo. Regards! Esteban A. Maringolo

2 3

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)
by Richard Uttner Dec. 21, 2015

Dec. 21, 2015

This is my first contribution to the DevList and I hope you forgive me that it sounds more like "I see something we dont need" than the other way round, but there will be more positive posts of mine concering the Unicode debate (which I will postpone to the New Year in order to be able to respond quickly). >From a developer's point of view that is dealing with more than one environment (3 Smalltalk environments including Pharo, where I am a newby) and a handful of other languages, I dont like to reuse interfaces that are hard to remember and understand though the task done by them is so easy that I can write it down in one simple #inject:into-line 10 times faster than looking it up in the implementors browser. Furthermore, something like #inject:into: will work forever and never be deprecated! Fullstop. Next thing that is easily overlooked is the semantics. I am not that good in mathematics, but I would suppose that summing up does by definition not need a neutral element - only an implementation that can be written down in 2 lines needs it. A mathematically correct implementation of summing up anything (including nil ... see reason below) that implements #+ would be: Collection:>>#sum | undef result | undef := result := Object new. self do: [:each | result := result == undef ifTrue: [each] ifFalse: [result + each]]. 2015-12-21 18:00 GMT+01:00 <pharo-dev-request(a)lists.pharo.org>: > Send Pharo-dev mailing list submissions to > pharo-dev(a)lists.pharo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org > or, via email, send a message with subject or body 'help' to > pharo-dev-request(a)lists.pharo.org > > You can reach the person managing the list at > pharo-dev-owner(a)lists.pharo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-dev digest..." > > > Today's Topics: > > 1. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Dimitris Chloupis) > 2. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) > 3. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Mariano Martinez Peck) > 4. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) > 5. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Dimitris Chloupis) > 6. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Thierry Goubier) > 7. Re: #sum:, #detectSum:, #sumNumbers: (Tudor Girba) > 8. [pharo-project/pharo-core] (GitHub) > 9. [pharo-project/pharo-core] e8216b: 50508 (GitHub) > 10. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Denis Kudriashov) > 11. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Ben Coman) > 12. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e > acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) > 13. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Thierry Goubier) > 14. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e > acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) > 15. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Robert Withers) > 16. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (phil(a)highoctane.be) > 17. Re: [ANN] Multiple Desktop support for Pharo 5 (H. Hirzel) > 18. No refactoring for equal/hash generation (Denis Kudriashov) > 19. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Denis Kudriashov) > 20. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Mariano Martinez Peck) > 21. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Robert Withers) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Dec 2015 17:17:42 +0000 > From: Dimitris Chloupis <kilon.alios(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium > Sponsored Development Effort > Message-ID: > <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj= > uBE4UAM4tAVZcrA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > how the communication is happening via Fuel , does it save to a fuel file > or it does it through memory some way ? > > On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis(a)mail.msen.com> > wrote: > > > On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: > > > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: > > > > Fuel I assume enters here the equation as a data exchange format , > the > > > > problem I have with fuel is that its not backward compatible which > for > > me > > > > > > > Fuel works well in this case. Version compatibility is not an issue, > > because > > when you fork an image/VM the two cooperating images are essentially > > identical. > > > > > Once you have a set of OS processes running Pharo how they talk to each > > other > > > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, > > JSONRPC, > > > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. > > > > Any of those would work, but Fuel is a good way to enable all kinds of > > objects to be copied from one image to another through a stream. In the > > case of RemoteTask, all of the results of a remote computation can be put > > into a single result object (an array or a dictionary or whatever), and > > that result can be passed back to the parent image by reading the single > > object. So - fork a copy of the image, have it do some work, and read the > > result object from a stream. You know you are done when you have read > > exactly one object. > > > > Dave > > > > >

2 1

Re: [Pharo-dev] [Vm-dev] VM Maker: VMMaker.oscog-eem.1609.mcz
by Eliot Miranda Dec. 21, 2015

Dec. 21, 2015

Hi All, the real Cog 64-bit Spur x64 VM just evaluated 3+4 correctly on Mac OS X: â Early days yet. This is a debug VM. The optimised VM does not yet display the prompt. But we can be confident that a 64-bit JIT for Spur will be available some time in January. â On Thu, Dec 17, 2015 at 10:42 AM, <commits(a)source.squeak.org> wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1609.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.1609 > Author: eem > Time: 17 December 2015, 10:41:49.192 am > UUID: 771cdc25-5d27-4818-8943-2ba5c0e31791 > Ancestors: VMMaker.oscog-eem.1608 > > Cogit: Fix the (arguably bogus) register save/restore code for safe > trampolines, including the ceScheduleScavenge call. > > =============== Diff against VMMaker.oscog-eem.1608 =============== > > Item was added: > + ----- Method: CogARMCompiler>>genSaveRegForCCall (in category 'abi') > ----- > + genSaveRegForCCall > + "Save the general purpose registers for a call into the C run-time > from a trampoline." > + "Save none, because the ARM ABI only defines callee saved > registers, no caller-saved regs." > + "cogit gen: STMFD operand: 16r7F"! > > Item was removed: > - ----- Method: CogARMCompiler>>genSaveRegisters (in category 'abi') ----- > - genSaveRegisters > - "Save the general purpose registers for a trampoline call." > - "Save none, because the ARM ABI only defines callee saved > registers, no caller-saved regs." > - "cogit gen: STMFD operand: 16r7F"! > > Item was added: > + ----- Method: CogARMCompiler>>genSaveRegsForCCall (in category 'abi') > ----- > + genSaveRegsForCCall > + "Save the general purpose registers for a trampoline call." > + "Save none, because the ARM ABI only defines callee saved > registers, no caller-saved regs." > + "cogit gen: STMFD operand: 16r7F" > + self flag: 'this will change with Sista when we hope to be able to > allocate arbitrary registers'! > > Item was removed: > - ----- Method: CogAbstractInstruction>>genSaveRegisters (in category > 'abi') ----- > - genSaveRegisters > - "Save the general purpose registers for a trampoline call." > - self subclassResponsibility! > > Item was changed: > ----- Method: CogIA32Compiler>>genRestoreRegsExcept: (in category 'abi') > ----- > genRestoreRegsExcept: abstractReg > | realReg | > realReg := self concreteRegister: abstractReg. > self assert: (EDI > EAX and: [EDI - EAX + 1 = 6]). > EAX to: EDI do: > [:reg| > + (reg between: ESP and: EBP) ifFalse: > + [realReg = reg > + ifTrue: [cogit AddCq: 4 R: ESP] > + ifFalse: [cogit PopR: reg]]]. > - realReg = reg ifTrue: [cogit AddCq: 4 R: ESP] ifFalse: > [cogit PopR: reg]]. > ^0! > > Item was removed: > - ----- Method: CogIA32Compiler>>genSaveRegisters (in category 'abi') ----- > - genSaveRegisters > - "Save the general purpose registers for a trampoline call." > - > - self assert: (EDI > EAX and: [EDI - EAX + 1 = 8]). > - EDI to: EAX by: -1 do: > - [:reg| > - (reg between: ESP and: EBP) ifFalse: > - [cogit PushR: reg]]. > - ^0! > > Item was added: > + ----- Method: CogIA32Compiler>>genSaveRegsForCCall (in category 'abi') > ----- > + genSaveRegsForCCall > + "Save the general purpose registers for a call into the C run-time > from a trampoline." > + > + self assert: (EDI > EAX and: [EDI - EAX + 1 = 8]). > + EDI to: EAX by: -1 do: > + [:reg| > + (reg between: ESP and: EBP) ifFalse: > + [cogit PushR: reg]]. > + ^0! > > Item was removed: > - ----- Method: CogMIPSELCompiler>>genSaveRegisters (in category 'abi') > ----- > - genSaveRegisters > - "This method is poorly named. Is this for a Smalltalk -> C call or > C -> Smalltalk call? > - If the former we don't need to do anything because all of the > abstract registers are > - allocated to C preserved registers." > - self flag: #bogus.! > > Item was added: > + ----- Method: CogMIPSELCompiler>>genSaveRegsForCCall (in category 'abi') > ----- > + genSaveRegsForCCall > + "Save the general purpose registers for a call into the C run-time > from a trampoline. > + We don't need to do anything because all of the abstract > registers are > + allocated to C preserved registers." > + self flag: 'this will change with Sista when we hope to be able to > allocate arbitrary registers'! > > Item was changed: > ----- Method: CogX64Compiler>>genRestoreRegs (in category 'abi') ----- > genRestoreRegs > "Restore the general purpose registers for a trampoline call. > c.f. genSaveRegisters" > + RAX to: R15 do: > + [:reg| > + (reg between: RSP and: RBP) ifFalse: > + [cogit PopR: reg]]. > - cogit > - PopR: RAX; > - PopR: RBX; > - PopR: RCX; > - PopR: RDX; > - PopR: RSI; > - PopR: RDI; > - PopR: R8; > - PopR: R9; > - PopR: R10; > - PopR: R11; > - PopR: R12; > - PopR: R13; > - PopR: R14; > - PopR: R15. > ^0! > > Item was changed: > ----- Method: CogX64Compiler>>genRestoreRegsExcept: (in category 'abi') > ----- > genRestoreRegsExcept: abstractReg > | realReg | > realReg := self concreteRegister: abstractReg. > self assert: (R15 > RAX and: [R15 - RAX + 1 = 16]). > RAX to: R15 do: > [:reg| > + (reg between: RSP and: RBP) ifFalse: > + [realReg = reg > + ifTrue: [cogit AddCq: 8 R: RSP] > + ifFalse: [cogit PopR: reg]]]. > - realReg = reg ifTrue: [cogit AddCq: 4 R: RSP] ifFalse: > [cogit PopR: reg]]. > ^0! > > Item was removed: > - ----- Method: CogX64Compiler>>genSaveRegisters (in category 'abi') ----- > - genSaveRegisters > - "Save the general purpose registers for a trampoline call." > - > - self assert: (R15 > RAX and: [R15 - RAX + 1 = 16]). > - R15 to: RAX by: -1 do: [:reg| cogit PushR: reg]. > - ^0! > > Item was added: > + ----- Method: CogX64Compiler>>genSaveRegsForCCall (in category 'abi') > ----- > + genSaveRegsForCCall > + "Save the general purpose registers for a trampoline call." > + > + self assert: (R15 > RAX and: [R15 - RAX + 1 = 16]). > + R15 to: RAX by: -1 do: > + [:reg| > + (reg between: RSP and: RBP) ifFalse: > + [cogit PushR: reg]]. > + ^0! > > Item was changed: > ----- Method: > Cogit>>compileCallFor:numArgs:arg:arg:arg:arg:resultReg:saveRegs: (in > category 'initialization') ----- > compileCallFor: aRoutine numArgs: numArgs arg: regOrConst0 arg: > regOrConst1 arg: regOrConst2 arg: regOrConst3 resultReg: resultRegOrNone > saveRegs: saveRegs > "Generate a call to aRoutine with up to 4 arguments. If > resultRegOrNone is not > NoReg assign the C result to resultRegOrNone. If saveRegs, save > all registers. > Hack: a negative arg value indicates an abstract register, a > non-negative value > indicates a constant." > <var: #aRoutine type: #'void *'> > <inline: false> > cStackAlignment > objectMemory wordSize ifTrue: > [backEnd > genAlignCStackSavingRegisters: saveRegs > numArgs: numArgs > wordAlignment: cStackAlignment / objectMemory > wordSize]. > saveRegs ifTrue: > + [backEnd genSaveRegsForCCall]. > - [backEnd genSaveRegisters]. > backEnd genMarshallNArgs: numArgs arg: regOrConst0 arg: > regOrConst1 arg: regOrConst2 arg: regOrConst3. > self CallFullRT: (self cCode: [aRoutine asUnsignedInteger] > inSmalltalk: [self > simulatedTrampolineFor: aRoutine]). > resultRegOrNone ~= NoReg ifTrue: > [backEnd genWriteCResultIntoReg: resultRegOrNone]. > saveRegs ifTrue: > [numArgs > 0 ifTrue: > [backEnd genRemoveNArgsFromStack: numArgs]. > resultRegOrNone ~= NoReg > ifTrue: [backEnd genRestoreRegsExcept: > resultRegOrNone] > ifFalse: [backEnd genRestoreRegs]]! > > -- _,,,^..^,,,_ best, Eliot

8 9