- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Max Leske

> On 20 Dec 2015, at 13:43, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Max, > > sum: aBlock ifEmpty: emptyBlock needs to obtain the sample evaluating the block. > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := aBlock value: self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample Thanks! Missed that. > > On Sun, Dec 20, 2015 at 8:59 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > I would like to wrap up this discussion. > > >> On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> So what is the conclusion? >> I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. >> >> [[[ >> >> aCollection arithmetic sum: [...] or.... aCollection >> arithmetic avg. >> >> ]]] >> > > > While I think that iterators are an intriguing idea I also believe that they are beyond the scope of this issue. If anybody wants to follow up on iterators (or unit types for that matter) please start a new thread / issue. > > > I propose to use Svenâs version for #sum:ifEmpty:. The result would be these three methods: > > sum > ^ self > sum: [ :each | each ] > ifEmpty: [ 0 ] > > sum: aBlock > ^ self > sum: aBlock > ifEmpty: [ self errorEmptyCollection ] > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample > > > Iâve attached a couple of benchmark results below. To me they show that > 1. the new implementation is maybe a tiny bit slower but insignificantly so (if youâre going for performance youâll probably write your own optimised version anyway) > 2. there is no need to duplicate the code (like #sum and #sum: currently do). Itâs perfectly fine to delegate to #sum:ifEmpty: > > > > In addition to the above changes I would like to remove #detectSum: (-> #sum:) and #sumNumbers (-> #sum). > > > Note that once we agree on changing this API, we will need to also change #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. RunArray, Interval) of these and of #sum et. al. to stay consistent. The changes would of course be in line with this change, such that every operation has a unary selector with a sensible default, one that takes a block and throws an error for empty collections and a third that takes a block for the iteration and one for the empty case. > > > Please cast your vote for these changes: > > 1. Do you agree to changing #sum and #sum: in the suggested way? > > 2. Do you agree to the removal of #detectSum:? > > 3. Do you agree to the removal of #sumNumbers? > > 4. Do you agree that the #max and #min selectors also need to be adapted? > > > > Thanks for you help. > > Cheers, > Max > > > > > > Benchmarks > ============ > (Note that these arenât very good benchmarks. Thereâs quite some variation on each run.) > > > Machine: > MacBook Pro (15-inch, Early 2011) > CPU: 2.2 GHz Intel Core i7 > Memory: 8 GB 1333 MHz DDR3 > Disk: APPLE SSD TS512C (500 GB) > > > Benchmarks of the current versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 75 iterations, 7.470 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 72 iterations, 7.128 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,189,477 iterations, 118,912 per second > > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,171,467 iterations, 117,112 per second > > > > Benchmarks of the new versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 73 iterations, 7.244 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 75 iterations, 7.480 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 seconds. > 72 iterations, 7.141 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,115,827 iterations, 111,560 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,154,595 iterations, 115,425 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 seconds. > 1,102,358 iterations, 110,203 per second > >

Dec. 20, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Gabriel Cotelli

Max, sum: aBlock ifEmpty: emptyBlock needs to obtain the sample evaluating the block. sum: aBlock ifEmpty: emptyBlock | sum sample | self isEmpty ifTrue: [ ^ emptyBlock value ]. sample := aBlock value: self anyOne. sum := self inject: sample into: [ :accum :each | accum + (aBlock value: each) ]. ^ sum - sample On Sun, Dec 20, 2015 at 8:59 AM, Max Leske <maxleske(a)gmail.com> wrote: > I would like to wrap up this discussion. > > > On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr> wrote: > > So what is the conclusion? > I like the idea of Esteban M to have iterator because it moves some > behavior out of core classes. > > [[[ > > aCollection arithmetic sum: [...] or.... aCollection > arithmetic avg. > > ]]] > > > While I think that iterators are an intriguing idea I also believe that > they are beyond the scope of this issue. If anybody wants to follow up on > iterators (or unit types for that matter) please start a new thread / issue. > > > I propose to use Svenâs version for #sum:ifEmpty:. The result would be > these three methods: > > sum > ^ self > sum: [ :each | each ] > ifEmpty: [ 0 ] > > sum: aBlock > ^ self > sum: aBlock > ifEmpty: [ self errorEmptyCollection ] > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample > > > Iâve attached a couple of benchmark results below. To me they show that > 1. the new implementation is maybe a tiny bit slower but insignificantly > so (if youâre going for performance youâll probably write your own > optimised version anyway) > 2. there is no need to duplicate the code (like #sum and #sum: currently > do). Itâs perfectly fine to delegate to #sum:ifEmpty: > > > > In addition to the above changes I would like to remove #detectSum: (-> > #sum:) and #sumNumbers (-> #sum). > > > Note that once we agree on changing this API, we will need to also change > #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. > RunArray, Interval) of these and of #sum et. al. to stay consistent. The > changes would of course be in line with this change, such that every > operation has a unary selector with a sensible default, one that takes a > block and throws an error for empty collections and a third that takes a > block for the iteration and one for the empty case. > > > Please cast your vote for these changes: > > 1. Do you agree to changing #sum and #sum: in the suggested way? > > 2. Do you agree to the removal of #detectSum:? > > 3. Do you agree to the removal of #sumNumbers? > > 4. Do you agree that the #max and #min selectors also need to be adapted? > > > > Thanks for you help. > > Cheers, > Max > > > > > > Benchmarks > ============ > (Note that these arenât very good benchmarks. Thereâs quite some variation > on each run.) > > > Machine: > MacBook Pro (15-inch, Early 2011) > CPU: 2.2 GHz Intel Core i7 > Memory: 8 GB 1333 MHz DDR3 > Disk: APPLE SSD TS512C (500 GB) > > > Benchmarks of the current versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 75 iterations, 7.470 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 72 iterations, 7.128 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,189,477 iterations, 118,912 per second > > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,171,467 iterations, 117,112 per second > > > > Benchmarks of the new versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 73 iterations, 7.244 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 75 iterations, 7.480 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 72 iterations, 7.141 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,115,827 iterations, 111,560 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,154,595 iterations, 115,425 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 1,102,358 iterations, 110,203 per second > >

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] VM Maker: VMMaker.oscog-eem.1609.mcz

by Nicolas Cellier

SmallInteger maxVal highBit -> 60. 3 bits reserved for immediate tags, 1 bit for sign, 60 remaining for positive magnitude... 2015-12-20 11:56 GMT+01:00 stepharo <stepharo(a)free.fr>: > Super !!! > Eliot what will be > > 1 class maxval > then? > > Stef > > Le 17/12/15 20:12, Eliot Miranda a Ã©crit : > >> Hi All, >> >> the real Cog 64-bit Spur x64 VM just evaluated 3+4 correctly on Mac OS >> X: >> >> > >

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] Re: SecureSession frame types

by Robert Withers

Good morning, just a few comments and questions.. 1) current 4bits for msgVersion and 4bits for hdrType. With 14 messages and some not implemented (suspend/resume/...) we have little headroom in 4bits of hdrType. Shall I make the msgVersion 3bits and the hdrType 5bits? 2) the smallest interleaved FEC encoded msg is 30 bytes. With 8 bytes of data: a msgSpec, using RS(15,9) with 4bit symbols, and 4 symbol block interleaving, the smallest on the wire is 30 bytes. Without FEC enabled is it 8 bytes. 3) when run to the end of hdrType room, we can add a jump tag and have a second hdrType field as the 9th byte. Again, the valid document link is: https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0 Thank you, robert On 12/20/2015 06:20 AM, ClÃ©ment Bera wrote: > > > > Hello, > > I tried to get your document but I got: > > Dropbox - error > > Is it only me ? > > 2015-12-20 11:31 GMT+01:00 Robert Withers <robert.w.withers(a)gmail.com > <mailto:robert.w.withers@gmail.com>>: > > > Excuse me for failing to complete this email./ I wanted to ask for > feedback on these structures, especially the header specification > word structure. So these fields make sense? > > thank you, > robert > > > On 12/20/2015 05:27 AM, Robert Withers wrote: > > I wrote up the various SecureSession frame types in > presentation document, which you can get here: > https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0 > > These are not yet implemented, but it is progressing. Ne quid > nemis. > > thanks, > > > -- > . .. .. ^,^ robert > > -- . .. .. ^,^ robert

Dec. 20, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Max Leske

I would like to wrap up this discussion. > On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr> wrote: > > So what is the conclusion? > I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. > > [[[ > > aCollection arithmetic sum: [...] or.... aCollection > arithmetic avg. > > ]]] > While I think that iterators are an intriguing idea I also believe that they are beyond the scope of this issue. If anybody wants to follow up on iterators (or unit types for that matter) please start a new thread / issue. I propose to use Svenâs version for #sum:ifEmpty:. The result would be these three methods: sum ^ self sum: [ :each | each ] ifEmpty: [ 0 ] sum: aBlock ^ self sum: aBlock ifEmpty: [ self errorEmptyCollection ] sum: aBlock ifEmpty: emptyBlock | sum sample | self isEmpty ifTrue: [ ^ emptyBlock value ]. sample := self anyOne. sum := self inject: sample into: [ :accum :each | accum + (aBlock value: each) ]. ^ sum - sample Iâve attached a couple of benchmark results below. To me they show that 1. the new implementation is maybe a tiny bit slower but insignificantly so (if youâre going for performance youâll probably write your own optimised version anyway) 2. there is no need to duplicate the code (like #sum and #sum: currently do). Itâs perfectly fine to delegate to #sum:ifEmpty: In addition to the above changes I would like to remove #detectSum: (-> #sum:) and #sumNumbers (-> #sum). Note that once we agree on changing this API, we will need to also change #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. RunArray, Interval) of these and of #sum et. al. to stay consistent. The changes would of course be in line with this change, such that every operation has a unary selector with a sensible default, one that takes a block and throws an error for empty collections and a third that takes a block for the iteration and one for the empty case. Please cast your vote for these changes: 1. Do you agree to changing #sum and #sum: in the suggested way? 2. Do you agree to the removal of #detectSum:? 3. Do you agree to the removal of #sumNumbers? 4. Do you agree that the #max and #min selectors also need to be adapted? Thanks for you help. Cheers, Max Benchmarks ============ (Note that these arenât very good benchmarks. Thereâs quite some variation on each run.) Machine: MacBook Pro (15-inch, Early 2011) CPU: 2.2 GHz Intel Core i7 Memory: 8 GB 1333 MHz DDR3 Disk: APPLE SSD TS512C (500 GB) Benchmarks of the current versions: [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. 75 iterations, 7.470 per second [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. 72 iterations, 7.128 per second [ (1 to: 100) asArray sum ] benchFor: 10 seconds. 1,189,477 iterations, 118,912 per second [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. 1,171,467 iterations, 117,112 per second Benchmarks of the new versions: [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. 73 iterations, 7.244 per second [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. 75 iterations, 7.480 per second [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 seconds. 72 iterations, 7.141 per second [ (1 to: 100) asArray sum ] benchFor: 10 seconds. 1,115,827 iterations, 111,560 per second [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. 1,154,595 iterations, 115,425 per second [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 seconds. 1,102,358 iterations, 110,203 per second

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] Re: SecureSession frame types

by Ferlicot D. Cyril

Le 20/12/2015 12:20, ClÃ©ment Bera a Ã©crit : > Hello, > > I tried to get your document but I got: > > Dropbox - error > > Is it only me ? > > Hi, I could get it without problem. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] Re: SecureSession frame types

by ClÃ©ment Bera

Hello, I tried to get your document but I got: Dropbox - error Is it only me ? 2015-12-20 11:31 GMT+01:00 Robert Withers <robert.w.withers(a)gmail.com>: > > Excuse me for failing to complete this email./ I wanted to ask for > feedback on these structures, especially the header specification word > structure. So these fields make sense? > > thank you, > robert > > > On 12/20/2015 05:27 AM, Robert Withers wrote: > >> I wrote up the various SecureSession frame types in presentation >> document, which you can get here: >> https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0 >> >> These are not yet implemented, but it is progressing. Ne quid nemis. >> >> thanks, >> > > -- > . .. .. ^,^ robert >

Dec. 20, 2015

Re: [Pharo-dev] SecureSession frame types

by Robert Withers

Irked and confused how to share updatable documents through dropbox. It didn't help that I had logged off the daemon. I reordered the 64bit header. Here's an updated link. If the doc changes in the future, I hope this link continues to work. https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0 regards, robert On 12/20/2015 05:31 AM, Robert Withers wrote: > Excuse me for failing to complete this email./ I wanted to ask for > feedback on these structures, especially the header specification word > structure. So these fields make sense? > > thank you, > robert > > On 12/20/2015 05:27 AM, Robert Withers wrote: >> I wrote up the various SecureSession frame types in presentation >> document, which you can get here: >> https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0 >> >> These are not yet implemented, but it is progressing. Ne quid nemis. >> >> thanks, > -- . .. .. ^,^ robert

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] VM Maker: VMMaker.oscog-eem.1609.mcz

by Tudor Girba

Merry Christmas to you, too :)! Doru > On Dec 17, 2015, at 8:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > the real Cog 64-bit Spur x64 VM just evaluated 3+4 correctly on Mac OS X: > > <Screen Shot 2015-12-17 at 11.10.14.png> > â > > 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 -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] VM Maker: VMMaker.oscog-eem.1609.mcz

by stepharo

Super !!! Eliot what will be 1 class maxval then? Stef Le 17/12/15 20:12, Eliot Miranda a Ã©crit : > Hi All, > > the real Cog 64-bit Spur x64 VM just evaluated 3+4 correctly on Mac > OS X: >

Dec. 20, 2015