Vm-dev December 2015

vm-dev@lists.squeakfoundation.org

33 participants
207 discussions

Start a nNew thread

new CryptOCap architecture, known as the Split Mushroom
by Robert Withers 23 Dec '15

23 Dec '15

Split Mushroom -- . .. ... ^,^ robert Go Panthers!

1 0

[SecureSession] version 74 is out with compression enabled
by Robert Withers 23 Dec '15

23 Dec '15

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

1 0

SecureSession frame types
by Robert Withers 22 Dec '15

22 Dec '15

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

2 12

OT: Convince me github is a wise choice
by Eliot Miranda 21 Dec '15

21 Dec '15

Hi Ben, Hi All, I'm quite conservative when it comes to relying on others' infrastructure so I need some help making me take the plunge. Please see below: On Thu, Dec 17, 2015 at 7:15 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, Dec 16, 2015 at 1:00 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> On Wed, Dec 16, 2015 at 10:43 AM, Ryan Macnak <rmacnak(a)gmail.com> > wrote: > >> > > >> > What would be more helpful is if the VM build was fixed to work with > a cross compiler, so it would compile fast enough to test ARM and MIPS on > Travis CI alongside IA32 and X64. > >> > > >> > It would also help if the top-of-tree Intel VMs were always kept > working so we'd know which change broke something. Moving the Subversion > repository to a more reliable host (which likely means migrating to Git) > would also cut down on the false positives Travis reports because the > Subversion server has a habit of dropping connections. > >> > >> +1 github :) > > btw, Did you know that github supports subversion clients since 2011 [1]? > Here are supported features [2]. Are these sufficient for your > current svn workflows? > Potentially we could have ONE repository and those liking subversion > can stick with it and those liking git can use that. Of course, this > would need to be proven. > Ah, that's interesting. So my concern is whether github is a safe long-term bet. Specifically what is there to prevent some third party from buying github, or of github going public and the board taking the decision, or github on its own, deciding to charge for hosting, keeping the data hostage to extract payment? What safeguards are in place to prevent this? I'm not interested in "this will never happen" arguments. I'm interested in hard data please. [4] Provides pragmatic advice for cutting over. Esteban appears to > have done similar to step 1 and 2 [3] - but it seem sometimes his > modifications directly update this mirror so its not clear to see when > that branch is an *exact* copy of the current svn trunk. So I'd love > to see a github repository that is always an *exact* mirror of the svn > repository, with any pharo mods occurring in a branch off that. Even > better if the repository for svn users resides on github in place of > that mirror. > > I've been googling around for problems reported using github via an > svn client, and haven't found any smoking guns. > Is this something we can trial? I'm willing to put some effort into > it. A key requirement would be not interrupting Eliots work on > Spur-64. Potentially we could stay for months on step 3 [4] with the > CI infrastructure running on the git side, but code check-ins > continuing onthe svn side. > > btw2, [5] provides a use case for the advantages of a full switch. > > cheers -ben > > [1] https://github.com/blog/966-improved-subversion-client-support > [2] https://help.github.com/articles/support-for-subversion-clients/ > [3] https://github.com/pharo-project/pharo-vm/network > [4] > http://blogs.atlassian.com/2013/01/atlassian-svn-to-git-migration-technical… > [5] > http://blogs.atlassian.com/2013/01/svn-to-git-how-atlassian-made-the-switch… > -- _,,,^..^,,,_ best, Eliot

5 4

Re: [Vm-dev] VM Maker: VMMaker.oscog-eem.1609.mcz
by Eliot Miranda 20 Dec '15

20 Dec '15

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

6 5

pluginizing Galois Fields
by Robert Withers 20 Dec '15

20 Dec '15

I thought I would post to these lists. I have a nascent implementation of Reed-Solomon encoding using Galois Fields. Computation within the field is governed by polynomial representation and operations (add, subtract, multiply, divide, inverse, exp, log). These operations on polynomials is where the profile says most time is being used. The code can be seen in the SecureSession package in squeaksource's Cryptography repository. The point of this email is to see if the folks who would know how to represent polynomials and operations in Slang would be interested in working towards this performance effort, whether through discussion of implementation. How would you Slanginize a polynomial and it's operations? manythanks, -- . .. .. ^,^ robert

5 28

Fwd: Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)
by Robert Withers 19 Dec '15

19 Dec '15

:) Thank you! -------- Forwarded Message -------- Subject: Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto) Date: Fri, 18 Dec 2015 22:37:00 -0500 From: Robert Withers <robert.w.withers(a)gmail.com> To: pharo-users(a)lists.pharo.org The Ode to CryptoCeps: Bouncer: "No, I'm sorry. This is a restricted area..." *checks around in case there's a problem* Me: " 'cep I got this..." *hands over teensie tiny tasty little mushoom* Note to self: 'did I eat one of those???' *can't seem to recall the particular moment. Oh@* Community: *looking sideways at each other* "What the hell is a mushoom?" Thank You! so much. On 12/18/2015 10:27 PM, Robert Withers wrote: > Ah ha!!! Thank you...how about CryptOCeps? ;) > > On 12/18/2015 10:22 PM, Offray Vladimir Luna Cárdenas wrote: >> Hi, >> >> On the names side, I would advice some kind of unique combination, >> for example "Jupyter notebook", works fine to find particularly the >> project this community is trying to build. In my own case, I spend a >> lot of time thinking in names and I discuss them with friends with a >> drink or a meal. Despite of not having a strong web presence in the >> sense of continuous updates in the web pages of my projects (my main >> web page is still under construction!) they position relatively well >> on google and DDG engines: >> >> [1] https://encrypted.google.com/search?hl=es&q=grafoscopio (5th link) >> [2] https://encrypted.google.com/search?hl=es&q=mutabit (1st link) >> [3] https://duckduckgo.com/?q=mutabit&t=ffsb (1st link) >> [4] https://duckduckgo.com/?q=grafoscopio&t=ffsb (2nd link) >> >> It didn't happen overnight but was a fluid organic process. So may be >> "Mushroom crypto" or "Risotto crypto" could be important descriptors >> in the main web presence sites of your projects (BTW, I can't find >> the repos and GitHub answers with 404). >> >> Cheers, >> >> Offray >> >> >> On 07/12/15 17:57, Robert Withers wrote: >>> Ben, Huw, Todd and Sven, thank you all for your feedback! I suppose >>> I could call the project "CryptOCaps" but for some reason I glommed >>> onto mushroom as the name. Not grandiose and it is somewhat >>> descriptive...a network of secure sessions, each one a mushroom. >>> Ceps are highly valued. We can tag it for the catalog. >>> >>> For sure, we have Seaside, Morphic, Nebraska, Fuel, Alien, Cog, >>> Monticello and that's just the squeak side of unusual naming of >>> projects. I hope that "mushroom" gains a wide reputation as a solid, >>> reliable, secure and performant session layer under the CryptOCaps >>> presentation...I am thinking of splitting the secure session layer >>> from the ocaps presentation layer, but this would require another >>> name choice, so I hesitate...perhaps "Risotto"? What are your thoughts? >>> >>> Best, >>> Robert >>> >>> On 12/07/2015 10:38 AM, Ben Coman wrote: >>>> I like it, but it seems you missed my point :) >>>> mushroom --> 117,000,000 is two orders of magnitude more hidden. >>>> Anyway, maybe I overplay its significance. >>>> cheers -ben >>>> >>>> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >>>> <robert.w.withers(a)gmail.com> wrote: >>>>> I renamed the project to Mushroom and I also dumped the encoding >>>>> work to >>>>> focus on shutdown, optimization and serialization. Here's the wiki: >>>>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>>>> >>>>> thanks,Robert >>>>> >>>>> >>>>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>> Now I think you are right on with your observation. >>>>>>>>> Additionally, the >>>>>>>>> number >>>>>>>>> of dialects could increase further with Fuel serialization, >>>>>>>>> just port >>>>>>>>> SecureSession and bits. >>>>>>>>> >>>>>>>>> Alright, I came up with a name and it may border on the >>>>>>>>> egregious ... >>>>>>>>> presenting ... >>>>>>>>> >>>>>>>>> "Maelstrom" >>>>>>>> Great sounding name. However some general advice for the >>>>>>>> community, >>>>>>>> since I see a lot of great sounding project names drowned out >>>>>>>> in the >>>>>>>> noise of our web-search-centric universe. A litmus test for >>>>>>>> project >>>>>>>> naming is using google search to find which return low search >>>>>>>> results. >>>>>>>> Today, its more important to be unique than any other attribute >>>>>>>> of a >>>>>>>> name. So in general, *dictionary* english words are not the best. >>>>>>>> One technique is to intentionally mispell the word you like. >>>>>>>> Here are >>>>>>>> some comparative examples (note, the surrounding quotes are >>>>>>>> required >>>>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>>>> >>>>>>>> "maelstrom" --> 7,480,000 >>>>>>>> "maelstroom" --> 6,200 >>>>>>>> "maelstrum" --> 2,280 >>>>>>>> "maelstruum" --> 7 >>>>>>>> >>>>>>>> Lots of interesting other techniques can be found by searching on: >>>>>>>> techniques to generate brand names or domain names. >>>>>>>> >>>>>>>> cheers -ben >>>>>>> >>>>>>> I would be happy to change the names to something more unique, >>>>>>> though it >>>>>>> may >>>>>>> take a few. Are you suggesting "maelstruum"? >>>>>>> >>>>>>> cheers, >>>>>>> Robert >>>>>>> >>>>>>> >>>>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>>>> >>>>>> I think maelstruum is certainly memorable with the double "u", but >>>>>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>>>>> associate it with "zoom". I wouldn't necessarily go for the >>>>>> absolute >>>>>> lowest results. I have an entirely unsubstantiated belief that >>>>>> anything less than 10,000 gives a reasonable chance to compete >>>>>> once a >>>>>> user's browsing history is taken into account. Finally you need to >>>>>> check existing results don't return something abhorrent (I didn't do >>>>>> this). >>>>>> >>>>>> I'd encourage to play around testing on google search. Its quick and >>>>>> easy to generate and test alternatives. I've added a few more below. >>>>>> "maelstra" --> 3,560 >>>>>> "maelstram" --> 504 >>>>>> "maelstrim" --> 1200 >>>>>> "maelstroon" --> 58 >>>>>> "maelstroomi" --> 4 >>>>>> >>>>>> btw, I wouldn't swap the order of the "ae" since that would be >>>>>> susceptible to real typing errors. >>>>>> >>>>>> cheers -ben >>>>>> >>>>> >>> >>> >>> >> >> > -- . .. .. ^,^ robert

1 0

VM Maker: VMMaker.oscog-eem.1610.mcz
by commits＠source.squeak.org 19 Dec '15

19 Dec '15

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1610.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1610 Author: eem Time: 18 December 2015, 7:03:36.871 pm UUID: 30dfc36f-1c08-4c13-a442-f4aa09bfe11f Ancestors: VMMaker.oscog-eem.1609 Cogit: Execute the "abstract registers simply name concrete registers" coup. I've tested the x86, ARM & x64 code generators for Squeak. I haven't yet tested Newspeak but suspect it will be fine. More importantly I haven't tested Sista, and given that Sista makes much more use of registers there could be issues here. Clément, apologies for any disturbance. SImulator: Fix a simulation-time assert failure if printStackCallStackOf: is given a StackInterpreter frame pointer (which are negative). Add accessors for printSends. Slang: Make slang check for cppIf:'s first argument being a string before using isEmpty/notEmpty, for robustness. =============== Diff against VMMaker.oscog-eem.1609 =============== Item was changed: ----- Method: CCodeGenerator>>generateInlineCCodeAsArgument:on:indent: (in category 'C translation') ----- generateInlineCCodeAsArgument: msgNode on: aStream indent: level "Generate the C code for this message onto the given stream. There are two forms, self cCode: aString ... and self cCode: aBlock." + (msgNode args first isConstant + and: [msgNode args first value isString]) - msgNode args first isConstant ifTrue: [(msgNode args first value at: 1 ifAbsent: nil) = $# ifTrue: [aStream cr]. aStream nextPutAll: msgNode args first value] ifFalse: [msgNode args first emitCCodeAsArgumentOn: aStream level: level generator: self]! Item was added: + ----- Method: CogARMCompiler class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + + "N.B. According to BSABI, R0-R3 are caller-save, R4-R12 are callee save. + Note that R9 might be a special register for the implementation. In some slides + it is refered to as sb. R10 can contain the stack limit (sl), R11 the fp. R12 is an + intra-procedure scratch instruction pointer for link purposes. It can also be used. + R10 is used as temporary inside a single abstract opcode implementation" + "R0-R3 are used when calling back to the interpreter. Using them would require + saving and restoring their values, so they are omitted so far. R12 is the only + scratch register at the moment.." + + TempReg := R0. + ClassReg := R8. + ReceiverResultReg := R7. + SendNumArgsReg := R6. + SPReg := SP. "R13" + FPReg := R11. + Arg0Reg := R4. + Arg1Reg := R5. + VarBaseReg := ConcreteVarBaseReg. "Must be callee saved" + RISCTempReg := ConcreteIPReg. "a.k.a. IP" + Scratch0Reg := R12. + LinkReg := LR. "R14" + PCReg := PC. "R15" + + DPFPReg0 := D0. + DPFPReg1 := D1. + DPFPReg2 := D2. + DPFPReg3 := D3. + DPFPReg4 := D4. + DPFPReg5 := D5. + DPFPReg6 := D6. + DPFPReg7 := D7 + ! Item was removed: - ----- Method: CogARMCompiler>>abstractRegisterForConcreteRegister: (in category 'private') ----- - abstractRegisterForConcreteRegister: reg - (self concreteRegister: TempReg) = reg ifTrue: [^TempReg]. - (self concreteRegister: ReceiverResultReg) = reg ifTrue: [^ReceiverResultReg]. - (self concreteRegister: ClassReg) = reg ifTrue: [^ClassReg]. - (self concreteRegister: SendNumArgsReg) = reg ifTrue: [^SendNumArgsReg]. - (self concreteRegister: Arg0Reg) = reg ifTrue: [^Arg0Reg]. - (self concreteRegister: Arg1Reg) = reg ifTrue: [^Arg1Reg]. - (self concreteRegister: FPReg) = reg ifTrue: [^FPReg]. - (self concreteRegister: SPReg) = reg ifTrue: [^SPReg]. - (self concreteRegister: LinkReg) = reg ifTrue: [^LinkReg]. - (self concreteRegister: RISCTempReg) = reg ifTrue: [^RISCTempReg]. - (self concreteRegister: PCReg) = reg ifTrue: [^PCReg]. - (self concreteRegister: VarBaseReg) = reg ifTrue: [^VarBaseReg]. - (self concreteRegister: Scratch0Reg) = reg ifTrue: [^Scratch0Reg]. - self error: 'could not find abstract register'. - ^0 - - "({ TempReg. ReceiverResultReg. ClassReg. SendNumArgsReg. Arg0Reg. Arg1Reg. - FPReg. SPReg. - LinkReg. RISCTempReg. PCReg. VarBaseReg. - Scratch0Reg } collect: [:i| self basicNew concreteRegister: i]) sort" - - "While the below works fine in Smalltalk it of course doesn't work in C ;)" - - "^reg caseOf: { - [self concreteRegister: TempReg] -> [TempReg]. - [self concreteRegister: ReceiverResultReg] -> [ReceiverResultReg]. - [self concreteRegister: ClassReg] -> [ClassReg]. - [self concreteRegister: SendNumArgsReg] -> [SendNumArgsReg]. - [self concreteRegister: Arg0Reg] -> [Arg0Reg]. - [self concreteRegister: Arg1Reg] -> [Arg1Reg]. - [self concreteRegister: FPReg] -> [FPReg]. - [self concreteRegister: SPReg] -> [SPReg] }"! Item was removed: - ----- Method: CogARMCompiler>>concreteDPFPRegister: (in category 'encoding') ----- - concreteDPFPRegister: registerIndex - "Map a possibly abstract double-precision floating-point register into a concrete one. - Abstract registers (defined in CogAbstractOpcodes) are all negative. If registerIndex - is negative assume it is an abstract register." - - ^registerIndex - caseOf: { - [DPFPReg0] -> [D0]. - [DPFPReg1] -> [D1]. - [DPFPReg2] -> [D2]. - [DPFPReg3] -> [D3]. - [DPFPReg4] -> [D4]. - [DPFPReg5] -> [D5]. - [DPFPReg6] -> [D6]. - [DPFPReg7] -> [D7] } - otherwise: - [self assert: (registerIndex between: D0 and: D7). - registerIndex]! Item was removed: - ----- Method: CogARMCompiler>>concreteRegister: (in category 'encoding') ----- - concreteRegister: registerIndex - "Map a possibly abstract register into a concrete one. Abstract registers - (defined in CogAbstractOpcodes) are all negative. If registerIndex is - negative assume it is an abstract register." - - "N.B. According to BSABI, R0-R3 are caller-save, R4-R12 are callee save. - Note that R9 might be a special register for the implementation. In some slides - it is refered to as sb. R10 can contain the stack limit (sl), R11 the fp. R12 is an - intra-procedure scratch instruction pointer for link purposes. It can also be used. - R10 is used as temporary inside a single abstract opcode implementation" - "R0-R3 are used when calling back to the interpreter. Using them would require - saving and restoring their values, so they are omitted so far. R12 is the only - scratch register at the moment.." - ^registerIndex - caseOf: { - [TempReg] -> [R0]. - [ClassReg] -> [R8]. - [ReceiverResultReg] -> [R7]. - [SendNumArgsReg] -> [R6]. - [SPReg] -> [SP]. "R13" - [FPReg] -> [R11]. - [Arg0Reg] -> [R4]. - [Arg1Reg] -> [R5]. - [VarBaseReg] -> [ConcreteVarBaseReg]. "Must be callee saved" - [RISCTempReg] -> [ConcreteIPReg]. "a.k.a. IP" - [Scratch0Reg] -> [R12]. - [LinkReg] -> [LR]. "R14" - [PCReg] -> [PC] "R15" } - otherwise: - [self assert: (registerIndex between: R0 and: PC). - registerIndex]! Item was changed: ----- Method: CogARMCompiler>>genMarshallNArgs:arg:arg:arg:arg: (in category 'abi') ----- genMarshallNArgs: numArgs arg: regOrConst0 arg: regOrConst1 arg: regOrConst2 arg: regOrConst3 + "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is + either a negative number, which encodes a constant, or a non-negative number, that of a register. - "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is either a - negative number, that of an abstract register, or a non-negative number, that of a constant parameter. Run-time calls have no more than four arguments, so chosen so that on ARM, where in its C ABI the first four integer arguments are passed in registers, all arguments can be passed in registers. We + defer to the back end to generate this code not so much that the back end knows whether it uses - defer to the back end to generate this code not so much that teh back end knows whether it uses the stack or registers to pass arguments (it does, but...). In fact we defer for an extremely evil reason. Doing so allows the x64 (where up to 6 args are passed) to assign the register arguments in an order + that allows some of the argument registers to be used for specific abstract registers, specifically + ReceiverResultReg and ClassReg. This is evil, evil, evil, but also it's really nice to keep using the old + register assignments the original author has grown accustomed to." - that allows some of the argument registers to be used for specificabstract registers, specifically - ReceiverResultReg and ClassReg. This is evil, evil, evil, but also its really nice to keep using the old - register assignments the principal author has grown accustomed to." <inline: true> numArgs = 0 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst0) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst0) R: CArg0Reg] - regOrConst0 >= 0 - ifTrue: [cogit MoveCq: regOrConst0 R: CArg0Reg] ifFalse: [cogit MoveR: regOrConst0 R: CArg0Reg]. numArgs = 1 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst1) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst1) R: CArg1Reg] - regOrConst1 >= 0 - ifTrue: [cogit MoveCq: regOrConst1 R: CArg1Reg] ifFalse: [cogit MoveR: regOrConst1 R: CArg1Reg]. numArgs = 2 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst2) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: CArg2Reg] - regOrConst2 >= 0 - ifTrue: [cogit MoveCq: regOrConst2 R: CArg2Reg] ifFalse: [cogit MoveR: regOrConst2 R: CArg2Reg]. numArgs = 3 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst3) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: CArg3Reg] - regOrConst3 >= 0 - ifTrue: [cogit MoveCq: regOrConst3 R: CArg3Reg] ifFalse: [cogit MoveR: regOrConst3 R: CArg3Reg]! Item was added: + ----- Method: CogAbstractInstruction class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + self subclassResponsibility! Item was changed: ----- Method: CogAbstractInstruction>>abstractRegisterForConcreteRegister: (in category 'private') ----- abstractRegisterForConcreteRegister: reg + <inline: true> + self cCode: [] inSmalltalk: [self assert: reg isInteger]. + ^reg! - (self concreteRegister: TempReg) = reg ifTrue: [^TempReg]. - (self concreteRegister: ReceiverResultReg) = reg ifTrue: [^ReceiverResultReg]. - (self concreteRegister: ClassReg) = reg ifTrue: [^ClassReg]. - (self concreteRegister: SendNumArgsReg) = reg ifTrue: [^SendNumArgsReg]. - (self concreteRegister: Arg0Reg) = reg ifTrue: [^Arg0Reg]. - (self concreteRegister: Arg1Reg) = reg ifTrue: [^Arg1Reg]. - (self concreteRegister: FPReg) = reg ifTrue: [^FPReg]. - (self concreteRegister: SPReg) = reg ifTrue: [^SPReg]. - self error: 'could not find abstract register'. - ^0 - - "While the below works fine in Smalltalk it of course doesn't work in C ;)" - - "^reg caseOf: { - [self concreteRegister: TempReg] -> [TempReg]. - [self concreteRegister: ReceiverResultReg] -> [ReceiverResultReg]. - [self concreteRegister: ClassReg] -> [ClassReg]. - [self concreteRegister: SendNumArgsReg] -> [SendNumArgsReg]. - [self concreteRegister: Arg0Reg] -> [Arg0Reg]. - [self concreteRegister: Arg1Reg] -> [Arg1Reg]. - [self concreteRegister: FPReg] -> [FPReg]. - [self concreteRegister: SPReg] -> [SPReg] }"! Item was added: + ----- Method: CogAbstractInstruction>>concreteDPFPRegister: (in category 'encoding') ----- + concreteDPFPRegister: reg + <inline: true> + self cCode: [] inSmalltalk: [self assert: reg isInteger]. + ^reg! Item was added: + ----- Method: CogAbstractInstruction>>concreteRegister: (in category 'private') ----- + concreteRegister: reg + <inline: true> + self cCode: [] inSmalltalk: [self assert: reg isInteger]. + ^reg! Item was changed: ----- Method: CogAbstractInstruction>>genMarshallNArgs:arg:arg:arg:arg: (in category 'abi') ----- genMarshallNArgs: numArgs arg: regOrConst0 arg: regOrConst1 arg: regOrConst2 arg: regOrConst3 + "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is + either a negative number, which encodes a constant, or a non-negative number, that of a register. - "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is either a - negative number, that of an abstract register, or a non-negative number, that of a constant parameter. Run-time calls have no more than four arguments, so chosen so that on ARM, where in its C ABI the first four integer arguments are passed in registers, all arguments can be passed in registers. We + defer to the back end to generate this code not so much that the back end knows whether it uses - defer to the back end to generate this code not so much that teh back end knows whether it uses the stack or registers to pass arguments (it does, but...). In fact we defer for an extremely evil reason. Doing so allows the x64 (where up to 6 args are passed) to assign the register arguments in an order + that allows some of the argument registers to be used for specific abstract registers, specifically + ReceiverResultReg and ClassReg. This is evil, evil, evil, but also it's really nice to keep using the old + register assignments the original author has grown accustomed to." - that allows some of the argument registers to be used for specificabstract registers, specifically - ReceiverResultReg and ClassReg. This is evil, evil, evil, but also its really nice to keep using the old - register assignments the principal author has grown accustomed to." <inline: true> ^self subclassResponsibility! Item was added: + ----- Method: CogIA32Compiler class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + + "N.B. EAX ECX & EDX are caller-save (scratch) registers. Hence we use ECX for class and EDX for + receiver/result since these are written in all normal sends. EBX ESI & EDI are callee-save." + + TempReg := EAX. + ClassReg := ECX. + ReceiverResultReg := EDX. + SendNumArgsReg := EBX. + SPReg := ESP. + FPReg := EBP. + Arg0Reg := ESI. + Arg1Reg := EDI. + + DPFPReg0 := XMM0L / 2. + DPFPReg1 := XMM1L / 2. + DPFPReg2 := XMM2L / 2. + DPFPReg3 := XMM3L / 2. + DPFPReg4 := XMM4L / 2. + DPFPReg5 := XMM5L / 2. + DPFPReg6 := XMM6L / 2. + DPFPReg7 := XMM7L / 2! Item was removed: - ----- Method: CogIA32Compiler>>concreteDPFPRegister: (in category 'encoding') ----- - concreteDPFPRegister: registerIndex - "Map a possibly abstract double-precision floating-point register into a concrete one. - Abstract registers (defined in CogAbstractOpcodes) are all negative. If registerIndex - is negative assume it is an abstract register. - - [1] IA-32 Intel® Architecture Software Developer's Manual Volume 2A: Instruction Set Reference, A-M" - - ^registerIndex - caseOf: { - [DPFPReg0] -> [XMM0L / 2]. - [DPFPReg1] -> [XMM1L / 2]. - [DPFPReg2] -> [XMM2L / 2]. - [DPFPReg3] -> [XMM3L / 2]. - [DPFPReg4] -> [XMM4L / 2]. - [DPFPReg5] -> [XMM5L / 2]. - [DPFPReg6] -> [XMM6L / 2]. - [DPFPReg7] -> [XMM7L / 2] } - otherwise: - [self assert: (registerIndex between: XMM0L and: XMM7L). - self assert: (registerIndex bitAnd: 1) = 0. - registerIndex / 2]! Item was removed: - ----- Method: CogIA32Compiler>>concreteRegister: (in category 'encoding') ----- - concreteRegister: registerIndex - "Map a possibly abstract register into a concrete one. Abstract registers - (defined in CogAbstractOpcodes) are all negative. If registerIndex is - negative assume it is an abstract register. - - [1] IA-32 Intel® Architecture Software Developer's Manual Volume 2A: Instruction Set Reference, A-M - - - N.B. EAX ECX & EDX are caller-save (scratch) registers. Hence we use ECX for class and EDX for - receiver/result since these are written in all normal sends. EBX ESI & EDI are callee-save." - - ^registerIndex - caseOf: { - [TempReg] -> [EAX]. - [ClassReg] -> [ECX]. - [ReceiverResultReg] -> [EDX]. - [SendNumArgsReg] -> [EBX]. - [SPReg] -> [ESP]. - [FPReg] -> [EBP]. - [Arg0Reg] -> [ESI]. - [Arg1Reg] -> [EDI] } - otherwise: - [self assert: (registerIndex between: EAX and: EDI). - registerIndex]! Item was changed: ----- Method: CogIA32Compiler>>genMarshallNArgs:arg:arg:arg:arg: (in category 'abi') ----- genMarshallNArgs: numArgs arg: regOrConst0 arg: regOrConst1 arg: regOrConst2 arg: regOrConst3 + "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is + either a negative number, which encodes a constant, or a non-negative number, that of a register. - "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is either a - negative number, that of an abstract register, or a non-negative number, that of a constant parameter. Run-time calls have no more than four arguments, so chosen so that on ARM, where in its C ABI the first four integer arguments are passed in registers, all arguments can be passed in registers. We + defer to the back end to generate this code not so much that the back end knows whether it uses - defer to the back end to generate this code not so much that teh back end knows whether it uses the stack or registers to pass arguments (it does, but...). In fact we defer for an extremely evil reason. Doing so allows the x64 (where up to 6 args are passed) to assign the register arguments in an order + that allows some of the argument registers to be used for specific abstract registers, specifically + ReceiverResultReg and ClassReg. This is evil, evil, evil, but also it's really nice to keep using the old + register assignments the original author has grown accustomed to." - that allows some of the argument registers to be used for specificabstract registers, specifically - ReceiverResultReg and ClassReg. This is evil, evil, evil, but also its really nice to keep using the old - register assignments the principal author has grown accustomed to." <inline: true> numArgs = 0 ifTrue: [^self]. numArgs > 1 ifTrue: [numArgs > 2 ifTrue: [numArgs > 3 ifTrue: + [(cogit isTrampolineArgConstant: regOrConst3) + ifFalse: [cogit PushR: regOrConst3] + ifTrue: [cogit PushCq: (cogit trampolineArgValue: regOrConst3)]]. + (cogit isTrampolineArgConstant: regOrConst2) + ifFalse: [cogit PushR: regOrConst2] + ifTrue: [cogit PushCq: (cogit trampolineArgValue: regOrConst2)]]. + (cogit isTrampolineArgConstant: regOrConst1) + ifFalse: [cogit PushR: regOrConst1] + ifTrue: [cogit PushCq: (cogit trampolineArgValue: regOrConst1)]]. + (cogit isTrampolineArgConstant: regOrConst0) + ifFalse: [cogit PushR: regOrConst0] + ifTrue: [cogit PushCq: (cogit trampolineArgValue: regOrConst0)]! - [regOrConst3 < 0 - ifTrue: [cogit PushR: regOrConst3] - ifFalse: [cogit PushCq: regOrConst3]]. - regOrConst2 < 0 - ifTrue: [cogit PushR: regOrConst2] - ifFalse: [cogit PushCq: regOrConst2]]. - regOrConst1 < 0 - ifTrue: [cogit PushR: regOrConst1] - ifFalse: [cogit PushCq: regOrConst1]]. - regOrConst0 < 0 - ifTrue: [cogit PushR: regOrConst0] - ifFalse: [cogit PushCq: regOrConst0]! Item was removed: - ----- Method: CogIA32CompilerForTests>>concreteRegister: (in category 'encoding') ----- - concreteRegister: value - ^value! Item was added: + ----- Method: CogInLineLiteralsX64Compiler class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + "[1] Figure 3.4 Register Usage in + System V Application Binary Interface + AMD64 Architecture Processor Supplement + + N.B. RAX RCX & RDX are caller-save (scratch) registers. Hence we use RCX for class and RDX for + receiver/result since these are written in all normal sends." + + TempReg := RAX. + ClassReg := RCX. + ReceiverResultReg := RDX. + SendNumArgsReg := R9. + SPReg := RSP. + FPReg := RBP. + Arg0Reg := RDI. "So as to agree with C ABI arg 0" + Arg1Reg := RSI. "So as to agree with C ABI arg 1" + VarBaseReg := RBX. "Must be callee saved" + RISCTempReg := R8. + Scratch0Reg := R10. + Scratch1Reg := R11. + Scratch2Reg := R12. + Scratch3Reg := R13. + Scratch4Reg := R14. + Scratch5Reg := R15. + + DPFPReg0 := XMM0L / 2. + DPFPReg1 := XMM1L / 2. + DPFPReg2 := XMM2L / 2. + DPFPReg3 := XMM3L / 2. + DPFPReg4 := XMM4L / 2. + DPFPReg5 := XMM5L / 2. + DPFPReg6 := XMM6L / 2. + DPFPReg7 := XMM7L / 2! Item was removed: - ----- Method: CogInLineLiteralsX64Compiler>>concreteRegister: (in category 'encoding') ----- - concreteRegister: registerIndex - "Map a possibly abstract register into a concrete one. Abstract registers - (defined in CogAbstractOpcodes) are all negative. If registerIndex is - negative assume it is an abstract register. - - [1] Figure 3.4 Register Usage in - System V Application Binary Interface - AMD64 Architecture Processor Supplement - - - N.B. RAX RCX & RDX are caller-save (scratch) registers. Hence we use RCX for class and RDX for - receiver/result since these are written in all normal sends." - - ^registerIndex - caseOf: { - [TempReg] -> [RAX]. - [ClassReg] -> [RCX]. - [ReceiverResultReg] -> [RDX]. - [SendNumArgsReg] -> [R9]. - [SPReg] -> [RSP]. - [FPReg] -> [RBP]. - [Arg0Reg] -> [RDI]. "So as to agree with C ABI arg 0" - [Arg1Reg] -> [RSI]. "So as to agree with C ABI arg 1" - [VarBaseReg] -> [RBX]. "Must be callee saved" - [RISCTempReg] -> [R8]. - [Scratch0Reg] -> [R10]. - [Scratch1Reg] -> [R11]. - [Scratch2Reg] -> [R12]. - [Scratch3Reg] -> [R13]. - [Scratch4Reg] -> [R14]. - [Scratch5Reg] -> [R15] } - otherwise: - [self assert: (registerIndex between: RAX and: R15). - registerIndex]! Item was added: + ----- Method: CogMIPSELCompiler class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + + "See MIPSConstants>>initializeRegisters for a description of the C ABI." + + "Note we can fit all of the abstract registers in C preserved registers, and + not need to save or restore them at runtime calls." + + ReceiverResultReg := S0. + Arg0Reg := S1. + Arg1Reg := S2. + ClassReg := S3. + SendNumArgsReg := S4. + TempReg := S5. + VarBaseReg := S6. "Must be callee saved" + SPReg := SP. + FPReg := FP. + RISCTempReg := AT. + LinkReg := RA! Item was removed: - ----- Method: CogMIPSELCompiler>>concreteRegister: (in category 'encoding') ----- - concreteRegister: registerIndex - "Map a possibly abstract register into a concrete one. Abstract registers - (defined in CogAbstractOpcodes) are all negative. If registerIndex is - negative assume it is an abstract register." - - "See MIPSConstants>>initializeRegisters for a description of the C ABI." - - "Note we can fit all of the abstract registers in C preserved registers, and - not need to save or restore them at runtime calls." - - ^registerIndex - caseOf: { - [ReceiverResultReg] -> [S0]. - [Arg0Reg] -> [S1]. - [Arg1Reg] -> [S2]. - [ClassReg] -> [S3]. - [SendNumArgsReg] -> [S4]. - [TempReg] -> [S5]. - [VarBaseReg] -> [S6]. "Must be callee saved" - [SPReg] -> [SP]. - [FPReg] -> [FP]. - [RISCTempReg] -> [AT]. - [LinkReg] -> [RA]. } - otherwise: - [self assert: (registerIndex between: R0 and: R31). - registerIndex]! Item was changed: ----- Method: CogMIPSELCompiler>>genMarshallNArgs:arg:arg:arg:arg: (in category 'abi') ----- genMarshallNArgs: numArgs arg: regOrConst0 arg: regOrConst1 arg: regOrConst2 arg: regOrConst3 + "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is + either a negative number, which encodes a constant, or a non-negative number, that of a register. - "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is either a - negative number, that of an abstract register, or a non-negative number, that of a constant parameter. Run-time calls have no more than four arguments, so chosen so that on ARM, where in its C ABI the first four integer arguments are passed in registers, all arguments can be passed in registers. We + defer to the back end to generate this code not so much that the back end knows whether it uses - defer to the back end to generate this code not so much that teh back end knows whether it uses the stack or registers to pass arguments (it does, but...). In fact we defer for an extremely evil reason. Doing so allows the x64 (where up to 6 args are passed) to assign the register arguments in an order + that allows some of the argument registers to be used for specific abstract registers, specifically + ReceiverResultReg and ClassReg. This is evil, evil, evil, but also it's really nice to keep using the old + register assignments the original author has grown accustomed to." - that allows some of the argument registers to be used for specificabstract registers, specifically - ReceiverResultReg and ClassReg. This is evil, evil, evil, but also its really nice to keep using the old - register assignments the principal author has grown accustomed to." <inline: true> self flag: #OABI. numArgs = 0 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst0) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst0) R: A0] - regOrConst0 >= 0 - ifTrue: [cogit MoveCq: regOrConst0 R: A0] ifFalse: [cogit MoveR: regOrConst0 R: A0]. numArgs = 1 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst1) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst1) R: A1] - regOrConst1 >= 0 - ifTrue: [cogit MoveCq: regOrConst1 R: A1] ifFalse: [cogit MoveR: regOrConst1 R: A1]. numArgs = 2 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst2) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: A2] - regOrConst2 >= 0 - ifTrue: [cogit MoveCq: regOrConst2 R: A2] ifFalse: [cogit MoveR: regOrConst2 R: A2]. numArgs = 3 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst3) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: A3] - regOrConst3 >= 0 - ifTrue: [cogit MoveCq: regOrConst3 R: A3] ifFalse: [cogit MoveR: regOrConst3 R: A3]! Item was added: + ----- Method: CogOutOfLineLiteralsX64Compiler class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + "[1] Figure 3.4 Register Usage in + System V Application Binary Interface + AMD64 Architecture Processor Supplement + + N.B. RAX RCX & RDX are caller-save (scratch) registers. Hence we use RCX for class and RDX for + receiver/result since these are written in all normal sends." + + TempReg := RAX. + ClassReg := RCX. + ReceiverResultReg := RDX. + SendNumArgsReg := R9. + SPReg := RSP. + FPReg := RBP. + Arg0Reg := RDI. "So as to agree with C ABI arg 0" + Arg1Reg := RSI. "So as to agree with C ABI arg 1" + VarBaseReg := RBX. "Must be callee saved" + "No need for a RISCTempReg because out-of-line literal loads imply no need for a special MoveCwR" + "RISCTempReg := R8." + Scratch0Reg := R10. + Scratch1Reg := R11. + Scratch2Reg := R12. + Scratch3Reg := R13. + Scratch4Reg := R14. + Scratch5Reg := R15. + Scratch6Reg := R8. + + DPFPReg0 := XMM0L / 2. + DPFPReg1 := XMM1L / 2. + DPFPReg2 := XMM2L / 2. + DPFPReg3 := XMM3L / 2. + DPFPReg4 := XMM4L / 2. + DPFPReg5 := XMM5L / 2. + DPFPReg6 := XMM6L / 2. + DPFPReg7 := XMM7L / 2! Item was removed: - ----- Method: CogOutOfLineLiteralsX64Compiler>>concreteRegister: (in category 'encoding') ----- - concreteRegister: registerIndex - "Map a possibly abstract register into a concrete one. Abstract registers - (defined in CogAbstractOpcodes) are all negative. If registerIndex is - negative assume it is an abstract register. - - [1] Figure 3.4 Register Usage in - System V Application Binary Interface - AMD64 Architecture Processor Supplement - - - N.B. RAX RCX & RDX are caller-save (scratch) registers. Hence we use RCX for class and RDX for - receiver/result since these are written in all normal sends." - - ^registerIndex - caseOf: { - [TempReg] -> [RAX]. - [ClassReg] -> [RCX]. - [ReceiverResultReg] -> [RDX]. - [SendNumArgsReg] -> [R8]. - [SPReg] -> [RSP]. - [FPReg] -> [RBP]. - [Arg0Reg] -> [RDI]. "So as to agree with C ABI arg 0" - [Arg1Reg] -> [RSI]. "So as to agree with C ABI arg 1" - [VarBaseReg] -> [RBX]. "Must be callee saved" - "No need for a RISCTempReg because out-of-line literal loads imply no need for a special MoveCwR" - "[RISCTempReg] -> [R8]." - [Scratch0Reg] -> [R9]. - [Scratch1Reg] -> [R10]. - [Scratch2Reg] -> [R11]. - [Scratch3Reg] -> [R12]. - [Scratch4Reg] -> [R13]. - [Scratch5Reg] -> [R14]. - [Scratch6Reg] -> [R15] } - otherwise: - [self assert: (registerIndex between: RAX and: R15). - registerIndex]! Item was changed: ----- Method: CogRTLOpcodes class>>initialize (in category 'class initialization') ----- (excessive size, no diff calculated) Item was added: + ----- Method: CogX64Compiler class>>initializeAbstractRegisters (in category 'class initialization') ----- + initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers." + self ~~ CogX64Compiler ifTrue: + [self subclassResponsibility]! Item was removed: - ----- Method: CogX64Compiler>>abstractRegisterForConcreteRegister: (in category 'private') ----- - abstractRegisterForConcreteRegister: reg - (self concreteRegister: TempReg) = reg ifTrue: [^TempReg]. - (self concreteRegister: ReceiverResultReg) = reg ifTrue: [^ReceiverResultReg]. - (self concreteRegister: ClassReg) = reg ifTrue: [^ClassReg]. - (self concreteRegister: SendNumArgsReg) = reg ifTrue: [^SendNumArgsReg]. - (self concreteRegister: Arg0Reg) = reg ifTrue: [^Arg0Reg]. - (self concreteRegister: Arg1Reg) = reg ifTrue: [^Arg1Reg]. - (self concreteRegister: FPReg) = reg ifTrue: [^FPReg]. - (self concreteRegister: SPReg) = reg ifTrue: [^SPReg]. - (self concreteRegister: RISCTempReg) = reg ifTrue: [^RISCTempReg]. - (self concreteRegister: VarBaseReg) = reg ifTrue: [^VarBaseReg]. - (self concreteRegister: Scratch0Reg) = reg ifTrue: [^Scratch0Reg]. - (self concreteRegister: Scratch1Reg) = reg ifTrue: [^Scratch1Reg]. - (self concreteRegister: Scratch2Reg) = reg ifTrue: [^Scratch2Reg]. - (self concreteRegister: Scratch3Reg) = reg ifTrue: [^Scratch3Reg]. - (self concreteRegister: Scratch4Reg) = reg ifTrue: [^Scratch4Reg]. - (self concreteRegister: Scratch5Reg) = reg ifTrue: [^Scratch5Reg]. - self error: 'could not find abstract register'. - ^0 - - "({ TempReg. ReceiverResultReg. ClassReg. SendNumArgsReg. Arg0Reg. Arg1Reg. - FPReg. SPReg. - RISCTempReg. VarBaseReg. - Scratch0Reg. Scratch1Reg. Scratch2Reg. Scratch3Reg. Scratch4Reg. Scratch5Reg. } collect: [:i| self basicNew concreteRegister: i]) sort" - - "While the below works fine in Smalltalk it of course doesn't work in C ;)" - - "^reg caseOf: { - [self concreteRegister: TempReg] -> [TempReg]. - [self concreteRegister: ReceiverResultReg] -> [ReceiverResultReg]. - [self concreteRegister: ClassReg] -> [ClassReg]. - [self concreteRegister: SendNumArgsReg] -> [SendNumArgsReg]. - [self concreteRegister: Arg0Reg] -> [Arg0Reg]. - [self concreteRegister: Arg1Reg] -> [Arg1Reg]. - [self concreteRegister: FPReg] -> [FPReg]. - [self concreteRegister: SPReg] -> [SPReg] }"! Item was removed: - ----- Method: CogX64Compiler>>concreteDPFPRegister: (in category 'encoding') ----- - concreteDPFPRegister: registerIndex - "Map a possibly abstract double-precision floating-point register into a concrete one. - Abstract registers (defined in CogAbstractOpcodes) are all negative. If registerIndex - is negative assume it is an abstract register. - - [1] IA-32 Intel® Architecture Software Developer's Manual Volume 2A: Instruction Set Reference, A-M" - - ^registerIndex - caseOf: { - [DPFPReg0] -> [XMM0L / 2]. - [DPFPReg1] -> [XMM1L / 2]. - [DPFPReg2] -> [XMM2L / 2]. - [DPFPReg3] -> [XMM3L / 2]. - [DPFPReg4] -> [XMM4L / 2]. - [DPFPReg5] -> [XMM5L / 2]. - [DPFPReg6] -> [XMM6L / 2]. - [DPFPReg7] -> [XMM7L / 2] } - otherwise: - [self assert: (registerIndex between: XMM0L and: XMM15L). - self assert: (registerIndex bitAnd: 1) = 0. - registerIndex / 2]! Item was changed: ----- Method: CogX64Compiler>>genMarshallNArgs:arg:arg:arg:arg: (in category 'abi') ----- genMarshallNArgs: numArgs arg: regOrConst0 arg: regOrConst1 arg: regOrConst2 arg: regOrConst3 + "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is + either a negative number, which encodes a constant, or a non-negative number, that of a register. - "Generate the code to pass up to four arguments in a C run-time call. Hack: each argument is either a - negative number, that of an abstract register, or a non-negative number, that of a constant parameter. Run-time calls have no more than four arguments, so chosen so that on ARM, where in its C ABI the first four integer arguments are passed in registers, all arguments can be passed in registers. We defer to the back end to generate this code not so much that the back end knows whether it uses the stack or registers to pass arguments (it does, but...). In fact we defer for an extremely evil reason. Doing so allows the x64 (where up to 6 args are passed) to assign the register arguments in an order that allows some of the argument registers to be used for specific abstract registers, specifically + ReceiverResultReg and ClassReg. This is evil, evil, evil, but also it's really nice to keep using the old + register assignments the original author has grown accustomed to. - ReceiverResultReg and ClassReg. This is evil, evil, evil, but also its really nice to keep using the old - register assignments the principal author has grown accustomed to. How can this possibly work? Look at Cogit class>>runtime for a list of the run-time calls and their arguments, including which arguments are passed in which registers. Look at CogX64Compiler's + subclass implementations of initializeAbstractregisters. There are no calls in which ReceiverResultReg + (RDX) and/or ClassReg (RCX) are passed along with Arg0Reg and Arg1Reg, and none in which the use of - subclass implementations of concreteRegister:. There are no calls in which ReceiverResultReg (RDX) - and/or ClassReg (RCX) are passed along with Arg0Reg and Arg1Reg, and none in which the use of either ReceiverResultReg or ClassReg conflict for args 3 & 4. So if args are assigned in order, the registers do not get overwritten. Yes, this is evil, but it's so nice to continue to use RCX & RDX." <inline: true> numArgs = 0 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst0) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst0) R: RDI] - regOrConst0 >= 0 - ifTrue: [cogit MoveCq: regOrConst0 R: RDI] ifFalse: + [regOrConst0 ~= RDI ifTrue: - [(self concreteRegister: regOrConst0) ~= RDI ifTrue: [cogit MoveR: regOrConst0 R: RDI]]. numArgs = 1 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst1) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst1) R: RSI] - regOrConst1 >= 0 - ifTrue: [cogit MoveCq: regOrConst1 R: RSI] ifFalse: + [regOrConst1 ~= RSI ifTrue: - [(self concreteRegister: regOrConst1) ~= RSI ifTrue: [cogit MoveR: regOrConst1 R: RSI]]. numArgs = 2 ifTrue: [^self]. self cppIf: ABI == #SysV ifTrue: + [(cogit isTrampolineArgConstant: regOrConst2) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: RDX] - [regOrConst2 >= 0 - ifTrue: [cogit MoveCq: regOrConst2 R: RDX] ifFalse: + [regOrConst2 ~= RDX ifTrue: - [(self concreteRegister: regOrConst2) ~= RDX ifTrue: [cogit MoveR: regOrConst2 R: RDX]]. numArgs = 3 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst3) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: RCX] - regOrConst3 >= 0 - ifTrue: [cogit MoveCq: regOrConst3 R: RCX] ifFalse: + [regOrConst3 ~= RCX ifTrue: - [(self concreteRegister: regOrConst3) ~= RCX ifTrue: [cogit MoveR: regOrConst3 R: RCX]]]. self cppIf: ABI == #MSVC ifTrue: + [(cogit isTrampolineArgConstant: regOrConst2) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: R8] - [regOrConst2 >= 0 - ifTrue: [cogit MoveCq: regOrConst2 R: R8] ifFalse: + [regOrConst2 ~= R8 ifTrue: - [(self concreteRegister: regOrConst2) ~= R8 ifTrue: [cogit MoveR: regOrConst2 R: R8]]. numArgs = 3 ifTrue: [^self]. + (cogit isTrampolineArgConstant: regOrConst3) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: R9] - regOrConst3 >= 0 - ifTrue: [cogit MoveCq: regOrConst3 R: R9] ifFalse: + [regOrConst3 ~= R9 ifTrue: - [(self concreteRegister: regOrConst3) ~= R9 ifTrue: [cogit MoveR: regOrConst3 R: R9]]]. self assert: numArgs <= 4! Item was removed: - ----- Method: CogX64CompilerForTests>>concreteRegister: (in category 'encoding') ----- - concreteRegister: value - ^value! Item was changed: ----- Method: Cogit class>>initializeMiscConstants (in category 'class initialization') ----- initializeMiscConstants super initializeMiscConstants. Debug := initializationOptions at: #Debug ifAbsent: [false]. (initializationOptions includesKey: #EagerInstructionDecoration) ifTrue: [EagerInstructionDecoration := initializationOptions at: #EagerInstructionDecoration] ifFalse: [EagerInstructionDecoration ifNil: [EagerInstructionDecoration := false]]. "speeds up single stepping but could lose fidelity" ProcessorClass := (initializationOptions at: #ISA ifAbsentPut: [self objectMemoryClass defaultISA]) caseOf: { [#X64] -> [BochsX64Alien]. [#IA32] -> [BochsIA32Alien]. [#ARMv5] -> [GdbARMAlien]. [#MIPSEL] -> [MIPSELSimulator] }. CogCompilerClass := self activeCompilerClass. + (CogCompilerClass withAllSuperclasses copyUpTo: CogAbstractInstruction) reverseDo: + [:compilerClass| compilerClass initialize; initializeAbstractRegisters]. - (CogCompilerClass withAllSuperclasses copyUpTo: CogAbstractInstruction) do: - [:compilerClass| compilerClass initialize]. "Our criterion for which methods to JIT is literal count. The default value is 60 literals or less." MaxLiteralCountForCompile := initializationOptions at: #MaxLiteralCountForCompile ifAbsent: [60]. "we special-case 0, 1 & 2 argument sends, N is numArgs >= 3" NumSendTrampolines := 4. "Currently not even the ceImplicitReceiverTrampoline contains object references." NumObjRefsInRuntime := 0. NSCSelectorIndex := (NSSendCache instVarNames indexOf: #selector) - 1. NSCNumArgsIndex := (NSSendCache instVarNames indexOf: #numArgs) - 1. NSCClassTagIndex := (NSSendCache instVarNames indexOf: #classTag) - 1. NSCEnclosingObjectIndex := (NSSendCache instVarNames indexOf: #enclosingObject) - 1. NSCTargetIndex := (NSSendCache instVarNames indexOf: #target) - 1. NumOopsPerNSC := NSSendCache instVarNames size. "Max size to alloca when compiling. Mac OS X 10.6.8 segfaults approaching 8Mb. Linux 2.6.9 segfaults above 11Mb. WIndows XP segfaults approaching 2Mb." MaxStackAllocSize := 1024 * 1024 * 3 / 2 ! Item was changed: ----- Method: Cogit>>generateSendTrampolines (in category 'initialization') ----- generateSendTrampolines 0 to: NumSendTrampolines - 1 do: [:numArgs| ordinarySendTrampolines at: numArgs put: (self genTrampolineFor: #ceSend:super:to:numArgs: called: (self trampolineName: 'ceSend' numArgs: numArgs) arg: ClassReg + arg: (self trampolineArgConstant: false) - arg: 0 arg: ReceiverResultReg arg: (self numArgsOrSendNumArgsReg: numArgs))]. "Generate these in the middle so they are within [firstSend, lastSend]." NewspeakVM ifTrue: [self generateNewspeakSendTrampolines]. BytecodeSetHasDirectedSuperSend ifTrue: [0 to: NumSendTrampolines - 1 do: [:numArgs| directedSuperSendTrampolines at: numArgs put: (self genTrampolineFor: #ceSend:above:to:numArgs: called: (self trampolineName: 'ceDirectedSuperSend' numArgs: numArgs) arg: ClassReg arg: TempReg arg: ReceiverResultReg arg: (self numArgsOrSendNumArgsReg: numArgs))]]. 0 to: NumSendTrampolines - 1 do: [:numArgs| superSendTrampolines at: numArgs put: (self genTrampolineFor: #ceSend:super:to:numArgs: called: (self trampolineName: 'ceSuperSend' numArgs: numArgs) arg: ClassReg + arg: (self trampolineArgConstant: true) - arg: 1 arg: ReceiverResultReg arg: (self numArgsOrSendNumArgsReg: numArgs))]. firstSend := ordinarySendTrampolines at: 0. lastSend := superSendTrampolines at: NumSendTrampolines - 1! Item was added: + ----- Method: Cogit>>isTrampolineArgConstant: (in category 'initialization') ----- + isTrampolineArgConstant: n + "Test for true and false and 0 to N encoded via trampolineArgConstant:" + <inline: true> + ^n < NoReg! Item was changed: ----- Method: Cogit>>numArgsOrSendNumArgsReg: (in category 'initialization') ----- numArgsOrSendNumArgsReg: numArgs "The send trampolines have different versions for different arg counts, with special cases for 0 through NumSendTrampolines - 2, and a general case for more, passing the arg count in SendNumArgsReg. This computes the relevant argument." <inline: true> + ^numArgs <= (NumSendTrampolines - 2) + ifTrue: [self trampolineArgConstant: numArgs] + ifFalse: [SendNumArgsReg]! - ^numArgs <= (NumSendTrampolines - 2) ifTrue: [numArgs] ifFalse: [SendNumArgsReg]! Item was changed: ----- Method: Cogit>>registerMaskFor: (in category 'register management') ----- registerMaskFor: reg + ^1 << reg! - "Answer a bit mask identifying the symbolic register. - Registers are negative numbers." - ^1 << (1 - reg)! Item was changed: ----- Method: Cogit>>registerMaskFor:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 + ^1 << reg1 bitOr: 1 << reg2! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^1 << (1 - reg1) bitOr: 1 << (1 - reg2)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 + ^(1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^(1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 + ^((1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3) bitOr: 1 << reg4! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^((1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)) bitOr: 1 << (1 - reg4)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 + ^(((1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3) bitOr: 1 << reg4) bitOr: 1 << reg5! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^(((1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)) bitOr: 1 << (1 - reg4)) bitOr: 1 << (1 - reg5)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and:and:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 + ^((((1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3) bitOr: 1 << reg4) bitOr: 1 << reg5) bitOr: 1 << reg6! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^((((1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)) bitOr: 1 << (1 - reg4)) bitOr: 1 << (1 - reg5)) bitOr: 1 << (1 - reg6)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and:and:and:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7 + ^(((((1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3) bitOr: 1 << reg4) bitOr: 1 << reg5) bitOr: 1 << reg6) bitOr: 1 << reg7! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^(((((1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)) bitOr: 1 << (1 - reg4)) bitOr: 1 << (1 - reg5)) bitOr: 1 << (1 - reg6)) bitOr: 1 << (1 - reg7)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and:and:and:and:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7 and: reg8 + ^((((((1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3) bitOr: 1 << reg4) bitOr: 1 << reg5) bitOr: 1 << reg6) bitOr: 1 << reg7) bitOr: 1 << reg8! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^((((((1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)) bitOr: 1 << (1 - reg4)) bitOr: 1 << (1 - reg5)) bitOr: 1 << (1 - reg6)) bitOr: 1 << (1 - reg7)) bitOr: 1 << (1 - reg8)! Item was changed: ----- Method: Cogit>>registerMaskFor:and:and:and:and:and:and:and:and: (in category 'register management') ----- registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7 and: reg8 and: reg9 + ^(((((((1 << reg1 bitOr: 1 << reg2) bitOr: 1 << reg3) bitOr: 1 << reg4) bitOr: 1 << reg5) bitOr: 1 << reg6) bitOr: 1 << reg7) bitOr: 1 << reg8) bitOr: 1 << reg9! - "Answer a bit mask identifying the symbolic registers. - Registers are negative numbers." - ^(((((((1 << (1 - reg1) bitOr: 1 << (1 - reg2)) bitOr: 1 << (1 - reg3)) bitOr: 1 << (1 - reg4)) bitOr: 1 << (1 - reg5)) bitOr: 1 << (1 - reg6)) bitOr: 1 << (1 - reg7)) bitOr: 1 << (1 - reg8)) bitOr: 1 << (1 - reg9)! Item was added: + ----- Method: Cogit>>trampolineArgConstant: (in category 'initialization') ----- + trampolineArgConstant: booleanOrInteger + "Encode true and false and 0 to N such that they can't be confused for register numbers (including NoReg) + and can be tested for by isTrampolineArgConstant: and decoded by trampolineArgValue:" + <inline: true> + self cCode: [] + inSmalltalk: [booleanOrInteger isInteger ifFalse: [^self trampolineArgConstant: (booleanOrInteger ifTrue: [1] ifFalse: [0])]]. + self assert: booleanOrInteger >= 0. + ^-2 - booleanOrInteger "0...N => -2...-(N+2)"! Item was added: + ----- Method: Cogit>>trampolineArgValue: (in category 'initialization') ----- + trampolineArgValue: n + "Decode true and false and 0 to N to their C equivalents from the encoding by trampolineArgConstant:" + <inline: true> + ^-2 - n! Item was changed: ----- Method: StackInterpreter>>printStackCallStackOf: (in category 'debug printing') ----- printStackCallStackOf: aContextOrProcessOrFrame <api> | theFP context | <var: #theFP type: #'char *'> + (self cCode: [false] "In the stack simulator, frame pointers are negative which upsets addressCouldBeObj:" + inSmalltalk: [stackPages couldBeFramePointer: aContextOrProcessOrFrame]) ifFalse: + [(objectMemory addressCouldBeObj: aContextOrProcessOrFrame) ifTrue: + [((objectMemory isContext: aContextOrProcessOrFrame) + and: [self checkIsStillMarriedContext: aContextOrProcessOrFrame currentFP: nil]) ifTrue: + [^self printStackCallStackOf: (self frameOfMarriedContext: aContextOrProcessOrFrame) asInteger]. + (self couldBeProcess: aContextOrProcessOrFrame) ifTrue: + [^self printCallStackOf: (objectMemory + fetchPointer: SuspendedContextIndex + ofObject: aContextOrProcessOrFrame)]. + ^nil]]. - (objectMemory addressCouldBeObj: aContextOrProcessOrFrame) ifTrue: - [((objectMemory isContext: aContextOrProcessOrFrame) - and: [self checkIsStillMarriedContext: aContextOrProcessOrFrame currentFP: nil]) ifTrue: - [^self printStackCallStackOf: (self frameOfMarriedContext: aContextOrProcessOrFrame) asInteger]. - (self couldBeProcess: aContextOrProcessOrFrame) ifTrue: - [^self printCallStackOf: (objectMemory - fetchPointer: SuspendedContextIndex - ofObject: aContextOrProcessOrFrame)]. - ^nil]. theFP := aContextOrProcessOrFrame asVoidPointer. [context := self shortReversePrintFrameAndCallers: theFP. ((self isMarriedOrWidowedContext: context) and: [theFP := self frameOfMarriedContext: context. self checkIsStillMarriedContext: context currentFP: theFP]) ifFalse: [^nil]] repeat! Item was added: + ----- Method: StackInterpreterSimulator>>printSends (in category 'debug printing') ----- + printSends + ^printSends! Item was added: + ----- Method: StackInterpreterSimulator>>printSends: (in category 'debug printing') ----- + printSends: aBoolean + printSends := aBoolean! Item was changed: ----- Method: StackToRegisterMappingCogit>>generateSendTrampolines (in category 'initialization') ----- generateSendTrampolines "Override to generate code to push the register arg(s) for <= numRegArg arity sends." 0 to: NumSendTrampolines - 1 do: [:numArgs| ordinarySendTrampolines at: numArgs put: (self genSendTrampolineFor: #ceSend:super:to:numArgs: numArgs: numArgs called: (self trampolineName: 'ceSend' numArgs: numArgs) arg: ClassReg + arg: (self trampolineArgConstant: false) - arg: 0 arg: ReceiverResultReg arg: (self numArgsOrSendNumArgsReg: numArgs))]. "Generate these in the middle so they are within [firstSend, lastSend]." NewspeakVM ifTrue: [self generateNewspeakSendTrampolines]. BytecodeSetHasDirectedSuperSend ifTrue: [0 to: NumSendTrampolines - 1 do: [:numArgs| directedSuperSendTrampolines at: numArgs put: (self genSendTrampolineFor: #ceSend:above:to:numArgs: numArgs: numArgs called: (self trampolineName: 'ceDirectedSuperSend' numArgs: numArgs) arg: ClassReg arg: TempReg arg: ReceiverResultReg arg: (self numArgsOrSendNumArgsReg: numArgs))]]. 0 to: NumSendTrampolines - 1 do: [:numArgs| superSendTrampolines at: numArgs put: (self genSendTrampolineFor: #ceSend:super:to:numArgs: numArgs: numArgs called: (self trampolineName: 'ceSuperSend' numArgs: numArgs) arg: ClassReg + arg: (self trampolineArgConstant: true) - arg: 1 arg: ReceiverResultReg arg: (self numArgsOrSendNumArgsReg: numArgs))]. firstSend := ordinarySendTrampolines at: 0. lastSend := superSendTrampolines at: NumSendTrampolines - 1! Item was changed: ----- Method: TSendNode>>isNonNullCCode (in category 'testing') ----- isNonNullCCode ^(#(cCode: cCode:inSmalltalk:) includes: selector) and: [arguments first isConstant + and: [arguments first value isString + and: [arguments first value notEmpty]]]! - and: [arguments first value notEmpty]]!

1 0

[commit][3546] Merge from oscog:
by commits＠squeakvm.org 19 Dec '15

19 Dec '15

Revision: 3546 Author: lewis Date: 2015-12-18 18:58:35 -0800 (Fri, 18 Dec 2015) Log Message: ----------- Merge from oscog: Revision: 3545 Author: rowledge Date: 2015-12-18 14:31:23 -0800 (Fri, 18 Dec 2015) Log Message: ----------- Add tweak to XSendEvent call that handles going fullscreen, per Nicolai Hess suggestion Modified Paths: -------------- branches/Cog/platforms/unix/vm-display-X11/sqUnixX11.c Modified Paths: -------------- trunk/platforms/unix/vm-display-X11/sqUnixX11.c Modified: trunk/platforms/unix/vm-display-X11/sqUnixX11.c =================================================================== --- trunk/platforms/unix/vm-display-X11/sqUnixX11.c 2015-12-18 22:31:23 UTC (rev 3545) +++ trunk/platforms/unix/vm-display-X11/sqUnixX11.c 2015-12-19 02:58:35 UTC (rev 3546) @@ -4030,7 +4030,7 @@ xev.xclient.data.l[0] = enable; /* 1 enable, 0 disable fullscreen */ xev.xclient.data.l[1] = fullscreen; xev.xclient.data.l[2] = 0; - XSendEvent(stDisplay, DefaultRootWindow(stDisplay), False, SubstructureNotifyMask, &xev); + XSendEvent(stDisplay, DefaultRootWindow(stDisplay), False, SubstructureRedirectMask | SubstructureNotifyMask, &xev); }

1 0

Fwd: picking up a little speed
by Robert Withers 19 Dec '15

19 Dec '15

This is without encryption. I think that is 15 MB/sec. Will video fit in that throughput? 100 KB data chunks received: 22 send time: 54 ms, rate: 325.926 Mbs. receive time: 143 ms. rate: 123.077 Mbs. regards, robert -------- Forwarded Message -------- Subject: picking up a little speed Date: Fri, 18 Dec 2015 20:09:30 -0500 From: Robert Withers <robert.w.withers(a)gmail.com> To: Pharo Development List <pharo-dev(a)lists.pharo.org> I was looking at Zinc to see how it works. My SecureSession was built without my knowing about all of Zinc and it looks delicious on the control side. Here is my latest stats: 100 KB data chunks received: 22 send time: 54 ms, rate: 325.926 Mbs. receive time: 143 ms. rate: 123.077 Mbs. -- . .. .. ^,^ robert

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2015