From avalloud at smalltalk.comcastbiz.net Wed Jun 1 01:23:08 2016 From: avalloud at smalltalk.comcastbiz.net (Andres Valloud) Date: Wed Jun 1 01:23:10 2016 Subject: [Vm-dev] Ephemerons and VM crash In-Reply-To: References: <573B3AAB.8060805@gmail.com> <573C1DCB.3040705@gmail.com> <573D70F5.2080006@gmail.com> <5742CF1C.50603@gmail.com> <5742D01D.3000708@gmail.com> <57432F5B.6020509@gmail.com> <5745A77A.7070301@gmail.com> <5746DEB7.5080109@gmail.com> <3F61EC41-71FB-4F07-B7F6-AC877091E9CD@gmail.com> Message-ID: <197c73ba-3440-15d1-d3b7-3a7eb0059cd4@smalltalk.comcastbiz.net> Yes, see the 2015 IWST paper re: Linked Weak Reference Arrays. You can download the paper using the link here: http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_15/IWST15 See also the short version: http://blogten.blogspot.com/2015/07/linked-weak-reference-arrays-paper.html Andres. On 5/28/16 10:14 , John McIntosh wrote: > > > > > Morning > > I'm curious if anyone has studied the time taken to morn & finalize a > weak object. I ask this because in my past work with VW and VA the most > interesting GC issues I tackled related to how much time finalization > took versus how long the engineer thought it might take. > > Thought on this should relate to normal processing, or situations where > the engineer is trying to force the finalization via interaction with > the GC logic. > > > > > On Thursday, 26 May 2016, Eliot Miranda > wrote: > > > > > > -- > =========================================================================== > John M. McIntosh. Corporate Smalltalk Consulting > Ltd https://www.linkedin.com/in/smalltalk > =========================================================================== > From lists at fniephaus.com Wed Jun 1 11:27:45 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed Jun 1 11:27:58 2016 Subject: [Vm-dev] `2 raisedTo: 100000000` crashes VM Message-ID: Hi all, We just found out that the VM crashes when trying to build very large integers. I'm not sure what could cause the problem... Best, Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/65ec0aa7/attachment.htm From bert at freudenbergs.de Wed Jun 1 11:43:01 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 1 11:43:06 2016 Subject: [Vm-dev] Re: `2 raisedTo: 100000000` crashes VM In-Reply-To: References: Message-ID: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> On 01.06.2016, at 13:27, Fabio Niephaus wrote: > > Hi all, > > We just found out that the VM crashes when trying to build very large integers. > I'm not sure what could cause the problem... Maybe largeIntgrowTo doesn?t check the size? Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x9b5fa572 __pthread_kill + 10 1 libsystem_pthread.dylib 0x91403654 pthread_kill + 101 2 libsystem_c.dylib 0x93dddc34 abort + 156 3 org.squeak.Squeak$(VM_MONIKER) 0x00139db9 sigsegv + 175 4 libsystem_platform.dylib 0x9e4bd79b _sigtramp + 43 5 ??? 0xffffffff 0 + 4294967295 6 org.squeak.Squeak$(VM_MONIKER) 0x00139d0a getCrashDumpFilenameInto + 82 7 org.squeak.Squeak$(VM_MONIKER) 0x00177262 largeIntgrowTo + 107 8 org.squeak.Squeak$(VM_MONIKER) 0x001771f1 normalizePositive + 190 9 org.squeak.Squeak$(VM_MONIKER) 0x0017678c primDigitMultiplyNegative + 597 10 ??? 0x04cb4cc8 0 + 80432328 11 org.squeak.Squeak$(VM_MONIKER) 0x000c203a interpret + 741 - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4207 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/77136501/smime.bin From bert at freudenbergs.de Wed Jun 1 12:29:45 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 1 12:29:50 2016 Subject: [Vm-dev] Re: 2 raisedTo: 100000000` crashes VM In-Reply-To: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> Message-ID: <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> > On 01.06.2016, at 13:43, Bert Freudenberg wrote: > > On 01.06.2016, at 13:27, Fabio Niephaus wrote: >> >> Hi all, >> >> We just found out that the VM crashes when trying to build very large integers. >> I'm not sure what could cause the problem... > > Maybe largeIntgrowTo doesn?t check the size? > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib 0x9b5fa572 __pthread_kill + 10 > 1 libsystem_pthread.dylib 0x91403654 pthread_kill + 101 > 2 libsystem_c.dylib 0x93dddc34 abort + 156 > 3 org.squeak.Squeak$(VM_MONIKER) 0x00139db9 sigsegv + 175 > 4 libsystem_platform.dylib 0x9e4bd79b _sigtramp + 43 > 5 ??? 0xffffffff 0 + 4294967295 > 6 org.squeak.Squeak$(VM_MONIKER) 0x00139d0a getCrashDumpFilenameInto + 82 > 7 org.squeak.Squeak$(VM_MONIKER) 0x00177262 largeIntgrowTo + 107 > 8 org.squeak.Squeak$(VM_MONIKER) 0x001771f1 normalizePositive + 190 > 9 org.squeak.Squeak$(VM_MONIKER) 0x0017678c primDigitMultiplyNegative + 597 > 10 ??? 0x04cb4cc8 0 + 80432328 > 11 org.squeak.Squeak$(VM_MONIKER) 0x000c203a interpret + 741 > > > - Bert - Btw it worked fine in the interpreter and Cog. - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4207 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/c46a9475/smime-0001.bin From btc at openinworld.com Wed Jun 1 13:38:04 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 1 13:38:27 2016 Subject: [Vm-dev] FoxSavedFP an friends Message-ID: Stepping through with the simulator, I see a scattering of variables FoxSavedFP, FoxCallerSavedIP, etc. The "Fox" must mean something but I can't work it out? cheers -ben From btc at openinworld.com Wed Jun 1 14:29:44 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 1 14:30:12 2016 Subject: [Vm-dev] interpreter method cache forwarding pointer checks Message-ID: Just curious if the probing of the intepreter method cache for forwarding pointers had been sorted out, per SpurMemoryManager class comment... > The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target. > (In the interpreter there needs to be a similar check when probing the method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation). cheers -ben From commits at source.squeak.org Wed Jun 1 17:01:24 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 1 17:01:26 2016 Subject: [Vm-dev] VM Maker: Cog-eem.326.mcz Message-ID: Eliot Miranda uploaded a new version of Cog to project VM Maker: http://source.squeak.org/VMMaker/Cog-eem.326.mcz ==================== Summary ==================== Name: Cog-eem.326 Author: eem Time: 1 June 2016, 10:00:55.448579 am UUID: 6590c3f6-5226-4bfe-8ab1-5ba2b3871f7e Ancestors: Cog-tpr.325 Be more accurate in smashing caller-saved registers on ARMv6. =============== Diff against Cog-tpr.325 =============== Item was changed: ----- Method: GdbARMAlien>>smashABICallerSavedRegistersWithValuesFrom:by: (in category 'accessing-abstract') ----- smashABICallerSavedRegistersWithValuesFrom: base by: step "limited list of registers to clear out when simulating an ABI call. Smash neither R0 nor R1 since many abi calls return 2 results or a 64-bit dual-reg value. LR has to be left alone becasue a leaf call doesn't push it." + #(r2: r3: r9: r12:) withIndexDo: - #(r2: r3:) withIndexDo: [:accessor :index| self perform: accessor with: index - 1 * step + base]! Item was changed: ----- Method: GdbARMAlien>>smashCallerSavedRegistersWithValuesFrom:by: (in category 'accessing-abstract') ----- smashCallerSavedRegistersWithValuesFrom: base by: step + #(r0: r1: r2: r3: r9: r12: lr:) withIndexDo: - #(r0: r1: r2: r3: lr:) withIndexDo: [:accessor :index| self perform: accessor with: index - 1 * step + base]! From eliot.miranda at gmail.com Wed Jun 1 17:43:24 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 1 17:43:27 2016 Subject: [Vm-dev] Amazing ARM simulator experience Message-ID: Hi All, just had to tell people about this morning's experience using the ARM simulator. I've been building Smalltalk VMs since 1983, so 33 years. My first on the Three Rivers PERQ was dog slow. My undergraduate project was done the the National Semiconductor 32016 based Whitechapel Computer Works workstation and its and 32032-based successor. This morning I was revamping register management in Cog's ARMv5/v6 back end, making more registers available by using two of the C argument registers for two of registers the Cogit assigns to various fixed tasks, and using store and load multiple instructions to save and restore concisely the registers around calls into the runtime. Remember the architecture here. The simulator generates ARM machine code into the ByteArray that re[resents the address space, holding all of generated machine code, a small C stack, and the Smalltalk heap. A plugin, derived from Gdb's ARM simulator written in C, interprets that machine code, running for a couple of milliseconds at a time in a loop, applying breakpoint calculations, and asserts on every call into the run-time, and that calls into the run-time and accesses of variables in the simulator is done by using illegal addresses in the generated machine code. Each illegal access causes the Gdb-derived machine code interpreter to return with an error, this error is turned into an exception, the handler for which maps the specific illegal address into a variable or message selector, accesses the variable or activates the message selector, providing the result, and allowing the execution to continue. In changing the register management I had a test case that worked, an image that prompted for an expression ands evaluated it, which worked both in the simulator and with the generated VM. But the real VM, crashed when used on a proper image. So to debug I started launching the real interactive image in the simulator. Well, the amazing experience is that that image, whose machine code is being _interpreted by a C program_ feels /faster/ than my 32016 based implementation back in 1984-ish. Quite amazing. I can open windows, type text, access source code (was playing with Message Names) etc. It's sluggish, but usable. Amazing how fast modern machines are. All on my 2012 vintage 2.2 Ghz Core i7 MacBook Pro. I'm blown away :-) _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/640bdba3/attachment.htm From eliot.miranda at gmail.com Wed Jun 1 17:45:47 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 1 17:45:48 2016 Subject: [Vm-dev] Re: [squeak-dev] Re: 2 raisedTo: 100000000` crashes VM In-Reply-To: <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> Message-ID: On Wed, Jun 1, 2016 at 5:29 AM, Bert Freudenberg wrote: > > > On 01.06.2016, at 13:43, Bert Freudenberg wrote: > > > > On 01.06.2016, at 13:27, Fabio Niephaus wrote: > >> > >> Hi all, > >> > >> We just found out that the VM crashes when trying to build very large > integers. > >> I'm not sure what could cause the problem... > > > > Maybe largeIntgrowTo doesn?t check the size? > > > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > > 0 libsystem_kernel.dylib 0x9b5fa572 __pthread_kill + 10 > > 1 libsystem_pthread.dylib 0x91403654 pthread_kill + 101 > > 2 libsystem_c.dylib 0x93dddc34 abort + 156 > > 3 org.squeak.Squeak$(VM_MONIKER) 0x00139db9 sigsegv + 175 > > 4 libsystem_platform.dylib 0x9e4bd79b _sigtramp + 43 > > 5 ??? 0xffffffff 0 + 4294967295 > > 6 org.squeak.Squeak$(VM_MONIKER) 0x00139d0a > getCrashDumpFilenameInto + 82 > > 7 org.squeak.Squeak$(VM_MONIKER) 0x00177262 largeIntgrowTo + 107 > > 8 org.squeak.Squeak$(VM_MONIKER) 0x001771f1 normalizePositive + 190 > > 9 org.squeak.Squeak$(VM_MONIKER) 0x0017678c > primDigitMultiplyNegative + 597 > > 10 ??? 0x04cb4cc8 0 + 80432328 > > 11 org.squeak.Squeak$(VM_MONIKER) 0x000c203a interpret + 741 > > > > > > - Bert - > > > Btw it worked fine in the interpreter and Cog. > So which VM does it fail on? > > - Bert - > > > > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/f08bb3c0/attachment.htm From eliot.miranda at gmail.com Wed Jun 1 17:48:21 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 1 17:48:23 2016 Subject: [Vm-dev] FoxSavedFP an friends In-Reply-To: References: Message-ID: On Wed, Jun 1, 2016 at 6:38 AM, Ben Coman wrote: > > Stepping through with the simulator, I see a scattering of variables > FoxSavedFP, FoxCallerSavedIP, etc. > > The "Fox" must mean something but I can't work it out? > Frame Offset indeX > cheers -ben > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/254c7ebc/attachment-0001.htm From eliot.miranda at gmail.com Wed Jun 1 17:52:41 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 1 17:52:44 2016 Subject: [Vm-dev] interpreter method cache forwarding pointer checks In-Reply-To: References: Message-ID: Hi Ben, On Wed, Jun 1, 2016 at 7:29 AM, Ben Coman wrote: > > Just curious if the probing of the intepreter method cache for > forwarding pointers had been sorted out, per SpurMemoryManager class > comment... > > > The inline cache failure code is then responsible for following the > forwarding pointer chain (these are Iliffe vectors :) ) and resolving to > the actual target. > > > (In the interpreter there needs to be a similar check when probing the > method cache). It has yet to be determined exactly how this is done (e.g. > change the receiver register and/or stack contents and retry the send, > perhaps scanning the current activation). > In the StackInterpeter look at internalFindNewMethodOrdinary and under which circumstances it sends handleForwardedSelectorFaultFor: and handleForwardedSendFaultForTag:. In the Cogit look at ceSICMiss: (code entry Single Inline Cache miss) and under which circumstances it sends ceSendFromInLineCacheMiss:. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/bbbc7b10/attachment.htm From commits at source.squeak.org Wed Jun 1 19:04:05 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 1 19:04:06 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1876.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1876.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1876 Author: eem Time: 1 June 2016, 12:02:13.056404 pm UUID: 28e91d90-4197-436d-9702-7c7dae02e85e Ancestors: VMMaker.oscog-cb.1875 Eliminate the callerSavedRegMask variable and replace it with a CallerSavedRegisterMask variable computed at register initialization time. On ARM: - define the caller-saved registers as the subset of the caller-saved registers that excludes R0/CArg0Reg/TempReg & R1/CArg1Reg (R0 is the C result register), and use R2 & R3 for abstract registers (ClassReg and Arg0Reg). - save and restore elements of the caller-saved registers as appropriate around run-time calls. - use LDM & STM to do the saving. - hence provide two extra registers, now provinding Extra[012]Reg Fix the various nameForRegister: to get a useful printRegisterMap on RISCs that have register arguments in the C calling convention (x64 & ARM). In the simulator, provide the same breakpoiting facilities for "click step" in ABI calls as for run-time calls, and have prntCogMethodFor: print something useful for trampoline addresses.. =============== Diff against VMMaker.oscog-cb.1875 =============== Item was changed: CogAbstractInstruction subclass: #CogARMCompiler instanceVariableNames: 'conditionOrNil' + classVariableNames: 'AL AddOpcode AndOpcode BicOpcode CArg0Reg CArg1Reg CArg2Reg CArg3Reg CC CMPSMULL CPSRReg CS CmpNotOpcode CmpOpcode ConcreteIPReg ConcretePCReg ConcreteVarBaseReg D0 D1 D2 D3 D4 D5 D6 D7 EQ GE GT HI LDMFD LE LR LS LT MI MRS MSR MoveNotOpcode MoveOpcode NE OrOpcode OverflowFlag PC PL PopLDM PushSTM R0 R1 R10 R11 R12 R2 R3 R4 R5 R6 R7 R8 R9 RsbOpcode SMLALOpcode SMULL SP STMFD SubOpcode TstOpcode VC VS XorOpcode' - classVariableNames: 'AL AddOpcode AndOpcode BicOpcode CArg0Reg CArg1Reg CArg2Reg CArg3Reg CC CMPSMULL CPSRReg CS CmpNotOpcode CmpOpcode ConcreteIPReg ConcretePCReg ConcreteVarBaseReg D0 D1 D2 D3 D4 D5 D6 D7 EQ GE GT HI LDMFD LE LR LS LT MI MRS MSR MoveNotOpcode MoveOpcode NE OrOpcode OverflowFlag PC PL R0 R1 R10 R11 R12 R2 R3 R4 R5 R6 R7 R8 R9 RsbOpcode SMLALOpcode SMULL SP STMFD SubOpcode TstOpcode VC VS XorOpcode' poolDictionaries: '' category: 'VMMaker-JIT'! !CogARMCompiler commentStamp: 'lw 8/23/2012 19:38' prior: 0! I generate ARM instructions from CogAbstractInstructions. For reference see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.architecture/index.html The Architecture Reference Manual used is that of version 5, which includes some version 6 instructions. Of those, only pld is used(for PrefetchAw). This class does not take any special action to flush the instruction cache on instruction-modification.! Item was changed: ----- Method: CogARMCompiler class>>initialize (in category 'class initialization') ----- initialize "Initialize various ARM instruction-related constants." "CogARMCompiler initialize" super initialize. self ~~ CogARMCompiler ifTrue: [^self]. "ARM general registers" R0 := 0. R1 := 1. R2 := 2. R3 := 3. R4 := 4. R5 := 5. R6 := 6. R7 := 7. R8 := 8. R9 := 9. R10 := 10. R11 := 11. R12 := 12. SP := 13. LR := 14. PC := 15. "ARM VFP Double precision floating point registers" D0 := 0. D1 := 1. D2 := 2. D3 := 3. D4 := 4. D5 := 5. D6 := 6. D7 := 7. CArg0Reg := 0. CArg1Reg := 1. CArg2Reg := 2. CArg3Reg := 3. ConcreteVarBaseReg := 10. ConcreteIPReg := 12. "IP, The Intra-Procedure-call scratch register." ConcretePCReg := 15. "Condition Codes. Note that cc=16rF is NOT ALLOWED as a condition; it specifies an extension instruction. See e.g.ARM_ARM v5 DDI01001.pdf A3.2.1" EQ := 0. NE := 1. CS := 2. CC := 3. MI := 4. PL := 5. VS := 6. VC := 7. HI := 8. LS := 9. GE := 10. LT := 11. GT := 12. LE := 13. AL := 14. "Table A3-2 in sec A3.4 Data-processing instructions of the AARM." AddOpcode := 4. AndOpcode := 0. BicOpcode := 14. CmpOpcode := 10. CmpNotOpcode := 11. MoveOpcode := 13. MoveNotOpcode := 15. OrOpcode := 12. RsbOpcode := 3. SMLALOpcode := 7. SubOpcode := 2. TstOpcode := 8. XorOpcode := 1. CPSRReg := 16. OverflowFlag := 1 << 28. "Specific instructions" self + initializeSpecificOpcodes: #(SMULL MSR MRS PopLDM PushSTM LDMFD STMFD CMPSMULL) - initializeSpecificOpcodes: #(SMULL MSR MRS LDMFD STMFD CMPSMULL) in: thisContext method! Item was changed: ----- 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.." - super initializeAbstractRegisters. + "According to IHI0042E ARM Architecture Procedure Calling Standard, in section 5.1.1: + A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6). + SP = r13, so the callee-saved regs are r4-r8 & r10-r12. + The caller-saved registers are those that are not callee-saved and not reserved for hardware/abi uses, + i..e r0-r3, r9 & r12. + We exclude registers 0 & 1 (TempReg/CArg0Reg & CArg1Reg) from the CallerSavedRegisterMask because we only + use them for argument passing and so never want to save and restore them. In fact restoring TempReg/CArg0Reg + would overwrite function results, so it shouldn't be included under any circumstances." + + CallerSavedRegisterMask := self registerMaskFor: "0 and: 1 and:" 2 and: 3 and: 9 and: 12. + TempReg := R0. + ClassReg := R2. + ReceiverResultReg := R5. - ClassReg := R8. - ReceiverResultReg := R7. SendNumArgsReg := R6. SPReg := SP. "a.k.a. R13" self assert: SP = 13. FPReg := R11. + Arg0Reg := R3. "overlaps with last C arg reg" + Arg1Reg := R4. + Extra0Reg := R7. + Extra1Reg := R8. + Extra2Reg := R9. - Arg0Reg := R4. - Arg1Reg := R5. - Extra0Reg := R9. VarBaseReg := R10. "Must be callee saved" self assert: ConcreteVarBaseReg = R10. RISCTempReg := R12. "a.k.a. IP" self assert: ConcreteIPReg = R12. LinkReg := LR. "R14" PCReg := PC. "R15" DPFPReg0 := D0. DPFPReg1 := D1. DPFPReg2 := D2. DPFPReg3 := D3. DPFPReg4 := D4. DPFPReg5 := D5. DPFPReg6 := D6. + DPFPReg7 := D7! - DPFPReg7 := D7 - ! Item was changed: ----- Method: CogARMCompiler>>availableRegisterOrNoneFor: (in category 'register allocation') ----- availableRegisterOrNoneFor: liveRegsMask "Answer an unused abstract register in the liveRegMask. Subclasses with more registers can override to answer them. N.B. Do /not/ allocate TempReg." (cogit register: Extra0Reg isInMask: liveRegsMask) ifFalse: [^Extra0Reg]. + (cogit register: Extra1Reg isInMask: liveRegsMask) ifFalse: + [^Extra1Reg]. + (cogit register: Extra2Reg isInMask: liveRegsMask) ifFalse: + [^Extra2Reg]. ^super availableRegisterOrNoneFor: liveRegsMask! Item was removed: - ----- Method: CogARMCompiler>>callerSavedRegisterMask (in category 'accessing') ----- - callerSavedRegisterMask - "According to IHI0042E ARM Architecture Procedure Calling Standard, in section 5.1.1: - A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6). - SP = r13, so the callee-saved regs are r4-r8 & r10-r12. - The caller-saved registers are those that are not callee-saved and not reserved for hardware/abi uses, - i..e r0-r3, r9 & r12." - ^cogit registerMaskFor: 0 and: 1 and: 2 and: 3 and: 9 and: 12! Item was added: + ----- Method: CogARMCompiler>>canPushPopMultipleRegisters (in category 'testing') ----- + canPushPopMultipleRegisters + + ^true! Item was changed: ----- Method: CogARMCompiler>>computeMaximumSize (in category 'generate machine code') ----- computeMaximumSize "Because we don't use Thumb, each ARM instruction has 4 bytes. Many abstract opcodes need more than one instruction. Instructions that refer to constants and/or literals depend on literals being stored in-line or out-of-line. N.B. The ^N forms are to get around the bytecode compiler's long branch limits which are exceeded when each case jumps around the otherwise." opcode caseOf: { "Noops & Pseudo Ops" [Label] -> [^0]. [Literal] -> [^4]. [AlignmentNops] -> [^(operands at: 0) - 4]. [Fill32] -> [^4]. [Nop] -> [^4]. "Control" [Call] -> [^4]. [CallFull] -> [^self literalLoadInstructionBytes + 4]. [JumpR] -> [^4]. [Jump] -> [^4]. [JumpFull] -> [^self literalLoadInstructionBytes + 4]. [JumpLong] -> [^4]. [JumpZero] -> [^4]. [JumpNonZero] -> [^4]. [JumpNegative] -> [^4]. [JumpNonNegative] -> [^4]. [JumpOverflow] -> [^4]. [JumpNoOverflow] -> [^4]. [JumpCarry] -> [^4]. [JumpNoCarry] -> [^4]. [JumpLess] -> [^4]. [JumpGreaterOrEqual] -> [^4]. [JumpGreater] -> [^4]. [JumpLessOrEqual] -> [^4]. [JumpBelow] -> [^4]. [JumpAboveOrEqual] -> [^4]. [JumpAbove] -> [^4]. [JumpBelowOrEqual] -> [^4]. [JumpLongZero] -> [^4]. [JumpLongNonZero] -> [^4]. [JumpFPEqual] -> [^8]. [JumpFPNotEqual] -> [^8]. [JumpFPLess] -> [^8]. [JumpFPGreaterOrEqual]-> [^8]. [JumpFPGreater] -> [^8]. [JumpFPLessOrEqual] -> [^8]. [JumpFPOrdered] -> [^8]. [JumpFPUnordered] -> [^8]. [RetN] -> [^(operands at: 0) = 0 ifTrue: [4] ifFalse: [8]]. [Stop] -> [^4]. "Arithmetic" [AddCqR] -> [^self rotateable8bitSignedImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [AndCqR] -> [^self rotateable8bitBitwiseImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes = 4 ifTrue: [8] ifFalse: [1 << (operands at: 0) highBit = ((operands at: 0) + 1) ifTrue: [8] ifFalse: [self literalLoadInstructionBytes + 4]]]]. [AndCqRR] -> [^self rotateable8bitBitwiseImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes = 4 ifTrue: [8] ifFalse: [1 << (operands at: 0) highBit = ((operands at: 0) + 1) ifTrue: [8] ifFalse: [self literalLoadInstructionBytes + 4]]]]. [CmpCqR] -> [^self rotateable8bitSignedImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [OrCqR] -> [^self rotateable8bitImmediate: (operands at: 0) ifTrue: [:r :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [SubCqR] -> [^self rotateable8bitSignedImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [TstCqR] -> [^self rotateable8bitImmediate: (operands at: 0) ifTrue: [:r :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [XorCqR] -> [^self rotateable8bitBitwiseImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes = 4 ifTrue: [8] ifFalse: [1 << (operands at: 0) highBit = ((operands at: 0) + 1) ifTrue: [8] ifFalse: [self literalLoadInstructionBytes + 4]]]]. [AddCwR] -> [^self literalLoadInstructionBytes + 4]. [AndCwR] -> [^self literalLoadInstructionBytes + 4]. [CmpCwR] -> [^self literalLoadInstructionBytes + 4]. [OrCwR] -> [^self literalLoadInstructionBytes + 4]. [SubCwR] -> [^self literalLoadInstructionBytes + 4]. [XorCwR] -> [^self literalLoadInstructionBytes + 4]. [AddRR] -> [^4]. [AndRR] -> [^4]. [CmpRR] -> [^4]. [OrRR] -> [^4]. [XorRR] -> [^4]. [SubRR] -> [^4]. [NegateR] -> [^4]. [LoadEffectiveAddressMwrR] -> [^self rotateable8bitImmediate: (operands at: 0) ifTrue: [:r :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [LogicalShiftLeftCqR] -> [^4]. [LogicalShiftRightCqR] -> [^4]. [ArithmeticShiftRightCqR] -> [^4]. [LogicalShiftLeftRR] -> [^4]. [LogicalShiftRightRR] -> [^4]. [ArithmeticShiftRightRR] -> [^4]. [AddRdRd] -> [^4]. [CmpRdRd] -> [^4]. [SubRdRd] -> [^4]. [MulRdRd] -> [^4]. [DivRdRd] -> [^4]. [SqrtRd] -> [^4]. "ARM Specific Arithmetic" [SMULL] -> [^4]. [MSR] -> [^4]. [CMPSMULL] -> [^4]. "special compare for genMulR:R: usage" + "ARM Specific Data Movement" + [PopLDM] -> [^4]. + [PushSTM] -> [^4]. "Data Movement" [MoveCqR] -> [^self literalLoadInstructionBytes = 4 ifTrue: [self literalLoadInstructionBytes] ifFalse: [self rotateable8bitBitwiseImmediate: (operands at: 0) ifTrue: [:r :i :n| 4] ifFalse: [self literalLoadInstructionBytes]]]. [MoveCwR] -> [^self literalLoadInstructionBytes = 4 ifTrue: [self literalLoadInstructionBytes] ifFalse: [(self inCurrentCompilation: (operands at: 0)) ifTrue: [4] ifFalse: [self literalLoadInstructionBytes]]]. [MoveRR] -> [^4]. [MoveRdRd] -> [^4]. [MoveAwR] -> [^(self isAddressRelativeToVarBase: (operands at: 0)) ifTrue: [4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveRAw] -> [^(self isAddressRelativeToVarBase: (operands at: 1)) ifTrue: [4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveAbR] -> [^(self isAddressRelativeToVarBase: (operands at: 0)) ifTrue: [4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveRAb] -> [^(self isAddressRelativeToVarBase: (operands at: 1)) ifTrue: [4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveRMwr] -> [^self is12BitValue: (operands at: 1) ifTrue: [:u :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveRdM64r] -> [^self literalLoadInstructionBytes + 4]. [MoveMbrR] -> [^self is12BitValue: (operands at: 0) ifTrue: [:u :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveRMbr] -> [^self is12BitValue: (operands at: 1) ifTrue: [:u :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveRM16r] -> [^self is12BitValue: (operands at: 1) ifTrue: [:u :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveM16rR] -> [^self rotateable8bitImmediate: (operands at: 0) ifTrue: [:r :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveM64rRd] -> [^self literalLoadInstructionBytes + 4]. [MoveMwrR] -> [^self is12BitValue: (operands at: 0) ifTrue: [:u :i| 4] ifFalse: [self literalLoadInstructionBytes + 4]]. [MoveXbrRR] -> [^4]. [MoveRXbrR] -> [^4]. [MoveXwrRR] -> [^4]. [MoveRXwrR] -> [^4]. [PopR] -> [^4]. [PushR] -> [^4]. [PushCw] -> [^self literalLoadInstructionBytes = 4 ifTrue: [self literalLoadInstructionBytes + 4] ifFalse: [(self inCurrentCompilation: (operands at: 0)) ifTrue: [8] ifFalse: [self rotateable8bitBitwiseImmediate: (operands at: 0) ifTrue: [:r :i :n| 8] ifFalse: [self literalLoadInstructionBytes + 4]]]]. [PushCq] -> [^self literalLoadInstructionBytes = 4 ifTrue: [self literalLoadInstructionBytes + 4] ifFalse: [self rotateable8bitBitwiseImmediate: (operands at: 0) ifTrue: [:r :i :n| 8] ifFalse: [self literalLoadInstructionBytes + 4]]]. [PrefetchAw] -> [^(self isAddressRelativeToVarBase: (operands at: 0)) ifTrue: [4] ifFalse: [self literalLoadInstructionBytes + 4]]. "Conversion" [ConvertRRd] -> [^8]. }. ^0 "to keep C compiler quiet" ! Item was added: + ----- Method: CogARMCompiler>>concretizePushOrPopMultipleRegisters: (in category 'generate machine code - concretize') ----- + concretizePushOrPopMultipleRegisters: doPush + self assert: (operands at: 0) ~= 0. + machineCode at: 0 put: AL << 28 + + (doPush "2r100PUSWL" + ifTrue: [2r10010010 << 20] + ifFalse: [2r10001011 << 20]) + + (SP << 16) + + (operands at: 0). + ^machineCodeSize := 4! Item was changed: ----- Method: CogARMCompiler>>dispatchConcretize (in category 'generate machine code') ----- dispatchConcretize "Attempt to generate concrete machine code for the instruction at address. This is the inner dispatch of concretizeAt: actualAddress which exists only to get around the branch size limits in the SqueakV3 (blue book derived) bytecode set." conditionOrNil ifNotNil: [self concretizeConditionalInstruction. ^self]. opcode caseOf: { "Noops & Pseudo Ops" [Label] -> [^self concretizeLabel]. [Literal] -> [^self concretizeLiteral]. [AlignmentNops] -> [^self concretizeAlignmentNops]. [Fill32] -> [^self concretizeFill32]. [Nop] -> [^self concretizeNop]. "Control" [Call] -> [^self concretizeCall]. "call code within code space" [CallFull] -> [^self concretizeCallFull]. "call code anywhere in address space" [JumpR] -> [^self concretizeJumpR]. [JumpFull] -> [^self concretizeJumpFull]."jump within address space" [JumpLong] -> [^self concretizeConditionalJump: AL]."jumps witihn code space" [JumpLongZero] -> [^self concretizeConditionalJump: EQ]. [JumpLongNonZero] -> [^self concretizeConditionalJump: NE]. [Jump] -> [^self concretizeConditionalJump: AL]. [JumpZero] -> [^self concretizeConditionalJump: EQ]. [JumpNonZero] -> [^self concretizeConditionalJump: NE]. [JumpNegative] -> [^self concretizeConditionalJump: MI]. [JumpNonNegative] -> [^self concretizeConditionalJump: PL]. [JumpOverflow] -> [^self concretizeConditionalJump: VS]. [JumpNoOverflow] -> [^self concretizeConditionalJump: VC]. [JumpCarry] -> [^self concretizeConditionalJump: CS]. [JumpNoCarry] -> [^self concretizeConditionalJump: CC]. [JumpLess] -> [^self concretizeConditionalJump: LT]. [JumpGreaterOrEqual] -> [^self concretizeConditionalJump: GE]. [JumpGreater] -> [^self concretizeConditionalJump: GT]. [JumpLessOrEqual] -> [^self concretizeConditionalJump: LE]. [JumpBelow] -> [^self concretizeConditionalJump: CC]. "unsigned lower" [JumpAboveOrEqual] -> [^self concretizeConditionalJump: CS]. "unsigned greater or equal" [JumpAbove] -> [^self concretizeConditionalJump: HI]. [JumpBelowOrEqual] -> [^self concretizeConditionalJump: LS]. [JumpFPEqual] -> [^self concretizeFPConditionalJump: EQ]. [JumpFPNotEqual] -> [^self concretizeFPConditionalJump: NE]. [JumpFPLess] -> [^self concretizeFPConditionalJump: LT]. [JumpFPGreaterOrEqual] -> [^self concretizeFPConditionalJump: GE]. [JumpFPGreater] -> [^self concretizeFPConditionalJump: GT]. [JumpFPLessOrEqual] -> [^self concretizeFPConditionalJump: LE]. [JumpFPOrdered] -> [^self concretizeFPConditionalJump: VC]. [JumpFPUnordered] -> [^self concretizeFPConditionalJump: VS]. [RetN] -> [^self concretizeRetN]. [Stop] -> [^self concretizeStop]. "Arithmetic" [AddCqR] -> [^self concretizeNegateableDataOperationCqR: AddOpcode]. [AndCqR] -> [^self concretizeInvertibleDataOperationCqR: AndOpcode]. [AndCqRR] -> [^self concretizeAndCqRR]. [CmpCqR] -> [^self concretizeNegateableDataOperationCqR: CmpOpcode]. [OrCqR] -> [^self concretizeDataOperationCqR: OrOpcode]. [SubCqR] -> [^self concretizeSubCqR]. [TstCqR] -> [^self concretizeTstCqR]. [XorCqR] -> [^self concretizeInvertibleDataOperationCqR: XorOpcode]. [AddCwR] -> [^self concretizeDataOperationCwR: AddOpcode]. [AndCwR] -> [^self concretizeDataOperationCwR: AndOpcode]. [CmpCwR] -> [^self concretizeDataOperationCwR: CmpOpcode]. [OrCwR] -> [^self concretizeDataOperationCwR: OrOpcode]. [SubCwR] -> [^self concretizeDataOperationCwR: SubOpcode]. [XorCwR] -> [^self concretizeDataOperationCwR: XorOpcode]. [AddRR] -> [^self concretizeDataOperationRR: AddOpcode]. [AndRR] -> [^self concretizeDataOperationRR: AndOpcode]. [CmpRR] -> [^self concretizeDataOperationRR: CmpOpcode]. [OrRR] -> [^self concretizeDataOperationRR: OrOpcode]. [SubRR] -> [^self concretizeDataOperationRR: SubOpcode]. [XorRR] -> [^self concretizeDataOperationRR: XorOpcode]. [AddRdRd] -> [^self concretizeAddRdRd]. [CmpRdRd] -> [^self concretizeCmpRdRd]. [DivRdRd] -> [^self concretizeDivRdRd]. [MulRdRd] -> [^self concretizeMulRdRd]. [SubRdRd] -> [^self concretizeSubRdRd]. [SqrtRd] -> [^self concretizeSqrtRd]. [NegateR] -> [^self concretizeNegateR]. [LoadEffectiveAddressMwrR] -> [^self concretizeLoadEffectiveAddressMwrR]. [ArithmeticShiftRightCqR] -> [^self concretizeArithmeticShiftRightCqR]. [LogicalShiftRightCqR] -> [^self concretizeLogicalShiftRightCqR]. [LogicalShiftLeftCqR] -> [^self concretizeLogicalShiftLeftCqR]. [ArithmeticShiftRightRR] -> [^self concretizeArithmeticShiftRightRR]. [LogicalShiftLeftRR] -> [^self concretizeLogicalShiftLeftRR]. [LogicalShiftRightRR] -> [^self concretizeLogicalShiftRightRR]. "ARM Specific Arithmetic" [SMULL] -> [^self concretizeSMULL] . [CMPSMULL] -> [^self concretizeCMPSMULL]. [MSR] -> [^self concretizeMSR]. + "ARM Specific Data Movement" + [PopLDM] -> [^self concretizePushOrPopMultipleRegisters: false]. + [PushSTM] -> [^self concretizePushOrPopMultipleRegisters: true]. "Data Movement" [MoveCqR] -> [^self concretizeMoveCqR]. [MoveCwR] -> [^self concretizeMoveCwR]. [MoveRR] -> [^self concretizeMoveRR]. [MoveAwR] -> [^self concretizeMoveAwR]. [MoveRAw] -> [^self concretizeMoveRAw]. [MoveAbR] -> [^self concretizeMoveAbR]. [MoveRAb] -> [^self concretizeMoveRAb]. [MoveMbrR] -> [^self concretizeMoveMbrR]. [MoveRMbr] -> [^self concretizeMoveRMbr]. [MoveRM16r] -> [^self concretizeMoveRM16r]. [MoveM16rR] -> [^self concretizeMoveM16rR]. [MoveM64rRd] -> [^self concretizeMoveM64rRd]. [MoveMwrR] -> [^self concretizeMoveMwrR]. [MoveXbrRR] -> [^self concretizeMoveXbrRR]. [MoveRXbrR] -> [^self concretizeMoveRXbrR]. [MoveXwrRR] -> [^self concretizeMoveXwrRR]. [MoveRXwrR] -> [^self concretizeMoveRXwrR]. [MoveRMwr] -> [^self concretizeMoveRMwr]. [MoveRdM64r] -> [^self concretizeMoveRdM64r]. [PopR] -> [^self concretizePopR]. [PushR] -> [^self concretizePushR]. [PushCq] -> [^self concretizePushCq]. [PushCw] -> [^self concretizePushCw]. [PrefetchAw] -> [^self concretizePrefetchAw]. "Conversion" [ConvertRRd] -> [^self concretizeConvertRRd]}! Item was changed: ----- Method: CogARMCompiler>>genDivR:R:Quo:Rem: (in category 'abstract instructions') ----- genDivR: abstractRegDivisor R: abstractRegDividend Quo: abstractRegQuotient Rem: abstractRegRemainder "Currently no instruction level support for divide on ARM. See also #canDivQuoRem" | rDividend rDivisor rQuotient rRemainder divRemFunctionAddr | self assert: abstractRegDividend ~= abstractRegDivisor. self assert: abstractRegQuotient ~= abstractRegRemainder. rDividend := abstractRegDividend. rDivisor := abstractRegDivisor. + rDividend = CArg0Reg ifFalse: + ["we need to move the value in rDividend to CArg0Reg. Best to double check if rDivisor is already using it first" + rDivisor = CArg0Reg ifTrue: "oh dear; we also need to move rDivisor's value out of the way first.. I'll move it to CArg1Reg and if some nitwit has managed to put rDividend there they deserve the crash" + [rDividend = CArg1Reg ifTrue: + [self error: 'register choices in genDivR:R:Quo:Rem: made life impossible']. - rDividend = CArg0Reg ifFalse:[ - "we need to move the value in rDividend to CArg0Reg. Best to double check if rDivisor is already using it first" - rDivisor = CArg0Reg ifTrue:[ "oh dear; we also need to move rDivisor's value out of the way first.. I'll move it to CArg1Reg and if some nitwit has managed to put rDividend there they deserve the crash" - rDividend = CArg1Reg ifTrue:[self error: 'register choices in genDivR:R:Quo:Rem: made life impossible']. cogit MoveR: rDivisor R: CArg1Reg. "and update rDivisor or we get buggerd by the next clause" rDivisor := CArg1Reg]. + cogit MoveR: rDividend R: CArg0Reg]. + rDivisor = CArg1Reg ifFalse: + [cogit MoveR: rDivisor R: CArg1Reg]. - cogit MoveR: rDividend R: CArg0Reg. - ]. - rDivisor = CArg1Reg ifFalse:[ - cogit MoveR: rDivisor R: CArg1Reg]. divRemFunctionAddr := self aeabiDivModFunctionAddr. cogit backEnd saveAndRestoreLinkRegAround: [cogit CallFullRT: (self cCode: [divRemFunctionAddr asUnsignedInteger] + inSmalltalk: [cogit simulatedTrampolineFor: divRemFunctionAddr]) + registersToBeSavedMask: (cogit registerMaskFor: CArg2Reg and: CArg3Reg)]. - inSmalltalk: [cogit simulatedTrampolineFor: divRemFunctionAddr])]. "Now we need to move the r0/1 results back to rQuotient & rRemainder" rQuotient := abstractRegQuotient. rRemainder := abstractRegRemainder. + rQuotient = CArg0Reg ifFalse: "oh good grief, not again" + [cogit MoveR: CArg0Reg R: rQuotient. + rQuotient = CArg1Reg ifTrue: + [self error: 'register choices in genDivR:R:Quo:Rem: made life impossible'] ]. + rRemainder = CArg1Reg ifFalse: + [cogit MoveR: CArg1Reg R: rRemainder] - rQuotient = CArg0Reg ifFalse:["oh good grief, not again" - cogit MoveR: CArg0Reg R: rQuotient. - rQuotient = CArg1Reg ifTrue:[self error: 'register choices in genDivR:R:Quo:Rem: made life impossible'] ]. - rRemainder = CArg1Reg ifFalse:[ - cogit MoveR: CArg1Reg R: rRemainder]. - ! Item was added: + ----- Method: CogARMCompiler>>genPopRegisterMask: (in category 'generate machine code') ----- + genPopRegisterMask: registersToBeSavedMask + + ^registersToBeSavedMask = 0 + ifTrue: [cogit Label] + ifFalse: [cogit gen: PopLDM operand: registersToBeSavedMask]! Item was added: + ----- Method: CogARMCompiler>>genPushRegisterMask: (in category 'generate machine code') ----- + genPushRegisterMask: registersToBeSavedMask + + ^registersToBeSavedMask = 0 + ifTrue: [cogit Label] + ifFalse: [cogit gen: PushSTM operand: registersToBeSavedMask]! Item was changed: ----- Method: CogARMCompiler>>genRestoreRegs: (in category 'abi') ----- genRestoreRegs: regMask + "Restore the registers in regMask as saved by genSaveRegs:." + + ^self genPopRegisterMask: regMask! - "Restore the registers in regMask as saved by genSaveRegs:. - Restore none, because the ARM ABI only defines callee saved registers, no caller-saved regs." - ^0! Item was changed: ----- Method: CogARMCompiler>>genSaveRegs: (in category 'abi') ----- genSaveRegs: regMask + "Save the registers in regMask for a call into the C run-time from a trampoline" + + ^self genPushRegisterMask: regMask! - "Save the registers in regMask 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." - ^0! Item was changed: ----- Method: CogARMCompiler>>generalPurposeRegisterMap (in category 'disassembly') ----- generalPurposeRegisterMap "Answer a Dictionary from register getter to register index." ^Dictionary newFromPairs: { #r0. R0. + #r1. R1. + #r2. R2. + #r3. R3. #r4. R4. #r5. R5. #r6. R6. #r7. R7. #r8. R8. + #r9. R9. #r10. R10. #r11. R11. #r12. R12 }! Item was changed: ----- Method: CogARMCompiler>>nameForRegister: (in category 'printing') ----- nameForRegister: reg "" + | default | + default := super nameForRegister: reg. + ^default last = $? + ifTrue: + [#(LR SP PC CArg0Reg CArg0Reg CArg1Reg CArg2Reg CArg3Reg) + detect: [:sym| (thisContext method methodClass classPool at: sym) = reg] + ifNone: [default]] + ifFalse: + [default]! - reg < 0 ifTrue: - [^super nameForRegister: reg]. - ^#(LR SP PC CArg0Reg CArg0Reg CArg1Reg CArg2Reg CArg3Reg) - detect: [:sym| (thisContext method methodClass classPool at: sym) = reg] - ifNone: [super nameForRegister: reg]! Item was changed: ----- Method: CogAbstractInstruction class>>initializeAbstractRegisters (in category 'class initialization') ----- initializeAbstractRegisters + "Assign the abstract registers with the identities/indices of the relevant concrete registers, + and assign CallerSavedRegisterMask appropriately. - "Assign the abstract registers with the identities/indices of the relevant concrete registers. First set all abstract registers to #undefined via CogAbstractRegisters initialize, and then, each subclasses assigns the subset they choose with values of specific concrete registers." + CallerSavedRegisterMask := #undefined. CogAbstractRegisters initialize! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor: (in category 'register management') ----- + registerMaskFor: reg + ^Cogit basicNew registerMaskFor: reg! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor:and: (in category 'register management') ----- + registerMaskFor: reg1 and: reg2 + ^Cogit basicNew registerMaskFor: reg1 and: reg2! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor:and:and: (in category 'register management') ----- + registerMaskFor: reg1 and: reg2 and: reg3 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor:and:and:and: (in category 'register management') ----- + registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor:and:and:and:and: (in category 'register management') ----- + registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor:and:and:and:and:and: (in category 'register management') ----- + registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6! Item was added: + ----- Method: CogAbstractInstruction class>>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 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7! Item was added: + ----- Method: CogAbstractInstruction class>>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 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7 and: reg8! Item was added: + ----- Method: CogAbstractInstruction class>>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 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7 and: reg8 and: reg9! Item was added: + ----- Method: CogAbstractInstruction class>>registerMaskFor:and: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 and: reg10 + ^Cogit basicNew registerMaskFor: reg1 and: reg2 and: reg3 and: reg4 and: reg5 and: reg6 and: reg7 and: reg8 and: reg9 and: reg10! Item was removed: - ----- Method: CogAbstractInstruction>>callerSavedRegisterMask (in category 'accessing') ----- - callerSavedRegisterMask - "Answer an abstract register mask as computed by StackToRegisterMappingCogit registerMaskFor:" - self subclassResponsibility! Item was added: + ----- Method: CogAbstractInstruction>>canPushPopMultipleRegisters (in category 'testing') ----- + canPushPopMultipleRegisters + + ^false! Item was changed: SharedPool subclass: #CogAbstractRegisters instanceVariableNames: '' + classVariableNames: 'Arg0Reg Arg1Reg CallerSavedRegisterMask ClassReg DPFPReg0 DPFPReg1 DPFPReg10 DPFPReg11 DPFPReg12 DPFPReg13 DPFPReg14 DPFPReg15 DPFPReg2 DPFPReg3 DPFPReg4 DPFPReg5 DPFPReg6 DPFPReg7 DPFPReg8 DPFPReg9 Extra0Reg Extra1Reg Extra2Reg Extra3Reg Extra4Reg Extra5Reg Extra6Reg Extra7Reg FPReg LinkReg NoReg PCReg RISCTempReg ReceiverResultReg SPReg SendNumArgsReg TempReg VarBaseReg' - classVariableNames: 'Arg0Reg Arg1Reg ClassReg DPFPReg0 DPFPReg1 DPFPReg10 DPFPReg11 DPFPReg12 DPFPReg13 DPFPReg14 DPFPReg15 DPFPReg2 DPFPReg3 DPFPReg4 DPFPReg5 DPFPReg6 DPFPReg7 DPFPReg8 DPFPReg9 Extra0Reg Extra1Reg Extra2Reg Extra3Reg Extra4Reg Extra5Reg Extra6Reg Extra7Reg FPReg LinkReg NoReg PCReg RISCTempReg ReceiverResultReg SPReg SendNumArgsReg TempReg VarBaseReg' poolDictionaries: '' category: 'VMMaker-JIT'! !CogAbstractRegisters commentStamp: 'eem 12/26/2015 14:06' prior: 0! I am a pool for the abstract register set that the Cogit uses to define its model of Smalltalk compiled to machine code.! Item was changed: ----- Method: CogAbstractRegisters class>>nameForRegister: (in category 'debug printing') ----- nameForRegister: reg "" ^#(Arg0Reg Arg1Reg ClassReg FPReg ReceiverResultReg SPReg SendNumArgsReg TempReg LinkReg RISCTempReg VarBaseReg PCReg + Extra0Reg Extra1Reg Extra2Reg Extra3Reg Extra4Reg Extra5Reg) - Scratch0Reg Scratch1Reg Scratch2Reg Scratch3Reg Scratch4Reg Scratch5Reg) detect: [:sym| (classPool at: sym) = reg] ifNone: ['REG', reg printString, '?']! Item was changed: ----- Method: CogIA32Compiler class>>initializeAbstractRegisters (in category 'class initialization') ----- initializeAbstractRegisters "Assign the abstract registers with the identities/indices of the relevant concrete registers." + super initializeAbstractRegisters. + "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." + CallerSavedRegisterMask := self registerMaskFor: EAX and: ECX and: EDX. - super initializeAbstractRegisters. TempReg := EAX. ClassReg := ECX. ReceiverResultReg := EDX. SendNumArgsReg := EBX. SPReg := ESP. FPReg := EBP. Arg0Reg := ESI. Arg1Reg := EDI. DPFPReg0 := XMM0L. DPFPReg1 := XMM1L. DPFPReg2 := XMM2L. DPFPReg3 := XMM3L. DPFPReg4 := XMM4L. DPFPReg5 := XMM5L. DPFPReg6 := XMM6L. DPFPReg7 := XMM7L! Item was removed: - ----- Method: CogIA32Compiler>>callerSavedRegisterMask (in category 'accessing') ----- - callerSavedRegisterMask - ^cogit registerMaskFor: EAX and: ECX and: EDX! Item was changed: ----- 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." super initializeAbstractRegisters. + self flag: #OABI. + CallerSavedRegisterMask := self + registerMaskFor: T0 and: T1 and: T2 and: T3 + and: T4 and: T5 and: T6 and: T7 and: T8 and: T9. + 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. self flag: #todo. "Extra0Reg := ??. Extra1Reg := ??. Extra2Reg := ??. Extra3Reg := ??. Extra4Reg := ??. Extra5Reg := ??. Extra6Reg := ??. Extra7Reg := ??." self flag: #todo. "DPFPReg0 := ??. DPFPReg1 := ??. DPFPReg2 := ??. DPFPReg3 := ??. DPFPReg4 := ??. DPFPReg5 := ??. DPFPReg6 := ??. DPFPReg7 := ??. DPFPReg8 := ??. DPFPReg9 := ??. DPFPReg10 := ??. DPFPReg11 := ??. DPFPReg12 := ??. DPFPReg13 := ??. DPFPReg14 := ??. DPFPReg15 := ??"! Item was removed: - ----- Method: CogMIPSELCompiler>>callerSavedRegisterMask (in category 'accessing') ----- - callerSavedRegisterMask - "Volatile" - "See MIPSConstants initializeRegisters." - self flag: #OABI. - ^cogit - registerMaskFor: T0 - and: T1 - and: T2 - and: T3 - and: T4 - and: T5 - and: T6 - and: T7 - and: T8 - and: T9! Item was changed: ----- Method: CogMIPSELCompiler>>nameForRegister: (in category 'printing') ----- nameForRegister: reg "" - reg < 0 ifTrue: [^super nameForRegister: reg]. ^MIPSConstants nameForRegister: reg! Item was changed: ----- Method: CogObjectRepresentationForSpur>>genGetActiveContextLarge:inBlock: (in category 'initialization') ----- genGetActiveContextLarge: isLarge inBlock: isInBlock "Create a trampoline to answer the active context that will answer it if a frame is already married, and create it otherwise. Assume numArgs is in SendNumArgsReg and ClassReg is free." | header slotSize jumpSingle loopHead jumpNeedScavenge continuation exit | cogit "load the flag; stash it in both TempReg & ClassReg; do the compare (a prime candidated for use of AndCq:R:R:)" MoveMw: FoxMethod r: FPReg R: ClassReg; AndCq: MFMethodFlagHasContextFlag R: ClassReg R: TempReg. jumpSingle := cogit JumpZero: 0. "jump if flag bit not set" cogit "since the flag bit was set, get the context in the receiver reg and return" MoveMw: FoxThisContext r: FPReg R: ReceiverResultReg; RetN: 0. jumpSingle jmpTarget: cogit Label. "OK, it doesn't exist; instantiate and initialize it" "set the hasContext flag; See CoInterpreter class>>initializeFrameIndices" cogit OrCq: MFMethodFlagHasContextFlag R: ClassReg; MoveR: ClassReg Mw: FoxMethod r: FPReg. "now get the home CogMethod into ClassReg and save for post-instantiation." isInBlock ifTrue: [cogit SubCq: 3 R: ClassReg; "-3 is -(hasContext+isBlock) flags" MoveM16: 0 r: ClassReg R: TempReg; SubR: TempReg R: ClassReg] ifFalse: [cogit SubCq: 1 R: ClassReg]. "-1 is hasContext flag" "instantiate the context..." slotSize := isLarge ifTrue: [LargeContextSlots] ifFalse: [SmallContextSlots]. header := objectMemory headerForSlots: slotSize format: objectMemory indexablePointersFormat classIndex: ClassMethodContextCompactIndex. self flag: #endianness. cogit MoveAw: objectMemory freeStartAddress R: ReceiverResultReg. self genStoreHeader: header intoNewInstance: ReceiverResultReg using: TempReg. cogit MoveR: ReceiverResultReg R: TempReg; AddCq: (objectMemory smallObjectBytesForSlots: slotSize) R: TempReg; MoveR: TempReg Aw: objectMemory freeStartAddress; CmpCq: objectMemory getScavengeThreshold R: TempReg. jumpNeedScavenge := cogit JumpAboveOrEqual: 0. "Now initialize the fields of the context. See CoInterpreter>>marryFrame:SP:copyTemps:" "sender gets frame pointer as a SmallInteger" continuation := cogit MoveR: FPReg R: TempReg. self genSetSmallIntegerTagsIn: TempReg. cogit MoveR: TempReg Mw: objectMemory baseHeaderSize + (SenderIndex * objectMemory bytesPerOop) r: ReceiverResultReg. "pc gets frame caller as a SmallInteger" cogit MoveMw: FoxSavedFP r: FPReg R: TempReg. self genSetSmallIntegerTagsIn: TempReg. cogit MoveR: TempReg Mw: objectMemory baseHeaderSize + (InstructionPointerIndex * objectMemory bytesPerOop) r: ReceiverResultReg. "Set the method field, freeing up ClassReg again, and frame's context field," cogit MoveMw: (cogit offset: CogMethod of: #methodObject) r: ClassReg R: TempReg; MoveR: TempReg Mw: objectMemory baseHeaderSize + (MethodIndex * objectMemory wordSize) r: ReceiverResultReg; MoveR: ReceiverResultReg Mw: FoxThisContext r: FPReg. "Now compute stack pointer; this is stackPointer (- 1 for return pc if a CISC) - framePointer - wordSize (1 each for saved pc, method, context, receiver) + 1 (1-relative) + numArgs" "TPR note - the code here is actually doing context stackPointer := ((((fp - sp) / wordSize) - [3|4]) + num args) asSmallInteger" cogit MoveR: FPReg R: TempReg; SubR: SPReg R: TempReg; LogicalShiftRightCq: self log2BytesPerWord R: TempReg; SubCq: (cogit backEnd hasLinkRegister ifTrue: [3] ifFalse: [4]) R: TempReg; AddR: SendNumArgsReg R: TempReg. self genConvertIntegerToSmallIntegerInReg: TempReg. cogit MoveR: TempReg Mw: objectMemory baseHeaderSize + (StackPointerIndex * objectMemory bytesPerOop) r: ReceiverResultReg. "Set closureOrNil to either the stacked receiver or nil" isInBlock ifTrue: [cogit MoveR: SendNumArgsReg R: TempReg; AddCq: 2 R: TempReg; "+2 for saved fp and saved pc" MoveXwr: TempReg R: FPReg R: TempReg] ifFalse: [cogit genMoveNilR: TempReg]. cogit MoveR: TempReg Mw: objectMemory baseHeaderSize + (ClosureIndex * objectMemory bytesPerOop) r: ReceiverResultReg. "Set the receiver" cogit MoveMw: FoxMFReceiver r: FPReg R: TempReg; MoveR: TempReg Mw: objectMemory baseHeaderSize + (ReceiverIndex * objectMemory bytesPerOop) r: ReceiverResultReg. "Now copy the arguments. This is tricky because of the shortage of registers,. ClassReg ranges from 1 to numArgs (SendNumArgsReg), and from ReceiverIndex + 1 to ReceiverIndex + numArgs. 1 to: numArgs do: [:i| temp := longAt(FPReg + ((SendNumArgs - i + 2) * wordSize)). +2 for saved pc and savedfp longAtput(FPReg + FoxMFReceiver + (i * wordSize), temp)]" "TPR note: this is a prime candidate for passing off to the backend to do at least faintly optimal code" cogit MoveCq: 1 R: ClassReg. loopHead := cogit CmpR: SendNumArgsReg R: ClassReg. exit := cogit JumpGreater: 0. cogit MoveR: SendNumArgsReg R: TempReg; SubR: ClassReg R: TempReg; AddCq: 2 R: TempReg; "+2 for saved fp and saved pc" MoveXwr: TempReg R: FPReg R: TempReg; AddCq: ReceiverIndex + (objectMemory baseHeaderSize / objectMemory wordSize) R: ClassReg; "Now convert ClassReg from frame index to context index" MoveR: TempReg Xwr: ClassReg R: ReceiverResultReg; SubCq: ReceiverIndex + (objectMemory baseHeaderSize / objectMemory wordSize) - 1 R: ClassReg; "convert back adding 1 ;-)" Jump: loopHead. exit jmpTarget: cogit Label. "Finally nil or copy the non-argument temps. ClassReg := FPReg + FoxMFReceiver. SendNumArgsReg := SendNumArgsReg+ReceiverIndex. [ClassReg := ClassReg - wordSize. backEnd hasLinkRegister ifTrue: [ClassReg > SPReg] ifFalse: [ClassReg >= SPReg]] whileTrue: [receiver[SendNumArgsReg] := *ClassReg. SendNumArgsReg := SendNumArgsReg + 1]]" coInterpreter marryFrameCopiesTemps ifFalse: [cogit MoveCq: objectMemory nilObject R: TempReg]. cogit MoveR: FPReg R: ClassReg; AddCq: FoxMFReceiver R: ClassReg; AddCq: ReceiverIndex + 1 + (objectMemory baseHeaderSize / objectMemory wordSize) R: SendNumArgsReg. loopHead := cogit SubCq: objectMemory wordSize R: ClassReg. cogit CmpR: SPReg R: ClassReg. "If on a CISC there's a retpc for the trampoline call on top of stack; if on a RISC there isn't." exit := cogit backEnd hasLinkRegister ifTrue: [cogit JumpBelow: 0] ifFalse: [cogit JumpBelowOrEqual: 0]. coInterpreter marryFrameCopiesTemps ifTrue: [cogit MoveMw: 0 r: ClassReg R: TempReg]. cogit MoveR: TempReg Xwr: SendNumArgsReg R: ReceiverResultReg; AddCq: 1 R: SendNumArgsReg; Jump: loopHead. exit jmpTarget: cogit Label. cogit RetN: 0. jumpNeedScavenge jmpTarget: cogit Label. cogit backEnd saveAndRestoreLinkRegAround: + [cogit + CallRT: ceScheduleScavengeTrampoline + registersToBeSavedMask: (cogit registerMaskFor: ReceiverResultReg and: SendNumArgsReg and: ClassReg)]. - [cogit CallRT: ceScheduleScavengeTrampoline]. cogit Jump: continuation. ^0! Item was changed: ----- Method: CogObjectRepresentationForSpur>>genStoreCheckTrampoline (in category 'initialization') ----- genStoreCheckTrampoline | jumpSC | CheckRememberedInTrampoline ifTrue: [cogit zeroOpcodeIndex. jumpSC := self genCheckRememberedBitOf: ReceiverResultReg scratch: cogit backEnd cResultRegister. self assert: jumpSC opcode = JumpNonZero. jumpSC opcode: JumpZero. cogit RetN: 0. jumpSC jmpTarget: cogit Label]. ^cogit genTrampolineFor: #remember: called: 'ceStoreCheckTrampoline' numArgs: 1 arg: ReceiverResultReg arg: nil arg: nil arg: nil + regsToSave: (CallerSavedRegisterMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) - regsToSave: (cogit callerSavedRegMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) pushLinkReg: true resultReg: cogit returnRegForStoreCheck appendOpcodes: CheckRememberedInTrampoline! Item was changed: ----- Method: CogObjectRepresentationForSpur>>generateObjectRepresentationTrampolines (in category 'initialization') ----- generateObjectRepresentationTrampolines "Do the store check. Answer the argument for the benefit of the code generator; ReceiverResultReg may be caller-saved and hence smashed by this call. Answering it allows the code generator to reload ReceiverResultReg cheaply. In Spur the only thing we leave to the run-time is adding the receiver to the remembered set and setting its isRemembered bit." self cppIf: IMMUTABILITY ifTrue: [self cCode: [] inSmalltalk: [ceStoreTrampolines := CArrayAccessor on: (Array new: NumStoreTrampolines)]. 0 to: NumStoreTrampolines - 1 do: [:instVarIndex | ceStoreTrampolines at: instVarIndex put: (self genStoreTrampolineCalled: (cogit trampolineName: 'ceStoreTrampoline' numArgs: instVarIndex limit: NumStoreTrampolines - 2) instVarIndex: instVarIndex)]]. ceStoreCheckTrampoline := self genStoreCheckTrampoline. ceStoreCheckContextReceiverTrampoline := self genStoreCheckContextReceiverTrampoline. ceScheduleScavengeTrampoline := cogit genTrampolineFor: #ceScheduleScavenge called: 'ceScheduleScavengeTrampoline' + regsToSave: CallerSavedRegisterMask. - regsToSave: cogit callerSavedRegMask. ceSmallActiveContextInMethodTrampoline := self genActiveContextTrampolineLarge: false inBlock: false called: 'ceSmallMethodContext'. ceSmallActiveContextInBlockTrampoline := self genActiveContextTrampolineLarge: false inBlock: true called: 'ceSmallBlockContext'. ceLargeActiveContextInMethodTrampoline := self genActiveContextTrampolineLarge: true inBlock: false called: 'ceLargeMethodContext'. ceLargeActiveContextInBlockTrampoline := self genActiveContextTrampolineLarge: true inBlock: true called: 'ceLargeBlockContext'! Item was changed: ----- Method: CogObjectRepresentationForSqueakV3>>generateObjectRepresentationTrampolines (in category 'initialization') ----- generateObjectRepresentationTrampolines "Do the store check. Answer the argument for the benefit of the code generator; ReceiverResultReg may be caller-saved and hence smashed by this call. Answering it allows the code generator to reload ReceiverResultReg cheaply." ceStoreCheckTrampoline := cogit genTrampolineFor: #ceStoreCheck: called: 'ceStoreCheckTrampoline' arg: ReceiverResultReg + regsToSave: (CallerSavedRegisterMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) - regsToSave: (cogit callerSavedRegMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) result: cogit returnRegForStoreCheck. ceCreateNewArrayTrampoline := cogit genTrampolineFor: #ceNewArraySlotSize: called: 'ceCreateNewArrayTrampoline' arg: SendNumArgsReg + regsToSave: (CallerSavedRegisterMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) - regsToSave: (cogit callerSavedRegMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) result: ReceiverResultReg. cePositive32BitIntegerTrampoline := cogit genTrampolineFor: #positive32BitIntegerFor: called: 'cePositive32BitIntegerTrampoline' arg: ReceiverResultReg + regsToSave: (CallerSavedRegisterMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) - regsToSave: (cogit callerSavedRegMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) result: TempReg. ceActiveContextTrampoline := self genActiveContextTrampoline. ceClosureCopyTrampoline := cogit genTrampolineFor: #ceClosureCopyDescriptor: called: 'ceClosureCopyTrampoline' arg: SendNumArgsReg + regsToSave: (CallerSavedRegisterMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) - regsToSave: (cogit callerSavedRegMask bitClear: (cogit registerMaskFor: ReceiverResultReg)) result: ReceiverResultReg! Item was changed: ----- Method: CogX64Compiler 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" - AMD64 Architecture Processor Supplement + super initializeAbstractRegisters. + + "N.B. RAX RCX & RDX are caller-save (scratch) registers. Hence we use RCX for class and RDX for - 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." + CallerSavedRegisterMask := self + registerMaskFor: RAX + and: RCX + and: RDX + and: RSI + and: RDI + and: R8 + and: R9 + and: R10 + and: R11. - super initializeAbstractRegisters. 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" "R8 is either RISCTempReg or Extra6Reg depending on subclass." Extra0Reg := R10. Extra1Reg := R11. Extra2Reg := R12. Extra3Reg := R13. Extra4Reg := R14. Extra5Reg := R15. DPFPReg0 := XMM0L. DPFPReg1 := XMM1L. DPFPReg2 := XMM2L. DPFPReg3 := XMM3L. DPFPReg4 := XMM4L. DPFPReg5 := XMM5L. DPFPReg6 := XMM6L. DPFPReg7 := XMM7L. DPFPReg8 := XMM8L. DPFPReg9 := XMM9L. DPFPReg10 := XMM10L. DPFPReg11 := XMM11L. DPFPReg12 := XMM12L. DPFPReg13 := XMM13L. DPFPReg14 := XMM14L. DPFPReg15 := XMM15L! Item was removed: - ----- Method: CogX64Compiler>>callerSavedRegisterMask (in category 'accessing') ----- - callerSavedRegisterMask - "See e.g. Figure 3.4 Register Usage in - System V Application Binary Interface - AMD64 Architecture Processor Supplement - N.B. We are playing fast and loose here being processor-specific. - Soon enough this needs to be OS-specific." - ^cogit - registerMaskFor: RAX - and: RCX - and: RDX - and: RSI - and: RDI - and: R8 - and: R9 - and: R10 - and: R11! 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. 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. 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 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. Argument registers for args 0 to 3 in SysV are RDI RSI RDX RCX, and in Win64 are RDI RSI R8 R9" numArgs = 0 ifTrue: [^self]. (cogit isTrampolineArgConstant: regOrConst0) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst0) R: RDI] "a.k.a. Arg0Reg" - ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst0) R: RDI] ifFalse: [regOrConst0 ~= RDI ifTrue: [cogit MoveR: regOrConst0 R: RDI]]. numArgs = 1 ifTrue: [^self]. (cogit isTrampolineArgConstant: regOrConst1) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst1) R: RSI] "a.k.a. Arg1Reg" - ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst1) R: RSI] ifFalse: [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] "a.k.a. ReceiverResultReg" - ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: RDX] ifFalse: [regOrConst2 ~= RDX ifTrue: [cogit MoveR: regOrConst2 R: RDX]]. numArgs = 3 ifTrue: [^self]. (cogit isTrampolineArgConstant: regOrConst3) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: RCX] "a.k.a. ClassReg" - ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: RCX] ifFalse: [regOrConst3 ~= RCX ifTrue: [cogit MoveR: regOrConst3 R: RCX]]]. + self cppIf: ABI == #MSVC ifTrue: "completely untested..." - self cppIf: ABI == #MSVC ifTrue: [(cogit isTrampolineArgConstant: regOrConst2) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: R8] "a.k.a. RISCTempReg in CogInLineLiteralsX64Compiler and Extra6Reg in CogOutOfLineLiteralsX64Compiler" - ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst2) R: R8] ifFalse: [regOrConst2 ~= R8 ifTrue: [cogit MoveR: regOrConst2 R: R8]]. numArgs = 3 ifTrue: [^self]. (cogit isTrampolineArgConstant: regOrConst3) + ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: R9] "a.k.a. SendNumArgsReg" - ifTrue: [cogit MoveCq: (cogit trampolineArgValue: regOrConst3) R: R9] ifFalse: [regOrConst3 ~= R9 ifTrue: [cogit MoveR: regOrConst3 R: R9]]]. self assert: numArgs <= 4! Item was changed: ----- Method: CogX64Compiler>>nameForRegister: (in category 'printing') ----- nameForRegister: reg "" + | default | + default := super nameForRegister: reg. + ^(default last = $? + and: [reg between: 0 and: 15]) + ifTrue: [#(RAX RCX RDX RBX RSP RBP RSI RDI R8 R9 R10 R11 R12 R13 R14 R15) at: reg + 1] + ifFalse: [default]! - (reg between: 0 and: 15) ifTrue: - [^#(RAX RCX RDX RBX RSP RBP RSI RDI R8 R9 R10 R11 R12 R13 R14 R15) at: reg + 1]. - ^super nameForRegister: reg! Item was changed: CogClass subclass: #Cogit + instanceVariableNames: 'coInterpreter objectMemory objectRepresentation processor threadManager methodZone methodZoneBase codeBase minValidCallAddress lastNInstructions simulatedAddresses simulatedTrampolines simulatedVariableGetters simulatedVariableSetters printRegisters printInstructions compilationTrace clickConfirm breakPC breakBlock singleStep guardPageSize traceFlags traceStores breakMethod methodObj enumeratingCogMethod methodHeader initialPC endPC methodOrBlockNumArgs inBlock needsFrame hasYoungReferent primitiveIndex backEnd literalsManager postCompileHook methodLabel stackCheckLabel blockEntryLabel blockEntryNoContextSwitch blockNoContextSwitchOffset stackOverflowCall sendMiss missOffset entryPointMask checkedEntryAlignment uncheckedEntryAlignment cmEntryOffset entry cmNoCheckEntryOffset noCheckEntry fullBlockEntry cbEntryOffset fullBlockNoContextSwitchEntry cbNoSwitchEntryOffset picMNUAbort picInterpretAbort endCPICCase0 endCPICCase1 firstCPICCaseOffset cPICCaseSize cPICEndSize closedPICSize openPICSize fixups abstractOpcodes generatorTable byte0 byte1 byte2 byte3 bytecodePC bytecodeSetOffset opcodeIndex numAbstractOpcodes blockStarts blockCount labelCounter cStackAlignment expectedSPAlignment expectedFPAlignment codeModified maxLitIndex ceMethodAbortTrampoline cePICAbortTrampoline ceCheckForInterruptTrampoline ceCPICMissTrampoline ceReturnToInterpreterTrampoline ceBaseFrameReturnTrampoline ceSendMustBeBooleanAddTrueTrampoline ceSendMustBeBooleanAddFalseTrampoline ceCannotResumeTrampoline ceEnterCogCodePopReceiverReg ceCallCogCodePopReceiverReg ceCallCogCodePopReceiverAndClassRegs cePrimReturnEnterCogCode cePrimReturnEnterCogCodeProfiling ceNonLocalReturnTrampoline ceFetchContextInstVarTrampoline ceStoreContextInstVarTrampoline ceEnclosingObjectTrampoline ceFlushICache ceCheckFeaturesFunction ceTraceLinkedSendTrampoline ceTraceBlockActivationTrampoline ceTraceStoreTrampoline ceGetFP ceGetSP ceCaptureCStackPointers ordinarySendTrampolines superSendTrampolines directedSuperSendTrampolines dynamicSuperSendTrampolines outerSendTrampolines selfSendTrampolines firstSend lastSend realCEEnterCogCodePopReceiverReg realCECallCogCodePopReceiverReg realCECallCogCodePopReceiverAndClassRegs trampolineTableIndex trampolineAddresses objectReferencesInRuntime runtimeObjectRefIndex cFramePointerInUse debugPrimCallStackOffset ceTryLockVMOwner ceUnlockVMOwner extA extB tempOop numIRCs indexOfIRC theIRCs implicitReceiverSendTrampolines cogMethodSurrogateClass cogBlockMethodSurrogateClass nsSendCacheSurrogateClass CStackPointer CFramePointer cPICPrototype cPICEndOfCodeOffset cPICEndOfCodeLabel maxCPICCases debugBytecodePointers debugOpcodeIndices disassemblingMethod' - instanceVariableNames: 'coInterpreter objectMemory objectRepresentation processor threadManager methodZone methodZoneBase codeBase minValidCallAddress lastNInstructions simulatedAddresses simulatedTrampolines simulatedVariableGetters simulatedVariableSetters printRegisters printInstructions compilationTrace clickConfirm breakPC breakBlock singleStep guardPageSize traceFlags traceStores breakMethod methodObj enumeratingCogMethod methodHeader initialPC endPC methodOrBlockNumArgs inBlock needsFrame hasYoungReferent primitiveIndex backEnd literalsManager callerSavedRegMask postCompileHook methodLabel stackCheckLabel blockEntryLabel blockEntryNoContextSwitch blockNoContextSwitchOffset stackOverflowCall sendMiss missOffset entryPointMask checkedEntryAlignment uncheckedEntryAlignment cmEntryOffset entry cmNoCheckEntryOffset noCheckEntry fullBlockEntry cbEntryOffset fullBlockNoContextSwitchEntry cbNoSwitchEntryOffset picMNUAbort picInterpretAbort endCPICCase0 endCPICCase1 firstCPICCaseOffset cPICCaseSize cPICEndSize closedPICSize openPICSize fixups abstractOpcodes generatorTable byte0 byte1 byte2 byte3 bytecodePC bytecodeSetOffset opcodeIndex numAbstractOpcodes blockStarts blockCount labelCounter cStackAlignment expectedSPAlignment expectedFPAlignment codeModified maxLitIndex ceMethodAbortTrampoline cePICAbortTrampoline ceCheckForInterruptTrampoline ceCPICMissTrampoline ceReturnToInterpreterTrampoline ceBaseFrameReturnTrampoline ceSendMustBeBooleanAddTrueTrampoline ceSendMustBeBooleanAddFalseTrampoline ceCannotResumeTrampoline ceEnterCogCodePopReceiverReg ceCallCogCodePopReceiverReg ceCallCogCodePopReceiverAndClassRegs cePrimReturnEnterCogCode cePrimReturnEnterCogCodeProfiling ceNonLocalReturnTrampoline ceFetchContextInstVarTrampoline ceStoreContextInstVarTrampoline ceEnclosingObjectTrampoline ceFlushICache ceCheckFeaturesFunction ceTraceLinkedSendTrampoline ceTraceBlockActivationTrampoline ceTraceStoreTrampoline ceGetFP ceGetSP ceCaptureCStackPointers ordinarySendTrampolines superSendTrampolines directedSuperSendTrampolines dynamicSuperSendTrampolines outerSendTrampolines selfSendTrampolines firstSend lastSend realCEEnterCogCodePopReceiverReg realCECallCogCodePopReceiverReg realCECallCogCodePopReceiverAndClassRegs trampolineTableIndex trampolineAddresses objectReferencesInRuntime runtimeObjectRefIndex cFramePointerInUse debugPrimCallStackOffset ceTryLockVMOwner ceUnlockVMOwner extA extB tempOop numIRCs indexOfIRC theIRCs implicitReceiverSendTrampolines cogMethodSurrogateClass cogBlockMethodSurrogateClass nsSendCacheSurrogateClass CStackPointer CFramePointer cPICPrototype cPICEndOfCodeOffset cPICEndOfCodeLabel maxCPICCases debugBytecodePointers debugOpcodeIndices disassemblingMethod' classVariableNames: 'AltBlockCreationBytecodeSize AltFirstSpecialSelector AltNSSendIsPCAnnotated AltNumSpecialSelectors AnnotationConstantNames AnnotationShift AnnotationsWithBytecodePCs BlockCreationBytecodeSize Debug DisplacementMask DisplacementX2N EagerInstructionDecoration FirstAnnotation FirstSpecialSelector HasBytecodePC IsAbsPCReference IsAnnotationExtension IsDirectedSuperSend IsDisplacementX2N IsNSDynamicSuperSend IsNSImplicitReceiverSend IsNSSelfSend IsNSSendCall IsObjectReference IsRelativeCall IsSendCall IsSuperSend MapEnd MaxCompiledPrimitiveIndex MaxStackAllocSize MaxX2NDisplacement NSCClassTagIndex NSCEnclosingObjectIndex NSCNumArgsIndex NSCSelectorIndex NSCTargetIndex NSSendIsPCAnnotated NeedsFixupFlag NumObjRefsInRuntime NumOopsPerNSC NumSpecialSelectors NumTrampolines ProcessorClass' poolDictionaries: 'CogAbstractRegisters CogCompilationConstants CogMethodConstants CogRTLOpcodes VMBasicConstants VMBytecodeConstants VMObjectIndices VMStackFrameOffsets' category: 'VMMaker-JIT'! Cogit class instanceVariableNames: 'generatorTable primitiveTable'! !Cogit commentStamp: 'eem 4/6/2015 15:56' prior: 0! I am the code generator for the Cog VM. My job is to produce machine code versions of methods for faster execution and to manage inline caches for faster send performance. I can be tested in the current image using my class-side in-image compilation facilities. e.g. try StackToRegisterMappingCogit genAndDis: (Integer >> #benchFib) I have concrete subclasses that implement different levels of optimization: SimpleStackBasedCogit is the simplest code generator. StackToRegisterMappingCogit is the current production code generator It defers pushing operands to the stack until necessary and implements a register-based calling convention for low-arity sends. StackToRegisterMappingCogit is an experimental code generator with support for counting conditional branches, intended to support adaptive optimization. coInterpreter the VM's interpreter with which I cooperate methodZoneManager the manager of the machine code zone objectRepresentation the object used to generate object accesses processor the simulator that executes the IA32/x86 machine code I generate when simulating execution in Smalltalk simulatedTrampolines MessageSend> the dictionary mapping trap jump addresses to run-time routines used to warp from simulated machine code in to the Smalltalk run-time. simulatedVariableGetters MessageSend> the dictionary mapping trap read addresses to variables in run-time objects used to allow simulated machine code to read variables in the Smalltalk run-time. simulatedVariableSetters MessageSend> the dictionary mapping trap write addresses to variables in run-time objects used to allow simulated machine code to write variables in the Smalltalk run-time. printRegisters printInstructions clickConfirm flags controlling debug printing and code simulation breakPC machine code pc breakpoint cFramePointer cStackPointer the variables representing the C stack & frame pointers, which must change on FFI callback and return selectorOop the oop of the methodObj being compiled methodObj the bytecode method being compiled initialPC endPC the start and end pcs of the methodObj being compiled methodOrBlockNumArgs argument count of current method or block being compiled needsFrame whether methodObj or block needs a frame to execute primitiveIndex primitive index of current method being compiled methodLabel label for the method header blockEntryLabel label for the start of the block dispatch code stackOverflowCall label for the call of ceStackOverflow in the method prolog sendMissCall label for the call of ceSICMiss in the method prolog entryOffset offset of method entry code from start (header) of method entry label for the first instruction of the method entry code noCheckEntryOffset offset of the start of a method proper (after the method entry code) from start (header) of method noCheckEntry label for the first instruction of start of a method proper fixups > the labels for forward jumps that will be fixed up when reaching the relevant bytecode. fixup shas one element per byte in methodObj's bytecode abstractOpcodes > the code generated when compiling methodObj byte0 byte1 byte2 byte3 individual bytes of current bytecode being compiled in methodObj bytecodePointer bytecode pc (same as Smalltalk) of the current bytecode being compiled opcodeIndex the index of the next free entry in abstractOpcodes (this code is translated into C where OrderedCollection et al do not exist) numAbstractOpcodes the number of elements in abstractOpcocdes blockStarts > the starts of blocks in the current method blockCount the index into blockStarts as they are being noted, and hence eventually the total number of blocks in the current method labelCounter a nicety for numbering labels not needed in the production system but probably not expensive enough to worry about ceStackOverflowTrampoline ceSend0ArgsTrampoline ceSend1ArgsTrampoline ceSend2ArgsTrampoline ceSendNArgsTrampoline ceSendSuper0ArgsTrampoline ceSendSuper1ArgsTrampoline ceSendSuper2ArgsTrampoline ceSendSuperNArgsTrampoline ceSICMissTrampoline ceCPICMissTrampoline ceStoreCheckTrampoline ceReturnToInterpreterTrampoline ceBaseFrameReturnTrampoline ceSendMustBeBooleanTrampoline ceClosureCopyTrampoline the various trampolines (system-call-like jumps from machine code to the run-time). See Cogit>>generateTrampolines for the mapping from trampoline to run-time routine and then read the run-time routine for a funcitonal description. ceEnterCogCodePopReceiverReg the enilopmart (jump from run-time to machine-code) methodZoneBase ! Cogit class instanceVariableNames: 'generatorTable primitiveTable'! Item was added: + ----- Method: Cogit>>CallFullRT:registersToBeSavedMask: (in category 'compile abstract instructions') ----- + CallFullRT: callTarget registersToBeSavedMask: registersToBeSaved + + | callerSavedRegsToBeSaved lastInst reg registersToBePushed | + + callerSavedRegsToBeSaved := CallerSavedRegisterMask bitAnd: registersToBeSaved. + + backEnd canPushPopMultipleRegisters + ifTrue: [backEnd genPushRegisterMask: callerSavedRegsToBeSaved] + ifFalse: + [registersToBePushed := callerSavedRegsToBeSaved. + reg := 0. + [registersToBePushed ~= 0] whileTrue: + [(registersToBePushed anyMask: 1) ifTrue: + [self PushR: reg]. + reg := reg + 1. + registersToBePushed := registersToBePushed >>> 1]]. + + lastInst := self CallFullRT: callTarget. + + backEnd canPushPopMultipleRegisters + ifTrue: [^backEnd genPopRegisterMask: callerSavedRegsToBeSaved] + ifFalse: + [[reg >= 0] whileTrue: + [(callerSavedRegsToBeSaved anyMask: 1 << reg) ifTrue: + [lastInst := self PopR: reg]. + reg := reg - 1]. + + ^lastInst]! Item was added: + ----- Method: Cogit>>CallRT:registersToBeSavedMask: (in category 'compile abstract instructions') ----- + CallRT: callTarget registersToBeSavedMask: registersToBeSaved + + | callerSavedRegsToBeSaved lastInst reg registersToBePushed | + + callerSavedRegsToBeSaved := CallerSavedRegisterMask bitAnd: registersToBeSaved. + + backEnd canPushPopMultipleRegisters + ifTrue: [backEnd genPushRegisterMask: callerSavedRegsToBeSaved] + ifFalse: + [registersToBePushed := callerSavedRegsToBeSaved. + reg := 0. + [registersToBePushed ~= 0] whileTrue: + [(registersToBePushed anyMask: 1) ifTrue: + [self PushR: reg]. + reg := reg + 1. + registersToBePushed := registersToBePushed >>> 1]]. + + lastInst := self CallRT: callTarget. + + backEnd canPushPopMultipleRegisters + ifTrue: [^backEnd genPopRegisterMask: callerSavedRegsToBeSaved] + ifFalse: + [[reg >= 0] whileTrue: + [(callerSavedRegsToBeSaved anyMask: 1 << reg) ifTrue: + [lastInst := self PopR: reg]. + reg := reg - 1]. + + ^lastInst]! Item was removed: - ----- Method: Cogit>>callerSavedRegMask (in category 'accessing') ----- - callerSavedRegMask - - ^callerSavedRegMask! Item was changed: ----- Method: Cogit>>handleABICallOrJumpSimulationTrap:evaluable: (in category 'simulation only') ----- handleABICallOrJumpSimulationTrap: aProcessorSimulationTrap evaluable: evaluable self assert: aProcessorSimulationTrap type = #call. processor simulateLeafCallOf: aProcessorSimulationTrap address nextpc: aProcessorSimulationTrap nextpc memory: coInterpreter memory. self recordInstruction: {'(simulated call of '. aProcessorSimulationTrap address. '/'. evaluable selector. ')'}. + ((printRegisters or: [printInstructions]) and: [clickConfirm]) ifTrue: + [(self confirm: 'skip run-time call?') ifFalse: + [clickConfirm := false. self halt]]. evaluable valueWithArguments: (processor postCallArgumentsNumArgs: evaluable numArgs in: coInterpreter memory). self recordInstruction: {'(simulated return to '. processor retpcIn: coInterpreter memory. ')'}. processor smashABICallerSavedRegistersWithValuesFrom: 16r80000000 by: objectMemory wordSize; simulateLeafReturnIn: coInterpreter memory! Item was changed: ----- Method: Cogit>>initializeBackend (in category 'initialization') ----- initializeBackend methodLabel machineCodeSize: 0. methodLabel opcode: Label. methodLabel operands at: 0 put: 0. methodLabel operands at: 1 put: 0. "label offset" - callerSavedRegMask := backEnd callerSavedRegisterMask. backEnd hasVarBaseRegister ifTrue: + [self assert: ((self registerMaskFor: VarBaseReg) noMask: CallerSavedRegisterMask)]. - [self assert: ((self registerMaskFor: VarBaseReg) noMask: callerSavedRegMask)]. literalsManager allocateLiterals: 4; resetLiterals! Item was changed: ----- Method: Cogit>>printCogMethodFor: (in category 'printing') ----- printCogMethodFor: address | cogMethod | cogMethod := methodZone methodFor: address. cogMethod = 0 + ifTrue: [(self codeEntryFor: address) + ifNil: [coInterpreter print: 'not a method'; cr] + ifNotNil: [coInterpreter print: 'trampoline '; print: (self codeEntryNameFor: address); cr]] - ifTrue: [coInterpreter print: 'not a method'; cr] ifFalse: [coInterpreter printCogMethod: cogMethod]! Item was changed: ----- Method: Cogit>>printRegisterMapOn: (in category 'disassembly') ----- printRegisterMapOn: aStream | map n | map := backEnd generalPurposeRegisterMap. n := 0. + (map keys asSortedCollection: [:a :b| (map at: a) < (map at: b)]) - map keys sort do: [:regName| | abstractName | + abstractName := backEnd nameForRegister: (map at: regName). - abstractName := CogAbstractRegisters nameForRegister: (map at: regName). aStream nextPutAll: abstractName; nextPutAll: ' => '; nextPutAll: regName] separatedBy: [(n := n + 1) \\ 4 = 0 ifTrue: [aStream cr] ifFalse: [aStream tab]]. aStream cr; flush! Item was changed: ----- Method: SimpleStackBasedCogit>>genTraceStoreTrampoline (in category 'initialization') ----- genTraceStoreTrampoline ceTraceStoreTrampoline := self genTrampolineFor: #ceTraceStoreOf:into: called: 'ceTraceStoreTrampoline' arg: ClassReg arg: ReceiverResultReg + regsToSave: CallerSavedRegisterMask! - regsToSave: callerSavedRegMask! Item was changed: ----- Method: SimpleStackBasedCogit>>generateTracingTrampolines (in category 'initialization') ----- generateTracingTrampolines "Generate trampolines for tracing. In the simulator we can save a lot of time and avoid noise instructions in the lastNInstructions log by short-cutting these trampolines, but we need them in the real vm." ceTraceLinkedSendTrampoline := self genTrampolineFor: #ceTraceLinkedSend: called: 'ceTraceLinkedSendTrampoline' arg: ReceiverResultReg + regsToSave: CallerSavedRegisterMask. - regsToSave: callerSavedRegMask. ceTraceBlockActivationTrampoline := self genTrampolineFor: #ceTraceBlockActivation called: 'ceTraceBlockActivationTrampoline' + regsToSave: CallerSavedRegisterMask.. - regsToSave: callerSavedRegMask.. ceTraceStoreTrampoline := self genTrampolineFor: #ceTraceStoreOf:into: called: 'ceTraceStoreTrampoline' arg: ClassReg arg: ReceiverResultReg + regsToSave: CallerSavedRegisterMask.. - regsToSave: callerSavedRegMask.. self cCode: [] inSmalltalk: [ceTraceLinkedSendTrampoline := self simulatedTrampolineFor: #ceShortCutTraceLinkedSend:. ceTraceBlockActivationTrampoline := self simulatedTrampolineFor: #ceShortCutTraceBlockActivation:. ceTraceStoreTrampoline := self simulatedTrampolineFor: #ceShortCutTraceStore:]! Item was changed: ----- Method: SimpleStackBasedCogit>>isCallerSavedReg: (in category 'register management') ----- isCallerSavedReg: reg + ^self register: reg isInMask: CallerSavedRegisterMask! - ^self register: reg isInMask: callerSavedRegMask! Item was changed: ----- Method: StackToRegisterMappingCogit>>generateTracingTrampolines (in category 'initialization') ----- generateTracingTrampolines "Generate trampolines for tracing. In the simulator we can save a lot of time and avoid noise instructions in the lastNInstructions log by short-cutting these trampolines, but we need them in the real vm." ceTraceLinkedSendTrampoline := self genTrampolineFor: #ceTraceLinkedSend: called: 'ceTraceLinkedSendTrampoline' arg: ReceiverResultReg + regsToSave: CallerSavedRegisterMask.. - regsToSave: callerSavedRegMask.. ceTraceBlockActivationTrampoline := self genTrampolineFor: #ceTraceBlockActivation called: 'ceTraceBlockActivationTrampoline' + regsToSave: CallerSavedRegisterMask.. - regsToSave: callerSavedRegMask.. ceTraceStoreTrampoline := self genTrampolineFor: #ceTraceStoreOf:into: called: 'ceTraceStoreTrampoline' arg: TempReg arg: ReceiverResultReg + regsToSave: CallerSavedRegisterMask.. - regsToSave: callerSavedRegMask.. self cCode: [] inSmalltalk: [ceTraceLinkedSendTrampoline := self simulatedTrampolineFor: #ceShortCutTraceLinkedSend:. ceTraceBlockActivationTrampoline := self simulatedTrampolineFor: #ceShortCutTraceBlockActivation:. ceTraceStoreTrampoline := self simulatedTrampolineFor: #ceShortCutTraceStore:]! Item was changed: ----- Method: StackToRegisterMappingCogit>>ssAllocateCallReg: (in category 'simulation stack') ----- ssAllocateCallReg: requiredReg "Allocate a register needed in a run-time call (i.e. flush uses of the register to the real stack). Since the run-time can smash any and all caller-saved registers also flush all caller-saved registers." + self ssAllocateRequiredRegMask: (CallerSavedRegisterMask - self ssAllocateRequiredRegMask: (callerSavedRegMask bitOr: (self registerMaskFor: requiredReg)) upThrough: simStackPtr! Item was changed: ----- Method: StackToRegisterMappingCogit>>ssAllocateCallReg:and: (in category 'simulation stack') ----- ssAllocateCallReg: requiredReg1 and: requiredReg2 "Allocate registers needed in a run-time call (i.e. flush uses of the registers to the real stack). Since the run-time can smash any and all caller-saved registers also flush all caller-saved registers." + self ssAllocateRequiredRegMask: (CallerSavedRegisterMask - self ssAllocateRequiredRegMask: (callerSavedRegMask bitOr: ((self registerMaskFor: requiredReg1) bitOr: (self registerMaskFor: requiredReg2))) upThrough: simStackPtr! Item was changed: ----- Method: StackToRegisterMappingCogit>>ssAllocateCallReg:and:and: (in category 'simulation stack') ----- ssAllocateCallReg: requiredReg1 and: requiredReg2 and: requiredReg3 "Allocate registers needed in a run-time call (i.e. flush uses of the registers to the real stack). Since the run-time can smash any and all caller-saved registers also flush all caller-saved registers." + self ssAllocateRequiredRegMask: (CallerSavedRegisterMask - self ssAllocateRequiredRegMask: (callerSavedRegMask bitOr: ((self registerMaskFor: requiredReg1) bitOr: ((self registerMaskFor: requiredReg2) bitOr: (self registerMaskFor: requiredReg3)))) upThrough: simStackPtr! Item was changed: ----- Method: StackToRegisterMappingCogit>>ssAllocateCallReg:and:and:and: (in category 'simulation stack') ----- ssAllocateCallReg: requiredReg1 and: requiredReg2 and: requiredReg3 and: requiredReg4 "Allocate registers needed in a run-time call (i.e. flush uses of the registers to the real stack). Since the run-time can smash any and all caller-saved registers also flush all caller-saved registers." + self ssAllocateRequiredRegMask: (CallerSavedRegisterMask - self ssAllocateRequiredRegMask: (callerSavedRegMask bitOr: ((self registerMaskFor: requiredReg1) bitOr: ((self registerMaskFor: requiredReg2) bitOr: ((self registerMaskFor: requiredReg3) bitOr: (self registerMaskFor: requiredReg4))))) upThrough: simStackPtr! From commits at squeakvm.org Wed Jun 1 19:32:09 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Wed Jun 1 19:31:58 2016 Subject: [Vm-dev] [commit][3733] CogVM source as per VMMaker.oscog-eem.1876 Message-ID: Revision: 3733 Author: eliot Date: 2016-06-01 12:32:08 -0700 (Wed, 01 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1876 Cogit: Change the JIT so that (with Immutability/Write barrier ON) methods with only frameless instance variable stores are compiled with two paths. The code first checks if the receiver is immutable/read-only, and takes the right path accordingly. The first path is frameless and does not include immutability/write barrier checks. The second one is frameful and does all the immutability/write barrier checks. Eliminate the callerSavedRegMask variable and replace it with a CallerSavedRegisterMask variable computed at register initialization time. On ARM: - define the caller-saved registers as the subset of the caller-saved registers that excludes R0/CArg0Reg/TempReg & R1/CArg1Reg (R0 is the C result register), and use R2 & R3 for abstract registers (ClassReg and Arg0Reg). - save and restore elements of the caller-saved registers as appropriate around run-time calls. - use LDM & STM to do the saving. - hence provide two extra registers, now provinding Extra[012]Reg Fix some compilation warnings in cogitX64.c Plugins: Change the JPEGReaderPlugin to handle 8- and 16- bit JPEGs (thank you Laura ! ; still to integrate the refactoring into C and Smalltalk code). More inlining of low-level copy routines in the LargeInegersPlugin. Modified Paths: -------------- branches/Cog/nsspur64src/vm/cogit.h branches/Cog/nsspur64src/vm/cogitX64.c branches/Cog/nsspur64src/vm/cointerp.c branches/Cog/nsspur64src/vm/cointerp.h branches/Cog/nsspur64src/vm/gcc3x-cointerp.c branches/Cog/nsspursrc/vm/cogit.h branches/Cog/nsspursrc/vm/cogitARMv5.c branches/Cog/nsspursrc/vm/cogitIA32.c branches/Cog/nsspursrc/vm/cogitMIPSEL.c branches/Cog/nsspursrc/vm/cointerp.c branches/Cog/nsspursrc/vm/cointerp.h branches/Cog/nsspursrc/vm/gcc3x-cointerp.c branches/Cog/nsspurstack64src/vm/gcc3x-interp.c branches/Cog/nsspurstack64src/vm/interp.c branches/Cog/nsspurstacksrc/vm/gcc3x-interp.c branches/Cog/nsspurstacksrc/vm/interp.c branches/Cog/spur64src/vm/cogit.h branches/Cog/spur64src/vm/cogitX64.c branches/Cog/spur64src/vm/cointerp.c branches/Cog/spur64src/vm/cointerp.h branches/Cog/spur64src/vm/gcc3x-cointerp.c branches/Cog/spursistasrc/vm/cogit.h branches/Cog/spursistasrc/vm/cogitARMv5.c branches/Cog/spursistasrc/vm/cogitIA32.c branches/Cog/spursistasrc/vm/cogitMIPSEL.c branches/Cog/spursistasrc/vm/cointerp.c branches/Cog/spursistasrc/vm/cointerp.h branches/Cog/spursistasrc/vm/gcc3x-cointerp.c branches/Cog/spursrc/vm/cogit.h branches/Cog/spursrc/vm/cogitARMv5.c branches/Cog/spursrc/vm/cogitIA32.c branches/Cog/spursrc/vm/cogitMIPSEL.c branches/Cog/spurstack64src/vm/gcc3x-interp.c branches/Cog/spurstack64src/vm/interp.c branches/Cog/spurstacksrc/vm/gcc3x-interp.c branches/Cog/spurstacksrc/vm/interp.c branches/Cog/src/plugins/B2DPlugin/B2DPlugin.c branches/Cog/src/plugins/BitBltPlugin/BitBltPlugin.c branches/Cog/src/plugins/JPEGReaderPlugin/JPEGReaderPlugin.c branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c branches/Cog/src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c branches/Cog/src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c branches/Cog/src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c branches/Cog/src/vm/cogit.h branches/Cog/src/vm/cogitARMv5.c branches/Cog/src/vm/cogitIA32.c branches/Cog/src/vm/cogitMIPSEL.c branches/Cog/src/vm/cointerp.c branches/Cog/src/vm/cointerp.h branches/Cog/src/vm/cointerpmt.c branches/Cog/src/vm/cointerpmt.h branches/Cog/src/vm/gcc3x-cointerp.c branches/Cog/src/vm/gcc3x-cointerpmt.c branches/Cog/stacksrc/vm/gcc3x-interp.c branches/Cog/stacksrc/vm/interp.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Modified: branches/Cog/nsspur64src/vm/cogit.h =================================================================== --- branches/Cog/nsspur64src/vm/cogit.h 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspur64src/vm/cogit.h 2016-06-01 19:32:08 UTC (rev 3733) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ Modified: branches/Cog/nsspur64src/vm/cogitX64.c =================================================================== --- branches/Cog/nsspur64src/vm/cogitX64.c 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-01 19:32:08 UTC (rev 3733) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 + CCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e from - StackToRegisterMappingCogit VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 + StackToRegisterMappingCogit VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -45,6 +45,7 @@ #define BlockCreationBytecodeSize 4 #define BytecodeSetHasDirectedSuperSend 0 #define Call 6 +#define CallerSavedRegisterMask 0xFC7 #define CallFull 7 #define CDQ 116 #if !defined(CheckRememberedInTrampoline) /* Allow this to be overridden on the compiler command line */ @@ -248,8 +249,6 @@ #define PushCq 74 #define PushCw 75 #define PushR 73 -#define R10 10 -#define R11 11 #define R12 12 #define R13 13 #define R15 15 @@ -469,6 +468,7 @@ static sqInt NoDbgRegParms blockDispatchTargetsForperformarg(CogMethod *cogMethod, usqInt (*binaryFunction)(sqInt mcpc, sqInt arg), sqInt arg); extern sqInt bytecodePCForstartBcpcin(sqInt mcpc, sqInt startbcpc, CogBlockMethod *cogMethod); static AbstractInstruction * NoDbgRegParms CallNewspeakSend(sqInt callTarget); +static AbstractInstruction * NoDbgRegParms CallRTregistersToBeSavedMask(sqInt callTarget, sqInt registersToBeSaved); static AbstractInstruction * NoDbgRegParms gCall(sqInt callTarget); static AbstractInstruction * NoDbgRegParms gCmpCqR(sqInt quickConstant, sqInt reg); static AbstractInstruction * NoDbgRegParms gCmpCwR(sqInt wordConstant, sqInt reg); @@ -601,7 +601,7 @@ static AbstractInstruction * NoDbgRegParms gMoveCwR(sqInt wordConstant, sqInt reg); static AbstractInstruction * NoDbgRegParms gMoveRMwr(sqInt sourceReg, sqInt offset, sqInt baseReg); static AbstractInstruction * NoDbgRegParms gMoveRR(sqInt reg1, sqInt reg2); -static usqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); +static sqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); static sqInt NoDbgRegParms mapForperformUntilarg(CogMethod *cogMethod, sqInt (*functionSymbol)(sqInt annotation, char *mcpc, sqInt arg), sqInt arg); static sqInt NoDbgRegParms mapObjectReferencesInClosedPIC(CogMethod *cPIC); static void mapObjectReferencesInGeneratedRuntime(void); @@ -632,7 +632,7 @@ static sqInt NoDbgRegParms needsFrameNever(sqInt stackDelta); static sqInt NoDbgRegParms noAssertMethodClassAssociationOf(sqInt methodPointer); static sqInt noCogMethodsMaximallyMarked(void); -static sqInt NoDbgRegParms noTargetsFreeInClosedPIC(sqInt cPIC); +static sqInt NoDbgRegParms noTargetsFreeInClosedPIC(CogMethod *cPIC); static sqInt NoDbgRegParms outputInstructionsAt(sqInt startAddress); static sqInt NoDbgRegParms outputInstructionsForGeneratedRuntimeAt(sqInt startAddress); static AbstractInstruction * NoDbgRegParms gPushCw(sqInt wordConstant); @@ -889,11 +889,8 @@ static sqInt NoDbgRegParms registerMask(SimStackEntry * self_in_registerMask); static sqInt NoDbgRegParms registerOrNone(SimStackEntry * self_in_registerOrNone); static SimStackEntry * NoDbgRegParms storeToReg(SimStackEntry * self_in_storeToReg, sqInt reg); -static sqInt NoDbgRegParms isBackwardBranchFixup(BytecodeFixup * self_in_isBackwardBranchFixup); static sqInt NoDbgRegParms isMergeFixup(BytecodeFixup * self_in_isMergeFixup); -static sqInt NoDbgRegParms isMergeFixupOrIsFixedUp(BytecodeFixup * self_in_isMergeFixupOrIsFixedUp); static sqInt NoDbgRegParms availableRegisterOrNoneFor(AbstractInstruction * self_in_availableRegisterOrNoneFor, sqInt liveRegsMask); -static sqInt NoDbgRegParms callerSavedRegisterMask(AbstractInstruction * self_in_callerSavedRegisterMask); static sqInt NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms callInstructionByteSize(AbstractInstruction * self_in_callInstructionByteSize); static sqInt NoDbgRegParms callTargetFromReturnAddress(AbstractInstruction * self_in_callTargetFromReturnAddress, sqInt callSiteReturnAddress); @@ -1076,6 +1073,9 @@ static CogMethod * NoDbgRegParms compileCogMethod(sqInt selector); static sqInt compileEntireMethod(void); static void compileFrameBuild(void); +#if IMMUTABILITY +static void compileTwoPathFrameBuild(void); +#endif /* IMMUTABILITY */ static sqInt NoDbgRegParms cPICMissTrampolineFor(sqInt numArgs); static sqInt doubleExtendedDoAnythingBytecode(void); static sqInt duplicateTopBytecode(void); @@ -1210,7 +1210,6 @@ static sqInt bytecodeSetOffset; void * CFramePointer; void * CStackPointer; -static sqInt callerSavedRegMask; static sqInt cbEntryOffset; static sqInt cbNoSwitchEntryOffset; sqInt ceBaseFrameReturnTrampoline; @@ -1273,12 +1272,13 @@ static sqInt debugFixupBreaks; static sqInt debugOpcodeIndices; unsigned long debugPrimCallStackOffset; +static sqInt debugStackPointers; static sqInt disassemblingMethod; static sqInt dynamicSuperSendTrampolines[NumSendTrampolines]; static AbstractInstruction * endCPICCase0; static sqInt endPC; static AbstractInstruction * entry; -static sqInt enumeratingCogMethod; +static CogMethod * enumeratingCogMethod; static sqInt expectedFPAlignment; static sqInt expectedSPAlignment; static sqInt extA; @@ -1831,6 +1831,7 @@ sqInt missOffset; static usqInt mzFreeStart; static sqInt needsFrame; +static sqInt needsTwoPath; static AbstractInstruction * noCheckEntry; static sqInt numAbstractOpcodes; static sqInt numIRCs; @@ -1885,7 +1886,6 @@ #define blockAlignment(self) 8 #define blockStartAt(index) (&blockStarts[index]) #define breakOnImplicitReceiver() (traceFlags & 64) -#define callerSavedRegMask() callerSavedRegMask #define ceBaseFrameReturnPC() ceBaseFrameReturnTrampoline #define ceCannotResumePC() ((usqInt)ceCannotResumeTrampoline) #define ceCheckFeatures() ceCheckFeaturesFunction() @@ -2605,7 +2605,7 @@ static sqInt NoDbgRegParms addressIsInInstructions(AbstractInstruction *address) { - return !((unsigned)(address) & BytesPerWord-1) \ + return !((usqInt)(address) & BytesPerWord-1) \ && (address) >= &abstractOpcodes[0] \ && (address) < &abstractOpcodes[opcodeIndex]; } @@ -2796,7 +2796,7 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - usqInt endbcpc; + sqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; @@ -2962,6 +2962,44 @@ return abstractInstruction; } + /* Cogit>>#CallRT:registersToBeSavedMask: */ +static AbstractInstruction * NoDbgRegParms +CallRTregistersToBeSavedMask(sqInt callTarget, sqInt registersToBeSaved) +{ + AbstractInstruction *abstractInstruction; + sqInt callerSavedRegsToBeSaved; + AbstractInstruction *lastInst; + sqInt reg; + sqInt registersToBePushed; + + reg = 0; + callerSavedRegsToBeSaved = CallerSavedRegisterMask & registersToBeSaved; + registersToBePushed = callerSavedRegsToBeSaved; + reg = 0; + while (registersToBePushed != 0) { + if (registersToBePushed & 1) { + /* begin PushR: */ + genoperand(PushR, reg); + } + reg += 1; + registersToBePushed = ((sqInt) registersToBePushed) >> 1; + } + + /* begin CallRT: */ + abstractInstruction = genoperand(Call, callTarget); + (abstractInstruction->annotation = IsRelativeCall); + lastInst = abstractInstruction; + while (reg >= 0) { + if (callerSavedRegsToBeSaved & (1LL << reg)) { + /* begin PopR: */ + lastInst = genoperand(PopR, reg); + } + reg -= 1; + } + return lastInst; + +} + /* Cogit>>#Call: */ static AbstractInstruction * NoDbgRegParms gCall(sqInt callTarget) @@ -3667,7 +3705,7 @@ closedPICRefersToUnmarkedObject(CogMethod *cPIC) { sqInt i; - sqInt object; + usqInt object; sqInt pc; if (!((isImmediate((cPIC->selector))) @@ -4464,6 +4502,8 @@ # if ABI == MSVC + + /* completely untested... */ if (regOrConst2 < NoReg) { /* begin MoveCq:R: */ anInstruction4 = genoperandoperand(MoveCqR, -2 - regOrConst2, R8); @@ -5236,7 +5276,7 @@ findMapLocationForMcpcinMethod(sqInt targetMcpc, CogMethod *cogMethod) { sqInt annotation; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; @@ -5320,7 +5360,7 @@ followForwardedLiteralsIn(CogMethod *cogMethod) { sqInt annotation; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -6721,8 +6761,7 @@ (methodLabel->opcode = Label); ((methodLabel->operands))[0] = 0; ((methodLabel->operands))[1] = 0; - callerSavedRegMask = callerSavedRegisterMask(backEnd); - assert(((registerMaskFor(VarBaseReg)) & callerSavedRegMask) == 0); + assert(((registerMaskFor(VarBaseReg)) & CallerSavedRegisterMask) == 0); } @@ -7136,10 +7175,10 @@ /* Answer the address of the null byte at the end of the method map. */ /* Cogit>>#mapEndFor: */ -static usqInt NoDbgRegParms +static sqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod) { - usqInt end; + sqInt end; end = ((((usqInt)cogMethod)) + ((cogMethod->blockSize))) - 1; while ((byteAt(end)) != MapEnd) { @@ -7157,7 +7196,7 @@ mapForperformUntilarg(CogMethod *cogMethod, sqInt (*functionSymbol)(sqInt annotation, char *mcpc, sqInt arg), sqInt arg) { sqInt annotation; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -7264,7 +7303,7 @@ sqInt freedPIC; sqInt hasYoungObj; sqInt hasYoungObjPtr; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt remappedMethod; @@ -7382,7 +7421,7 @@ { sqInt annotation; CogMethod *cogMethod; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -7462,7 +7501,7 @@ CogMethod *cogMethod; sqInt hasYoungObj; sqInt hasYoungObjPtr; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; usqInt pointer; @@ -7582,8 +7621,8 @@ sqInt annotation; sqInt annotation1; CogMethod *cogMethod; - usqInt map; - usqInt map1; + sqInt map; + sqInt map1; sqInt mapByte; sqInt mapByte1; usqInt mcpc; @@ -7742,7 +7781,7 @@ markAndTraceOrFreeCogMethodfirstVisit(CogMethod *cogMethod, sqInt firstVisit) { sqInt annotation; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -8070,7 +8109,7 @@ { sqInt annotation; CogMethod *cogMethod; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -8198,7 +8237,7 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - usqInt endbcpc; + sqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; @@ -8483,7 +8522,7 @@ /* Cogit>>#noTargetsFreeInClosedPIC: */ static sqInt NoDbgRegParms -noTargetsFreeInClosedPIC(sqInt cPIC) +noTargetsFreeInClosedPIC(CogMethod *cPIC) { return !(cPICHasFreedTargets(cPIC)); } @@ -8628,8 +8667,15 @@ cogMethod = methodFor(address); if (cogMethod == 0) { - print("not a method"); - cr(); + if ((codeEntryFor(address)) == null) { + print("not a method"); + cr(); + } + else { + print("trampoline "); + print(codeEntryNameFor(address)); + cr(); + } } else { printCogMethod(cogMethod); @@ -8641,9 +8687,9 @@ printPCMapPairsFor(CogMethod *cogMethod) { sqInt annotation; - usqInt map; + sqInt map; unsigned char mapByte; - usqInt mcpc; + sqInt mcpc; sqInt value; mcpc = (0 @@ -8820,7 +8866,7 @@ { sqInt annotation; sqLong callDelta; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqLong refDelta; @@ -9394,7 +9440,7 @@ { sqInt annotation; CogMethod *cogMethod; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -9837,7 +9883,7 @@ sqInt annotation; CogMethod *cogMethod; sqInt freedPIC; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -9914,7 +9960,7 @@ { sqInt annotation; CogMethod *cogMethod; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt mustScanAndUnlink; @@ -10013,7 +10059,7 @@ { sqInt annotation; CogMethod *cogMethod; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -10082,7 +10128,7 @@ sqInt annotation; CogMethod *cogMethod; sqInt freedPIC; - usqInt map; + sqInt map; sqInt mapByte; usqInt mcpc; sqInt result; @@ -10471,8 +10517,6 @@ freeOlderMethodsForCompaction(void) { usqInt amountToFree; - sqInt cascade0; - sqInt cascade1; CogMethod *cogMethod; sqInt freeableUsage; usqInt freedSoFar; @@ -10499,7 +10543,7 @@ } } while((freedSoFar < amountToFree) && (((freeableUsage += 1)) < CMMaxUsageCount)); - } +} /* Answer that all entries in youngReferrers are in-use and have the @@ -15000,11 +15044,11 @@ genoperand(RetN, 0); jmpTarget(jumpSC, gLabel()); } - ceStoreCheckTrampoline = genTrampolineForcallednumArgsargargargargregsToSavepushLinkRegresultRegappendOpcodes(remember, "ceStoreCheckTrampoline", 1, ReceiverResultReg, null, null, null, (((callerSavedRegMask()) | (1LL << ReceiverResultReg)) - (1LL << ReceiverResultReg)), 1, (callerSavedRegMask & (1LL << ReceiverResultReg) + ceStoreCheckTrampoline = genTrampolineForcallednumArgsargargargargregsToSavepushLinkRegresultRegappendOpcodes(remember, "ceStoreCheckTrampoline", 1, ReceiverResultReg, null, null, null, ((CallerSavedRegisterMask | (1LL << ReceiverResultReg)) - (1LL << ReceiverResultReg)), 1, (CallerSavedRegisterMask & (1LL << ReceiverResultReg) ? ReceiverResultReg : RAX), CheckRememberedInTrampoline); ceStoreCheckContextReceiverTrampoline = genStoreCheckContextReceiverTrampoline(); - ceScheduleScavengeTrampoline = genTrampolineForcalledregsToSave(ceScheduleScavenge, "ceScheduleScavengeTrampoline", callerSavedRegMask()); + ceScheduleScavengeTrampoline = genTrampolineForcalledregsToSave(ceScheduleScavenge, "ceScheduleScavengeTrampoline", CallerSavedRegisterMask); ceSmallActiveContextInMethodTrampoline = genActiveContextTrampolineLargeinBlockcalled(0, 0, "ceSmallMethodContext"); ceSmallActiveContextInBlockTrampoline = genActiveContextTrampolineLargeinBlockcalled(0, 1, "ceSmallBlockContext"); ceLargeActiveContextInMethodTrampoline = genActiveContextTrampolineLargeinBlockcalled(1, 0, "ceLargeMethodContext"); @@ -15020,7 +15064,6 @@ static sqInt NoDbgRegParms genGetActiveContextLargeinBlock(sqInt isLarge, sqInt isInBlock) { - AbstractInstruction *abstractInstruction; sqInt address; sqInt address1; AbstractInstruction *anInstruction; @@ -15241,9 +15284,7 @@ /* begin RetN: */ genoperand(RetN, 0); jmpTarget(jumpNeedScavenge, gLabel()); - /* begin CallRT: */ - abstractInstruction = genoperand(Call, ceScheduleScavengeTrampoline); - (abstractInstruction->annotation = IsRelativeCall); + CallRTregistersToBeSavedMask(ceScheduleScavengeTrampoline, ((1LL << ReceiverResultReg) | (1LL << SendNumArgsReg)) | (1LL << ClassReg)); /* begin Jump: */ genoperand(Jump, ((sqInt)continuation)); @@ -16794,13 +16835,6 @@ return self_in_storeToReg; } - /* CogSSBytecodeFixup>>#isBackwardBranchFixup */ -static sqInt NoDbgRegParms -isBackwardBranchFixup(BytecodeFixup * self_in_isBackwardBranchFixup) -{ - return ((self_in_isBackwardBranchFixup->simStackPtr)) == UnknownSimStackPtrFlag; -} - /* CogSSBytecodeFixup>>#isMergeFixup */ static sqInt NoDbgRegParms isMergeFixup(BytecodeFixup * self_in_isMergeFixup) @@ -16808,14 +16842,7 @@ return (((usqInt)((self_in_isMergeFixup->targetInstruction)))) == NeedsMergeFixupFlag; } - /* CogSSBytecodeFixup>>#isMergeFixupOrIsFixedUp */ -static sqInt NoDbgRegParms -isMergeFixupOrIsFixedUp(BytecodeFixup * self_in_isMergeFixupOrIsFixedUp) -{ - return (((usqInt)((self_in_isMergeFixupOrIsFixedUp->targetInstruction)))) >= NeedsMergeFixupFlag; -} - /* Answer an unused abstract register in the liveRegMask. Subclasses with more registers can override to answer them. N.B. Do /not/ allocate TempReg. */ @@ -16864,20 +16891,6 @@ } -/* See e.g. Figure 3.4 Register Usage in - System V Application Binary Interface - AMD64 Architecture Processor Supplement - N.B. We are playing fast and loose here being processor-specific. - Soon enough this needs to be OS-specific. */ - - /* CogX64Compiler>>#callerSavedRegisterMask */ -static sqInt NoDbgRegParms -callerSavedRegisterMask(AbstractInstruction * self_in_callerSavedRegisterMask) -{ - return ((((((((1LL << RAX) | (1LL << RCX)) | (1LL << RDX)) | (1LL << RSI)) | (1LL << RDI)) | (1LL << R8)) | (1LL << R9)) | (1LL << R10)) | (1LL << R11); -} - - /* Answer the address the full call immediately preceding callSiteReturnAddress will jump to. */ @@ -23144,7 +23157,7 @@ CogBlockMethod *cogMethod1; BytecodeDescriptor *descriptor; sqInt distance; - usqInt endbcpc; + sqInt endbcpc; sqInt errCode; CogMethod *homeMethod; sqInt isBackwardBranch; @@ -24748,7 +24761,6 @@ compileCogMethod(sqInt selector) { unsigned long allocBytes; - sqInt debugStackPointers; int extra; unsigned long fixupBytes; sqInt numBlocks; @@ -24880,6 +24892,15 @@ sqInt iLimiT; AbstractInstruction *jumpSkip; + +# if IMMUTABILITY + if (needsTwoPath) { + compileTwoPathFrameBuild(); + return; + } + +# endif /* IMMUTABILITY */ + if (!needsFrame) { initSimStackForFramelessMethod(initialPC); return; @@ -24945,6 +24966,134 @@ initSimStackForFramefulMethod(initialPC); } + +/* Build a frame for a CogMethod activation. See CoInterpreter + class>>initializeFrameIndices. receiver (in ReceiverResultReg) + arg0 + ... + argN + caller's saved ip/this stackPage (for a base frame) + fp-> saved fp + method + context (uninitialized?) + receiver + first temp + ... + sp-> Nth temp + If there is a primitive and an error code the Nth temp is the error code. + Ensure SendNumArgsReg is set early on (incidentally to nilObj) because + it is the flag determining whether context switch is allowed on + stack-overflow. */ +/* We are in a method where the frame is needed *only* for instance variable + store, typically a setter method. + This case has 20% overhead with Immutability compared to setter without + immutability because of the stack + frame creation. We compile two path, one where the object is immutable, + one where it isn't. At the beginning + of the frame build, we take one path or the other depending on the + receiver mutability. + + Note: this specific case happens only where there are only instance + variabel stores. We could do something + similar for literal variable stores, but we don't as it's too uncommon. + */ + + /* StackToRegisterMappingCogit>>#compileTwoPathFrameBuild */ +#if IMMUTABILITY +static void +compileTwoPathFrameBuild(void) +{ + sqInt address; + AbstractInstruction *anInstruction; + AbstractInstruction *anInstruction1; + AbstractInstruction *anInstruction2; + AbstractInstruction *anInstruction3; + sqInt constant; + sqInt i; + sqInt iLimiT; + AbstractInstruction * jumpImmutable; + AbstractInstruction *jumpSkip; + + assert(needsFrame); + assert(IMMUTABILITY); + assert(needsTwoPath); + assert(blockCount == 0); + + /* first path. The receiver is mutable */ + jumpImmutable = genJumpImmutablescratchReg(ReceiverResultReg, TempReg); + initSimStackForFramelessMethod(initialPC); + /* begin compileMethodBody */ + if (endPC < initialPC) { + goto l7; + } + compileAbstractInstructionsFromthrough(initialPC + (deltaToSkipPrimAndErrorStoreInheader(methodObj, methodHeader)), endPC); +l7: /* end compileMethodBody */; + + /* reset because it impact inst var store compilation */ + needsTwoPath = 0; + jmpTarget(jumpImmutable, gLabel()); + genPushRegisterArgs(); + if (!needsFrame) { + return; + } + /* begin PushR: */ + genoperand(PushR, FPReg); + /* begin MoveR:R: */ + genoperandoperand(MoveRR, SPReg, FPReg); + addDependent(methodLabel, annotateAbsolutePCRef(gPushCw(((sqInt)methodLabel)))); + /* begin genMoveNilR: */ + constant = nilObject(); + if (shouldAnnotateObjectReference(constant)) { + annotateobjRef(gMoveCwR(constant, SendNumArgsReg), constant); + } + else { + /* begin MoveCq:R: */ + anInstruction = genoperandoperand(MoveCqR, constant, SendNumArgsReg); + } + /* begin PushR: */ + genoperand(PushR, SendNumArgsReg); + /* begin PushR: */ + genoperand(PushR, ReceiverResultReg); + for (i = (methodOrBlockNumArgs + 1), iLimiT = (temporaryCountOfMethodHeader(methodHeader)); i <= iLimiT; i += 1) { + /* begin PushR: */ + genoperand(PushR, SendNumArgsReg); + } + if (((primitiveIndexOfMethodheader(methodObj, methodHeader)) > 0) + && ((longStoreBytecodeForHeader(methodHeader)) == (fetchByteofObject(initialPC + (sizeOfCallPrimitiveBytecode(methodHeader)), methodObj)))) { + compileGetErrorCode(); + } + /* begin MoveAw:R: */ + address = stackLimitAddress(); + /* begin gen:literal:operand: */ + anInstruction3 = genoperandoperand(MoveAwR, address, TempReg); + /* begin CmpR:R: */ + genoperandoperand(CmpRR, TempReg, SPReg); + if (canContextSwitchIfActivatingheader(methodObj, methodHeader)) { + /* begin JumpBelow: */ + genConditionalBranchoperand(JumpBelow, ((sqInt)stackOverflowCall)); + /* begin Label */ + stackCheckLabel = genoperandoperand(Label, (labelCounter += 1), bytecodePC); + } + else { + /* begin JumpAboveOrEqual: */ + jumpSkip = genConditionalBranchoperand(JumpAboveOrEqual, ((sqInt)0)); + /* begin MoveCq:R: */ + anInstruction1 = genoperandoperand(MoveCqR, 0, SendNumArgsReg); + /* begin Jump: */ + genoperand(Jump, ((sqInt)stackOverflowCall)); + jmpTarget(jumpSkip, (stackCheckLabel = gLabel())); + } + /* begin annotateBytecode: */ + (stackCheckLabel->annotation = HasBytecodePC); + if (numIRCs > 0) { + /* begin PrefetchAw: */ + anInstruction2 = genoperand(PrefetchAw, theIRCs); + } + + initSimStackForFramefulMethod(initialPC); +} +#endif /* IMMUTABILITY */ + /* StackToRegisterMappingCogit>>#cPICMissTrampolineFor: */ static sqInt NoDbgRegParms cPICMissTrampolineFor(sqInt numArgs) @@ -25561,9 +25710,9 @@ static void generateTracingTrampolines(void) { - ceTraceLinkedSendTrampoline = genTrampolineForcalledargregsToSave(ceTraceLinkedSend, "ceTraceLinkedSendTrampoline", ReceiverResultReg, callerSavedRegMask); - ceTraceBlockActivationTrampoline = genTrampolineForcalledregsToSave(ceTraceBlockActivation, "ceTraceBlockActivationTrampoline", callerSavedRegMask); - ceTraceStoreTrampoline = genTrampolineForcalledargargregsToSave(ceTraceStoreOfinto, "ceTraceStoreTrampoline", TempReg, ReceiverResultReg, callerSavedRegMask); + ceTraceLinkedSendTrampoline = genTrampolineForcalledargregsToSave(ceTraceLinkedSend, "ceTraceLinkedSendTrampoline", ReceiverResultReg, CallerSavedRegisterMask); + ceTraceBlockActivationTrampoline = genTrampolineForcalledregsToSave(ceTraceBlockActivation, "ceTraceBlockActivationTrampoline", CallerSavedRegisterMask); + ceTraceStoreTrampoline = genTrampolineForcalledargargregsToSave(ceTraceStoreOfinto, "ceTraceStoreTrampoline", TempReg, ReceiverResultReg, CallerSavedRegisterMask); } /* StackToRegisterMappingCogit>>#genJumpBackTo: */ @@ -26076,7 +26225,7 @@ ensureReceiverResultRegContainsSelf(); /* begin genPushMaybeContextSlotIndex: */ assert(needsFrame); - if (callerSavedRegMask & (1LL << ReceiverResultReg)) { + if (CallerSavedRegisterMask & (1LL << ReceiverResultReg)) { /* We have no way of reloading ReceiverResultReg since we need the inst var value as the result. */ (optStatus.isReceiverResultRegLive = 0); @@ -26979,6 +27128,7 @@ AbstractInstruction *anInstruction; sqInt association; sqInt topReg; + sqInt topReg1; assert(needsFrame); /* begin genLoadLiteralVariable:in: */ @@ -26998,17 +27148,27 @@ /* begin genStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: */ # if IMMUTABILITY - /* begin genImmCheckStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: */ - ssAllocateRequiredReg(ClassReg); - ssStoreAndReplacePoptoReg(popBoolean, ClassReg); - ssFlushTo(simStackPtr); - genStoreWithImmutabilityCheckSourceRegslotIndexdestRegscratchRegneedsStoreCheckneedRestoreRcvr(ClassReg, ValueIndex, ReceiverResultReg, TempReg, needsStoreCheck, 0); + if (needsTwoPath) { + /* first path, receiver is mutable */ + /* begin genVanillaStorePop:slotIndex:destReg:needsStoreCheck: */ + topReg = allocateRegForStackEntryAtnotConflictingWith(0, 1LL << ReceiverResultReg); + ssStorePoptoReg(popBoolean, topReg); + genStoreSourceRegslotIndexdestRegscratchReginFrameneedsStoreCheck(topReg, ValueIndex, ReceiverResultReg, TempReg, needsFrame, needsStoreCheck); + } + else { + /* begin genImmCheckStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: */ + ssAllocateRequiredReg(ClassReg); + ssStoreAndReplacePoptoReg(popBoolean, ClassReg); + ssFlushTo(simStackPtr); + genStoreWithImmutabilityCheckSourceRegslotIndexdestRegscratchRegneedsStoreCheckneedRestoreRcvr(ClassReg, ValueIndex, ReceiverResultReg, TempReg, needsStoreCheck, 0); + } + # else /* IMMUTABILITY */ /* begin genVanillaStorePop:slotIndex:destReg:needsStoreCheck: */ - topReg = allocateRegForStackEntryAtnotConflictingWith(0, 1LL << ReceiverResultReg); - ssStorePoptoReg(popBoolean, topReg); - genStoreSourceRegslotIndexdestRegscratchReginFrameneedsStoreCheck(topReg, ValueIndex, ReceiverResultReg, TempReg, needsFrame, needsStoreCheck); + topReg1 = allocateRegForStackEntryAtnotConflictingWith(0, 1LL << ReceiverResultReg); + ssStorePoptoReg(popBoolean, topReg1); + genStoreSourceRegslotIndexdestRegscratchReginFrameneedsStoreCheck(topReg1, ValueIndex, ReceiverResultReg, TempReg, needsFrame, needsStoreCheck); # endif /* IMMUTABILITY */ @@ -27108,23 +27268,34 @@ genStorePopReceiverVariableneedsStoreCheck(sqInt popBoolean, sqInt slotIndex, sqInt needsStoreCheck) { sqInt topReg; + sqInt topReg1; ssFlushUpThroughReceiverVariable(slotIndex); ensureReceiverResultRegContainsSelf(); /* begin genStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: */ # if IMMUTABILITY - /* begin genImmCheckStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: */ - ssAllocateRequiredReg(ClassReg); - ssStoreAndReplacePoptoReg(popBoolean, ClassReg); - ssFlushTo(simStackPtr); - genStoreWithImmutabilityCheckSourceRegslotIndexdestRegscratchRegneedsStoreCheckneedRestoreRcvr(ClassReg, slotIndex, ReceiverResultReg, TempReg, needsStoreCheck, 1); + if (needsTwoPath) { + /* first path, receiver is mutable */ + /* begin genVanillaStorePop:slotIndex:destReg:needsStoreCheck: */ + topReg = allocateRegForStackEntryAtnotConflictingWith(0, 1LL << ReceiverResultReg); + ssStorePoptoReg(popBoolean, topReg); + genStoreSourceRegslotIndexdestRegscratchReginFrameneedsStoreCheck(topReg, slotIndex, ReceiverResultReg, TempReg, needsFrame, needsStoreCheck); + } + else { + /* begin genImmCheckStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: */ + ssAllocateRequiredReg(ClassReg); + ssStoreAndReplacePoptoReg(popBoolean, ClassReg); + ssFlushTo(simStackPtr); + genStoreWithImmutabilityCheckSourceRegslotIndexdestRegscratchRegneedsStoreCheckneedRestoreRcvr(ClassReg, slotIndex, ReceiverResultReg, TempReg, needsStoreCheck, 1); + } + # else /* IMMUTABILITY */ /* begin genVanillaStorePop:slotIndex:destReg:needsStoreCheck: */ - topReg = allocateRegForStackEntryAtnotConflictingWith(0, 1LL << ReceiverResultReg); - ssStorePoptoReg(popBoolean, topReg); - genStoreSourceRegslotIndexdestRegscratchReginFrameneedsStoreCheck(topReg, slotIndex, ReceiverResultReg, TempReg, needsFrame, needsStoreCheck); + topReg1 = allocateRegForStackEntryAtnotConflictingWith(0, 1LL << ReceiverResultReg); + ssStorePoptoReg(popBoolean, topReg1); + genStoreSourceRegslotIndexdestRegscratchReginFrameneedsStoreCheck(topReg1, slotIndex, ReceiverResultReg, TempReg, needsFrame, needsStoreCheck); # endif /* IMMUTABILITY */ @@ -27207,6 +27378,7 @@ { AbstractInstruction *abstractInstruction; AbstractInstruction *abstractInstruction1; + sqInt framelessReturn; sqInt offset; @@ -27222,7 +27394,17 @@ (abstractInstruction->annotation = HasBytecodePC); return 0; } - if (needsFrame) { + +# if IMMUTABILITY + framelessReturn = needsFrame + && (!needsTwoPath); + +# else /* IMMUTABILITY */ + framelessReturn = needsFrame; + +# endif /* IMMUTABILITY */ + + if (framelessReturn) { /* begin MoveR:R: */ genoperandoperand(MoveRR, FPReg, SPReg); /* begin PopR: */ @@ -27871,6 +28053,12 @@ needsFrame = 0; prevBCDescriptor = null; + +# if IMMUTABILITY + needsTwoPath = 0; + +# endif /* IMMUTABILITY */ + numIRCs = 0; if ((primitiveIndex > 0) @@ -27895,6 +28083,21 @@ && (pc >= latestContinuation)) { endPC = pc; } + +# if IMMUTABILITY + if (!(needsFrame + && (!needsTwoPath))) { + if ((((descriptor->needsFrameFunction)) == null) + || (((descriptor->needsFrameFunction))(framelessStackDelta))) { + needsFrame = 1; + needsTwoPath = ((descriptor->generator)) == genStoreAndPopReceiverVariableBytecode; + } + else { + framelessStackDelta += (descriptor->stackDelta); + } + } + +# else /* IMMUTABILITY */ if (!needsFrame) { if ((((descriptor->needsFrameFunction)) == null) || (((descriptor->needsFrameFunction))(framelessStackDelta))) { @@ -27904,6 +28107,9 @@ framelessStackDelta += (descriptor->stackDelta); } } + +# endif /* IMMUTABILITY */ + if (isBranch(descriptor)) { distance = ((descriptor->spanFunction))(descriptor, pc, nExts, methodObj); targetPC = (pc + ((descriptor->numBytes))) + distance; @@ -27945,7 +28151,7 @@ static void NoDbgRegParms ssAllocateCallReg(sqInt requiredReg) { - ssAllocateRequiredRegMaskupThrough(callerSavedRegMask | (1LL << requiredReg), simStackPtr); + ssAllocateRequiredRegMaskupThrough(CallerSavedRegisterMask | (1LL << requiredReg), simStackPtr); } @@ -27957,7 +28163,7 @@ static void NoDbgRegParms ssAllocateCallRegand(sqInt requiredReg1, sqInt requiredReg2) { - ssAllocateRequiredRegMaskupThrough(callerSavedRegMask | ((1LL << requiredReg1) | (1LL << requiredReg2)), simStackPtr); + ssAllocateRequiredRegMaskupThrough(CallerSavedRegisterMask | ((1LL << requiredReg1) | (1LL << requiredReg2)), simStackPtr); } @@ -27969,7 +28175,7 @@ static void NoDbgRegParms ssAllocateCallRegandand(sqInt requiredReg1, sqInt requiredReg2, sqInt requiredReg3) { - ssAllocateRequiredRegMaskupThrough(callerSavedRegMask | ((1LL << requiredReg1) | ((1LL << requiredReg2) | (1LL << requiredReg3))), simStackPtr); + ssAllocateRequiredRegMaskupThrough(CallerSavedRegisterMask | ((1LL << requiredReg1) | ((1LL << requiredReg2) | (1LL << requiredReg3))), simStackPtr); } /* StackToRegisterMappingCogit>>#ssAllocateRequiredRegMask:upThrough: */ Modified: branches/Cog/nsspur64src/vm/cointerp.c =================================================================== --- branches/Cog/nsspur64src/vm/cointerp.c 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspur64src/vm/cointerp.c 2016-06-01 19:32:08 UTC (rev 3733) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e from - CoInterpreter VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CoInterpreter VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -2452,7 +2452,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1872"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1876"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -40930,7 +40930,7 @@ sqInt oopRcvr; sqInt oopResult; usqLong result; - sqInt resultIsNegative; + int resultIsNegative; char *sp; oopArg = longAt(GIV(stackPointer) + (0 * BytesPerWord)); @@ -61627,7 +61627,7 @@ usqInt prevFree; usqInt prevFreeChunk; usqInt prevPrevFree; - usqInt prevPrevFreeChunk; + sqInt prevPrevFreeChunk; sqInt slotBytes; sqInt slotBytes1; usqInt there; @@ -67437,7 +67437,7 @@ bridgeFromto(SpurSegmentInfo *aSegment, SpurSegmentInfo *nextSegmentOrNil) { usqInt bridgeSpan; - usqInt clifton; + sqInt clifton; usqInt segEnd; segEnd = ((aSegment->segSize)) + ((aSegment->segStart)); @@ -67618,7 +67618,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - usqInt address; + sqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -67681,7 +67681,7 @@ sqInt limit; sqInt newEndOfMemory; sqInt next; - usqInt node; + sqInt node; usqInt numSlots; usqInt numSlots1; SpurSegmentInfo *seg; @@ -68024,8 +68024,8 @@ { usqLong firstSavedBridgeWord; sqInt nWritten; - usqInt pier1; - usqInt pier2; + sqInt pier1; + sqInt pier2; usqLong secondSavedBridgeWord; pier1 = (((segment->segSize)) + ((segment->segStart))) - (2 * BaseHeaderSize); Modified: branches/Cog/nsspur64src/vm/cointerp.h =================================================================== --- branches/Cog/nsspur64src/vm/cointerp.h 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspur64src/vm/cointerp.h 2016-06-01 19:32:08 UTC (rev 3733) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ Modified: branches/Cog/nsspur64src/vm/gcc3x-cointerp.c =================================================================== --- branches/Cog/nsspur64src/vm/gcc3x-cointerp.c 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspur64src/vm/gcc3x-cointerp.c 2016-06-01 19:32:08 UTC (rev 3733) @@ -2,11 +2,11 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e from - CoInterpreter VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CoInterpreter VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -2455,7 +2455,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1872"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1876"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -40939,7 +40939,7 @@ sqInt oopRcvr; sqInt oopResult; usqLong result; - sqInt resultIsNegative; + int resultIsNegative; char *sp; oopArg = longAt(GIV(stackPointer) + (0 * BytesPerWord)); @@ -61636,7 +61636,7 @@ usqInt prevFree; usqInt prevFreeChunk; usqInt prevPrevFree; - usqInt prevPrevFreeChunk; + sqInt prevPrevFreeChunk; sqInt slotBytes; sqInt slotBytes1; usqInt there; @@ -67446,7 +67446,7 @@ bridgeFromto(SpurSegmentInfo *aSegment, SpurSegmentInfo *nextSegmentOrNil) { usqInt bridgeSpan; - usqInt clifton; + sqInt clifton; usqInt segEnd; segEnd = ((aSegment->segSize)) + ((aSegment->segStart)); @@ -67627,7 +67627,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - usqInt address; + sqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -67690,7 +67690,7 @@ sqInt limit; sqInt newEndOfMemory; sqInt next; - usqInt node; + sqInt node; usqInt numSlots; usqInt numSlots1; SpurSegmentInfo *seg; @@ -68033,8 +68033,8 @@ { usqLong firstSavedBridgeWord; sqInt nWritten; - usqInt pier1; - usqInt pier2; + sqInt pier1; + sqInt pier2; usqLong secondSavedBridgeWord; pier1 = (((segment->segSize)) + ((segment->segStart))) - (2 * BaseHeaderSize); Modified: branches/Cog/nsspursrc/vm/cogit.h =================================================================== --- branches/Cog/nsspursrc/vm/cogit.h 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspursrc/vm/cogit.h 2016-06-01 19:32:08 UTC (rev 3733) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1872 uuid: 6db6d610-b1a5-4f4d-978d-22c917bdb3e4 + CCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ Modified: branches/Cog/nsspursrc/vm/cogitARMv5.c =================================================================== --- branches/Cog/nsspursrc/vm/cogitARMv5.c 2016-05-26 20:01:37 UTC (rev 3732) +++ branches/Cog/nsspursrc/vm/cogitARMv5.c 2016-06-01 19:32:08 UTC (rev 3733) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 + CCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e from - StackToRegisterMappingCogit VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 + StackToRegisterMappingCogit VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1860 uuid: 4d58d995-ee0c-4330-9190-adfa038e8f24 " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -39,8 +39,8 @@ #define AndOpcode 0 #define AndRR 91 #define AnnotationShift 5 -#define Arg0Reg 4 -#define Arg1Reg 5 +#define Arg0Reg 3 +#define Arg1Reg 4 #define ArithmeticShiftRightCqR 80 #define ArithmeticShiftRightRR 81 #define BadRegisterSet 1 @@ -52,6 +52,7 @@ #define CArg2Reg 2 #define CArg3Reg 3 #define Call 6 +#define CallerSavedRegisterMask 0x120C #define CallFull 7 #define CC 3 #if !defined(CheckRememberedInTrampoline) /* Allow this to be overridden on the compiler command line */ @@ -61,7 +62,7 @@ #define ClassBlockClosureCompactIndex 37 #define ClassFloatCompactIndex 34 #define ClassMethodContextCompactIndex 36 -#define ClassReg 8 +#define ClassReg 2 #define ClosureFirstCopiedValueIndex 3 #define ClosureIndex 4 #define ClosureNumArgsIndex 2 @@ -73,7 +74,7 @@ #define CMMaxUsageCount 7 #define CMMethod 2 #define CMOpenPIC 5 -#define CMPSMULL 121 +#define CMPSMULL 123 #define CmpC32R 102 #define CmpCqR 94 #define CmpCwR 101 @@ -96,7 +97,9 @@ #define DPFPReg2 2 #define EncounteredUnknownBytecode -6 #define EQ 0 -#define Extra0Reg 9 +#define Extra0Reg 7 +#define Extra1Reg 8 +#define Extra2Reg 9 #define Fill32 4 #define FirstAnnotation 64 #define FirstJump 11 @@ -249,6 +252,7 @@ #define PC 15 #define PCReg 15 #define PL 5 +#define PopLDM 119 #define PopR 72 #define PrefetchAw 76 #define PrimCallCollectsProfileSamples 8 @@ -261,9 +265,10 @@ #define PushCq 74 #define PushCw 75 #define PushR 73 +#define PushSTM 120 #define R0 0 #define ReceiverIndex 5 -#define ReceiverResultReg 7 +#define ReceiverResultReg 5 #define RetN 8 #define RISCTempReg 12 #define RsbOpcode 3 @@ -445,7 +450,6 @@ static sqInt NoDbgRegParms bicsrnimmror(AbstractInstruction * self_in_bicsrnimmror, sqInt destReg, sqInt srcReg, sqInt immediate, sqInt rot); static sqInt NoDbgRegParms bl(AbstractInstruction * self_in_bl, sqInt offset); static sqInt NoDbgRegParms b(AbstractInstruction * self_in_b, sqInt offset); -static sqInt NoDbgRegParms callerSavedRegisterMask(AbstractInstruction * self_in_callerSavedRegisterMask); static sqInt NoDbgRegParms callInstructionByteSize(AbstractInstruction * self_in_callInstructionByteSize); static sqInt NoDbgRegParms callTargetFromReturnAddress(AbstractInstruction * self_in_callTargetFromReturnAddress, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms computeMaximumSize(AbstractInstruction * self_in_computeMaximumSize); @@ -456,6 +460,7 @@ static void NoDbgRegParms concretizeConditionalInstruction(AbstractInstruction * self_in_concretizeConditionalInstruction); static usqInt NoDbgRegParms concretizeFill32(AbstractInstruction * self_in_concretizeFill32); static usqInt NoDbgRegParms concretizeMSR(AbstractInstruction * self_in_concretizeMSR); +static usqInt NoDbgRegParms concretizePushOrPopMultipleRegisters(AbstractInstruction * self_in_concretizePushOrPopMultipleRegisters, sqInt doPush); static usqInt NoDbgRegParms concretizeSMULL(AbstractInstruction * self_in_concretizeSMULL); static sqInt NoDbgRegParms conditionIsNotNever(AbstractInstruction * self_in_conditionIsNotNever, sqInt instr); static sqInt NoDbgRegParms dataOpTyperdrnrmlsr(AbstractInstruction * self_in_dataOpTyperdrnrmlsr, sqInt armOpcode, sqInt destReg, sqInt srcReg, sqInt addReg, sqInt shft); @@ -472,8 +477,6 @@ static AbstractInstruction * NoDbgRegParms genPushRegisterArgsForNumArgsscratchReg(AbstractInstruction * self_in_genPushRegisterArgsForNumArgsscratchReg, sqInt numArgs, sqInt ignored); static sqInt NoDbgRegParms genRemoveNArgsFromStack(AbstractInstruction * self_in_genRemoveNArgsFromStack, sqInt n); static AbstractInstruction * NoDbgRegParms genRestoreRegsExcept(AbstractInstruction * self_in_genRestoreRegsExcept, sqInt abstractReg); -static sqInt NoDbgRegParms genRestoreRegs(AbstractInstruction * self_in_genRestoreRegs, sqInt regMask); -static sqInt NoDbgRegParms genSaveRegs(AbstractInstruction * self_in_genSaveRegs, sqInt regMask); static sqInt NoDbgRegParms genSaveStackPointers(AbstractInstruction * self_in_genSaveStackPointers); static AbstractInstruction * NoDbgRegParms genSubstituteReturnAddress(AbstractInstruction * self_in_genSubstituteReturnAddress, sqInt retpc); static sqInt NoDbgRegParms instructionBeforeAddress(AbstractInstruction * self_in_instructionBeforeAddress, sqInt followingAddress); @@ -569,7 +572,9 @@ static sqInt NoDbgRegParms blockCreationBytecodeSizeForHeader(sqInt aMethodHeader); static sqInt NoDbgRegParms blockDispatchTargetsForperformarg(CogMethod *cogMethod, usqInt (*binaryFunction)(sqInt mcpc, sqInt arg), sqInt arg); extern sqInt bytecodePCForstartBcpcin(sqInt mcpc, sqInt startbcpc, CogBlockMethod *cogMethod); +static AbstractInstruction * NoDbgRegParms CallFullRTregistersToBeSavedMask(sqInt callTarget, sqInt registersToBeSaved); static AbstractInstruction * NoDbgRegParms CallNewspeakSend(sqInt callTarget); +static AbstractInstruction * NoDbgRegParms CallRTregistersToBeSavedMask(sqInt callTarget, sqInt registersToBeSaved); static AbstractInstruction * NoDbgRegParms gCall(sqInt callTarget); static AbstractInstruction * NoDbgRegParms gCmpCqR(sqInt quickConstant, sqInt reg); static AbstractInstruction * NoDbgRegParms gCmpCwR(sqInt wordConstant, sqInt reg); @@ -703,7 +708,7 @@ static AbstractInstruction * NoDbgRegParms gMoveMwrR(sqInt offset, sqInt baseReg, sqInt destReg); static AbstractInstruction * NoDbgRegParms gMoveRMwr(sqInt sourceReg, sqInt offset, sqInt baseReg); static AbstractInstruction * NoDbgRegParms gMoveRR(sqInt reg1, sqInt reg2); -static sqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); +static usqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); static sqInt NoDbgRegParms mapForperformUntilarg(CogMethod *cogMethod, sqInt (*functionSymbol)(sqInt annotation, char *mcpc, sqInt arg), sqInt arg); static sqInt NoDbgRegParms mapObjectReferencesInClosedPIC(CogMethod *cPIC); static void mapObjectReferencesInGeneratedRuntime(void); @@ -734,7 +739,7 @@ static sqInt NoDbgRegParms needsFrameNever(sqInt stackDelta); static sqInt NoDbgRegParms noAssertMethodClassAssociationOf(sqInt methodPointer); static sqInt noCogMethodsMaximallyMarked(void); -static sqInt NoDbgRegParms noTargetsFreeInClosedPIC(sqInt cPIC); +static sqInt NoDbgRegParms noTargetsFreeInClosedPIC(CogMethod *cPIC); static sqInt NoDbgRegParms outputInstructionsAt(sqInt startAddress); static sqInt NoDbgRegParms outputInstructionsForGeneratedRuntimeAt(sqInt startAddress); static AbstractInstruction * NoDbgRegParms gPopR(sqInt reg); @@ -992,9 +997,7 @@ static sqInt NoDbgRegParms registerMask(SimStackEntry * self_in_registerMask); static sqInt NoDbgRegParms registerOrNone(SimStackEntry * self_in_registerOrNone); static SimStackEntry * NoDbgRegParms storeToReg(SimStackEntry * self_in_storeToReg, sqInt reg); -static sqInt NoDbgRegParms isBackwardBranchFixup(BytecodeFixup * self_in_isBackwardBranchFixup); static sqInt NoDbgRegParms isMergeFixup(BytecodeFixup * self_in_isMergeFixup); -static sqInt NoDbgRegParms isMergeFixupOrIsFixedUp(BytecodeFixup * self_in_isMergeFixupOrIsFixedUp); static AbstractInstruction * NoDbgRegParms allocateLiteral(sqInt aLiteral); static AbstractInstruction * NoDbgRegParms checkLiteralforInstruction(sqInt literal, AbstractInstruction *anInstruction); static sqInt NoDbgRegParms dumpLiterals(sqInt generateBranchAround); @@ -1117,6 +1120,9 @@ static CogMethod * NoDbgRegParms compileCogMethod(sqInt selector); static sqInt compileEntireMethod(void); static void compileFrameBuild(void); +#if IMMUTABILITY +static void compileTwoPathFrameBuild(void); +#endif /* IMMUTABILITY */ static sqInt NoDbgRegParms cPICMissTrampolineFor(sqInt numArgs); static sqInt doubleExtendedDoAnythingBytecode(void); static sqInt duplicateTopBytecode(void); @@ -1251,7 +1257,6 @@ static sqInt bytecodeSetOffset; void * CFramePointer; void * CStackPointer; -static sqInt callerSavedRegMask; static sqInt cbEntryOffset; static sqInt cbNoSwitchEntryOffset; sqInt ceBaseFrameReturnTrampoline; @@ -1314,6 +1319,7 @@ static sqInt debugFixupBreaks; static sqInt debugOpcodeIndices; unsigned long debugPrimCallStackOffset; +static sqInt debugStackPointers; static sqInt disassemblingMethod; static sqInt dynamicSuperSendTrampolines[NumSendTrampolines]; static AbstractInstruction * endCPICCase0; @@ -1877,6 +1883,7 @@ sqInt missOffset; static usqInt mzFreeStart; static sqInt needsFrame; +static sqInt needsTwoPath; static sqInt nextLiteralIndex; static AbstractInstruction * noCheckEntry; static sqInt numAbstractOpcodes; @@ -1938,7 +1945,6 @@ #define blockAlignment(self) 8 #define blockStartAt(index) (&blockStarts[index]) #define breakOnImplicitReceiver() (traceFlags & 64) -#define callerSavedRegMask() callerSavedRegMask #define ceBaseFrameReturnPC() ceBaseFrameReturnTrampoline #define ceCannotResumePC() ((usqInt)ceCannotResumeTrampoline) #define ceCheckFeatures() ceCheckFeaturesFunction() @@ -2341,6 +2347,12 @@ if (!(liveRegsMask & (1L << Extra0Reg))) { return Extra0Reg; } + if (!(liveRegsMask & (1L << Extra1Reg))) { + return Extra1Reg; + } + if (!(liveRegsMask & (1L << Extra2Reg))) { + return Extra2Reg; + } if (!(liveRegsMask & (1L << Arg1Reg))) { return Arg1Reg; } @@ -2399,23 +2411,6 @@ } -/* According to IHI0042E ARM Architecture Procedure Calling Standard, in - section 5.1.1: - A subroutine must preserve the contents of the registers r4-r8, r10, r11 - and SP (and r9 in PCS variants that designate r9 as v6). - SP = r13, so the callee-saved regs are r4-r8 & r10-r12. - The caller-saved registers are those that are not callee-saved and not - reserved for hardware/abi uses, - i..e r0-r3, r9 & r12. */ - - /* CogARMCompiler>>#callerSavedRegisterMask */ -static sqInt NoDbgRegParms -callerSavedRegisterMask(AbstractInstruction * self_in_callerSavedRegisterMask) -{ - return (((((1L << 0) | (1L << 1)) | (1L << 2)) | (1L << 3)) | (1L << 9)) | (1L << 12); -} - - /* ARM calls and jumps span +/- 32 mb, more than enough for intra-zone calls and jumps. */ @@ -2533,6 +2528,8 @@ case SMULL: case MSR: case CMPSMULL: + case PopLDM: + case PushSTM: case MoveRR: case MoveRdRd: case MoveXbrRR: @@ -2851,7 +2848,18 @@ return ((self_in_concretizeMSR->machineCodeSize) = 4); } + /* CogARMCompiler>>#concretizePushOrPopMultipleRegisters: */ +static usqInt NoDbgRegParms +concretizePushOrPopMultipleRegisters(AbstractInstruction * self_in_concretizePushOrPopMultipleRegisters, sqInt doPush) +{ + assert((((self_in_concretizePushOrPopMultipleRegisters->operands))[0]) != 0); + ((self_in_concretizePushOrPopMultipleRegisters->machineCode))[0] = ((((AL << 28) + ((doPush + ? 146L << 20 + : 139L << 20))) + (SP << 16)) + (((self_in_concretizePushOrPopMultipleRegisters->operands))[0])); + return ((self_in_concretizePushOrPopMultipleRegisters->machineCodeSize) = 4); +} + /* Generate an SMULL loResultReg, hiResultReg, srcA, srcB instruction */ /* CogARMCompiler>>#concretizeSMULL */ @@ -5008,6 +5016,14 @@ concretizeMSR(self_in_dispatchConcretize); return; + case PopLDM: + concretizePushOrPopMultipleRegisters(self_in_dispatchConcretize, 0); + return; + + case PushSTM: + concretizePushOrPopMultipleRegisters(self_in_dispatchConcretize, 1); + return; + case MoveCqR: /* begin concretizeMoveCqR */ word2 = ((self_in_dispatchConcretize->operands))[0]; @@ -5838,7 +5854,6 @@ static AbstractInstruction * NoDbgRegParms genDivRRQuoRem(AbstractInstruction * self_in_genDivRRQuoRem, sqInt abstractRegDivisor, sqInt abstractRegDividend, sqInt abstractRegQuotient, sqInt abstractRegRemainder) { - sqInt callTarget; usqInt divRemFunctionAddr; AbstractInstruction * inst; sqInt rDividend; @@ -5876,12 +5891,8 @@ self_in_saveAndRestoreLinkRegAround = ((AbstractInstruction *) (backEnd())); /* begin PushR: */ inst = genoperand(PushR, LinkReg); - /* begin CallFullRT: */ - callTarget = ((usqInt)divRemFunctionAddr); - /* begin CallFull: */ @@ Diff output truncated at 50000 characters. @@ From eliot.miranda at gmail.com Wed Jun 1 19:35:40 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 1 19:35:42 2016 Subject: [Vm-dev] Fwd: [vm-dev-owner@lists.squeakfoundation.org: Re: Amazing ARM simulator experience] In-Reply-To: <20160601191235.F04504E0087@marimba.at.major2nd.com> References: <20160601191235.F04504E0087@marimba.at.major2nd.com> Message-ID: ---------- Forwarded message ---------- From: ghost Date: Wed, Jun 1, 2016 at 12:12 PM Subject: [vm-dev-owner@lists.squeakfoundation.org: Re: Amazing ARM simulator experience] To: eliot.miranda@gmail.com Eliot, please pass this along to the mailing list if you like. Thanks- P. From: ghost To: Eliot Miranda CC: vm-dev@lists.squeakfoundation.org In-reply-to: < CAC20JE1dBwTXJNxOaiLbwhU8O8eeTV4Wg_AJtUSuA2ZO4bkKtA@mail.gmail.com> (message from Eliot Miranda on Wed, 1 Jun 2016 10:43:24 -0700) Subject: Re: Amazing ARM simulator experience Date: Wed, 1 Jun 2016 12:11:29 -0700 (PDT) Eliot, I can't top your adventure, but I have a similar experience to share. As part of work I was doing on binary code decompilation, for each ISA I had to build a translator from binary code into something fairly close to C parse trees. Now, I didn't intend these trees to be used for anything other than analysis, but it turned out to be pretty easy to actually execute them. The project is all written in JavaScript*, and compiling the trees into JavaScript code turned out to only require a few hundred lines of code because the primitives are all very low-level and there aren't many of them. So what we have here is binary code, decompiled into machine-oriented JavaScript, which is then executed by Google's v8 JIT compiler. My primo test case was Ghostscript executing "-dNODISPLAY -c 3 4 add = quit", which doesn't look like much but does require loading and initializing the entire graphics rendering system (a good deal of which is written in PostScript and interpreted by GS). This took 522M ARMv7 instructions in 472 seconds, or a bit over 1 MIPS, on a 2014-era x86/64 workstation. I wasn't sure whether to be more impressed by v8, or appalled by how much work GS had to do to get up to speed. -- L Peter Deutsch :: Aladdin Enterprises :: Healdsburg, CA Was your vote really counted? http://www.verifiedvoting.org ---------------------------------------------------------------- *If you want to discuss the choice of JavaScript as implementation language, please e-mail me privately. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/82949255/attachment.htm From bert at freudenbergs.de Wed Jun 1 20:48:35 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 1 20:48:39 2016 Subject: [Vm-dev] Re: [squeak-dev] 2 raisedTo: 100000000` crashes VM In-Reply-To: References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> Message-ID: On 01.06.2016, at 19:45, Eliot Miranda wrote: > (2 raisedTo: 100000000) basicSize > So which VM does it fail on? Mac Spur 5.0.3692 - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4207 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/bb67d584/smime.bin From kilon.alios at gmail.com Wed Jun 1 22:07:41 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Wed Jun 1 22:07:53 2016 Subject: [Vm-dev] Amazing ARM simulator experience In-Reply-To: References: Message-ID: My first computer that my father bought me in 1988 was an Amstrad CPC 6128 , with a 4 Mhz CPU and 128kb Ram My latest computer is a late 2013 quad core 3 Ghz iMac with 8 gb memory. Which makes it at least 3000 times faster than my Amstrad , technology has come a long way the past 30 years. I could not imagine this future even in my wildest dreams. By Gdb you mean the GNU debugger ? On Wed, Jun 1, 2016 at 8:43 PM Eliot Miranda wrote: > > Hi All, > > just had to tell people about this morning's experience using the ARM > simulator. I've been building Smalltalk VMs since 1983, so 33 years. My > first on the Three Rivers PERQ was dog slow. My undergraduate project was > done the the National Semiconductor 32016 based Whitechapel Computer Works > workstation and its and 32032-based successor. > > This morning I was revamping register management in Cog's ARMv5/v6 back > end, making more registers available by using two of the C argument > registers for two of registers the Cogit assigns to various fixed tasks, > and using store and load multiple instructions to save and restore > concisely the registers around calls into the runtime. > > Remember the architecture here. The simulator generates ARM machine code > into the ByteArray that re[resents the address space, holding all of > generated machine code, a small C stack, and the Smalltalk heap. A plugin, > derived from Gdb's ARM simulator written in C, interprets that machine > code, running for a couple of milliseconds at a time in a loop, applying > breakpoint calculations, and asserts on every call into the run-time, and > that calls into the run-time and accesses of variables in the simulator is > done by using illegal addresses in the generated machine code. Each > illegal access causes the Gdb-derived machine code interpreter to return > with an error, this error is turned into an exception, the handler for > which maps the specific illegal address into a variable or message > selector, accesses the variable or activates the message selector, > providing the result, and allowing the execution to continue. > > In changing the register management I had a test case that worked, an > image that prompted for an expression ands evaluated it, which worked both > in the simulator and with the generated VM. But the real VM, crashed when > used on a proper image. So to debug I started launching the real > interactive image in the simulator. > > Well, the amazing experience is that that image, whose machine code is > being _interpreted by a C program_ feels /faster/ than my 32016 based > implementation back in 1984-ish. Quite amazing. I can open windows, type > text, access source code (was playing with Message Names) etc. It's > sluggish, but usable. Amazing how fast modern machines are. All on my > 2012 vintage 2.2 Ghz Core i7 MacBook Pro. I'm blown away :-) > > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/fbe9b91f/attachment.htm From commits at source.squeak.org Wed Jun 1 23:47:26 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 1 23:47:28 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1877.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1877.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1877 Author: eem Time: 1 June 2016, 4:45:31.895746 pm UUID: 638b0433-98fd-4fdf-8b75-588d6c09081f Ancestors: VMMaker.oscog-eem.1876 Cogit: revise Clément's two-path code for immutability to allow it to be used for frameless setters containing more than one inst var store, avoiding multiple store checks by checking once for the receiver being young. Good for a 4% speedup in the binary tree benchmark. Rename needsTwoPath to useTwoPaths. Refactor StackToRegisterMappingCogit>>scanMethod so that it is used by RegisterMappingCogit and SistaCogit without having to duplicate an already large method with very minor varations three times. Add an isInstVarStore property to CogBytecodeDescriptor and set it in the bytecode tables. Fix bug in ARM's concretizeSqrtRd. Fix Slang bug detabbing empty expansions in cppIf:ifTrue:ifFalse:. =============== Diff against VMMaker.oscog-eem.1876 =============== Item was changed: ----- Method: CCodeGenerator>>generateInlineCppIfElse:asArgument:on:indent: (in category 'C translation') ----- generateInlineCppIfElse: msgNode asArgument: asArgument on: aStream indent: level "Generate the C code for this message onto the given stream." | expr putStatement | "Compile-time expansion for constants set in the options dictionary, e.g. to cut down on noise for MULTIPLEBYTECODESETS." putStatement := asArgument ifTrue: "emitCCodeAsArgumentOn: doesn't indent, the code needs indenting if it takes multiple lines, so post-process." [[:node| | expansion | expansion := String streamContents: [:s| node emitCCodeAsArgumentOn: s level: level generator: self]. aStream nextPutAll: ((expansion includes: Character cr) ifTrue: [(String streamContents: [:s| s position > 0 ifTrue: [s tab: level + 1]. node emitCCodeAsArgumentOn: s level: level generator: self]) copyReplaceAll: (String with: Character cr) with: (String with: Character cr), (String new: level + 1 withAll: Character tab)] ifFalse: [expansion])]] ifFalse: [[:node| | expansion | expansion := String streamContents: [:s| node emitCCodeOn: s level: level generator: self]. "Remove tabs from first line to avoid indenting a second time" + expansion ifNotEmpty: + [expansion := expansion allButFirst: (expansion findFirst: [:c| c ~~ Character tab]) - 1]. - expansion := expansion allButFirst: (expansion findFirst: [:c| c ~~ Character tab]) - 1. aStream nextPutAll: expansion]]. (self nilOrBooleanConditionFor: msgNode) ifNotNil: [:condition| condition ifTrue: [putStatement value: msgNode args second] ifFalse: [msgNode args size >= 3 ifTrue: [putStatement value: msgNode args third]]. ^self]. "Full #if ... #else..." putStatement := asArgument ifTrue: "emitCCodeAsArgumentOn: doesn't indent, the code needs indenting in this case, so post-process." [[:node| aStream nextPutAll: ((String streamContents: [:s| s next: level + 1 put: Character tab. node emitCCodeAsArgumentOn: s level: level generator: self]) copyReplaceAll: (String with: Character cr) with: (String with: Character cr), (String new: level + 1 withAll: Character tab))]] ifFalse: [[:node| node emitCCodeOn: aStream level: level generator: self]]. expr := String streamContents: [:es| msgNode args first emitCCodeAsArgumentOn: es level: 0 generator: self]. [expr last isSeparator] whileTrue: [expr := expr allButLast]. aStream ensureCr; nextPut: $#; next: level * 2 put: Character space; nextPutAll: 'if '; nextPutAll: expr; cr. self with: msgNode args first ifAppropriateSetTo: true do: [putStatement value: msgNode args second]. expr := ' /* ', expr, ' */'. msgNode args size >= 3 ifTrue: [aStream ensureCr; nextPut: $#; next: level * 2 put: Character space; nextPutAll: 'else'; nextPutAll: expr; cr. self with: msgNode args first ifAppropriateSetTo: false do: [putStatement value: msgNode args third]]. aStream ensureCr; nextPut: $#; next: level * 2 put: Character space; nextPutAll: 'endif'; nextPutAll: expr; cr. asArgument ifTrue: [aStream next: level + 1 put: Character tab]! Item was changed: ----- Method: CogARMCompiler>>concretizeSqrtRd (in category 'generate machine code - concretize') ----- concretizeSqrtRd "Will get inlined into concretizeAt: switch." "Square root of FP regLHS into regLHS" | regLHS | + regLHS := operands at: 0. - regLHS := operands at: 1. machineCode at: 0 put:(self fsqrtd: regLHS). ^machineCodeSize := 4 ! Item was changed: VMStructType subclass: #CogBytecodeDescriptor + instanceVariableNames: 'generator spanFunction needsFrameFunction stackDelta opcode numBytes isBranchTrue isBranchFalse isReturn isBlockCreation isMapped isMappedInBlock isExtension isInstVarRef isInstVarStore hasIRC' - instanceVariableNames: 'generator spanFunction needsFrameFunction stackDelta opcode numBytes isBranchTrue isBranchFalse isReturn isBlockCreation isMapped isMappedInBlock isExtension isInstVarRef hasIRC' classVariableNames: '' poolDictionaries: '' category: 'VMMaker-JIT'! !CogBytecodeDescriptor commentStamp: 'eem 11/18/2010 06:32' prior: 0! I am an entry in the Cogit's dispatch table for bytecodes. I hold the routine to call to generate code for the partcular bytecode I represent and the number of bytes the bytecode has. For eliminating temps in frameless blocks I maintain a stack delta for bytecodes that are valid in a frameless block. The order of my instance variables is chosen for compact struct packing.! Item was added: + ----- Method: CogBytecodeDescriptor>>isInstVarStore (in category 'accessing') ----- + isInstVarStore + "Answer the value of isInstVarStore" + + ^ isInstVarStore! Item was added: + ----- Method: CogBytecodeDescriptor>>isInstVarStore: (in category 'accessing') ----- + isInstVarStore: anObject + "Set the value of isInstVarStore" + + ^isInstVarStore := anObject! Item was added: + ----- Method: CogObjectRepresentationForSpur>>genJumpInOldSpace: (in category 'compile abstract instructions') ----- + genJumpInOldSpace: reg + "Jump if reg is old." + + ^cogit + CmpCq: objectMemory storeCheckBoundary R: reg; "N.B. FLAGS := destReg - scratchReg" + JumpAboveOrEqual: 0! Item was added: + ----- Method: CogObjectRepresentationForSqueakV3>>genJumpInOldSpace: (in category 'compile abstract instructions') ----- + genJumpInOldSpace: reg + "Jump if reg is old." + + ^cogit + MoveAw: objectMemory youngStartAddress R: TempReg; + CmpR: TempReg R: reg; "N.B. FLAGS := destReg - scratchReg" + JumpBelow: 0! Item was changed: ----- Method: Cogit class>>generatorTableFrom: (in category 'class initialization') ----- generatorTableFrom: anArray | blockCreationBytecodeSize | generatorTable := CArrayAccessor on: (Array new: 256). anArray do: [:tuple| | descriptor | (descriptor := CogBytecodeDescriptor new) numBytes: tuple first; generator: tuple fourth; isReturn: (tuple includes: #return); isMapped: ((tuple includes: #isMappedIfImmutability) ifTrue: [self bindingOf: #IMMUTABILITY] ifFalse: [tuple includes: #isMapped]); isMappedInBlock: (tuple includes: #isMappedInBlock); isBlockCreation: (tuple includes: #block); spanFunction: (((tuple includes: #block) or: [(tuple includes: #branch)]) ifTrue: [tuple detect: [:thing| thing isSymbol and: [thing numArgs = 4]]]); isBranchTrue: (tuple includes: #isBranchTrue); isBranchFalse: (tuple includes: #isBranchFalse); isExtension: (tuple includes: #extension); isInstVarRef: (tuple includes: #isInstVarRef); "for Spur" + isInstVarStore: (tuple includes: #isInstVarStore); "for Spur" hasIRC: (tuple includes: #hasIRC); "for Newspeak" yourself. "As a hack to cut down on descriptor flags, use opcode to tag unusedBytecode for scanning. Currently descriptors are exactly 16 bytes with all 8 flag bits used (in Newspeak at least 17 bytes, 9 flag bits). As another hack to eliminate a test in scanMethod mark unknowns as extensions." descriptor generator == #unknownBytecode ifTrue: [descriptor opcode: Nop; isExtension: true]. descriptor isBlockCreation ifTrue: [blockCreationBytecodeSize ifNil: [blockCreationBytecodeSize := descriptor numBytes] ifNotNil: [self assert: blockCreationBytecodeSize = descriptor numBytes]]. tuple do: [:thing| thing isSymbol ifTrue: [(thing beginsWith: #needsFrame) ifTrue: [descriptor needsFrameFunction: thing]. (CogRTLOpcodes classPool at: thing ifAbsent: []) ifNotNil: [:opcode| descriptor opcode: opcode]]]. tuple last isInteger ifTrue: [descriptor stackDelta: tuple last] ifFalse: [descriptor needsFrameFunction ifNotNil: [self error: 'frameless block bytecodes must specify a stack delta']]. tuple second to: tuple third do: [:index| generatorTable at: index put: descriptor]]. BlockCreationBytecodeSize := blockCreationBytecodeSize. ^generatorTable! Item was added: + ----- Method: RegisterAllocatingCogit>>maybeCountFixup (in category 'compile abstract instructions') ----- + maybeCountFixup + + numFixups := numFixups + 1! Item was added: + ----- Method: RegisterAllocatingCogit>>maybeInitNumFixups (in category 'compile abstract instructions') ----- + maybeInitNumFixups + + numFixups := 0! Item was removed: - ----- Method: RegisterAllocatingCogit>>scanMethod (in category 'compile abstract instructions') ----- - scanMethod - "Overrides to count the number of fixups." - "Scan the method (and all embedded blocks) to determine - - what the last bytecode is; extra bytes at the end of a method are used to encode things like source pointers or temp names - - if the method needs a frame or not - - what are the targets of any backward branches. - - how many blocks it creates - Answer the block count or on error a negative error code" - | latestContinuation nExts descriptor pc numBlocks distance targetPC framelessStackDelta | - - needsFrame := false. - numFixups := 0. - prevBCDescriptor := nil. - self - cppIf: IMMUTABILITY - ifTrue: [needsTwoPath := false]. - NewspeakVM ifTrue: - [numIRCs := 0]. - (primitiveIndex > 0 - and: [coInterpreter isQuickPrimitiveIndex: primitiveIndex]) ifTrue: - [^0]. - pc := latestContinuation := initialPC. - numBlocks := framelessStackDelta := nExts := extA := extB := 0. - [pc <= endPC] whileTrue: - [byte0 := (objectMemory fetchByte: pc ofObject: methodObj) + bytecodeSetOffset. - descriptor := self generatorAt: byte0. - descriptor isExtension ifTrue: - [descriptor opcode = Nop ifTrue: "unknown bytecode tag; see Cogit class>>#generatorTableFrom:" - [^EncounteredUnknownBytecode]. - self loadSubsequentBytesForDescriptor: descriptor at: pc. - self perform: descriptor generator]. - (descriptor isReturn - and: [pc >= latestContinuation]) ifTrue: - [endPC := pc]. - self - cppIf: IMMUTABILITY - ifTrue: [(needsFrame and: [needsTwoPath not]) - ifFalse: [(descriptor needsFrameFunction isNil - or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) - ifTrue: [needsFrame := true. - needsTwoPath := descriptor generator == #genStoreAndPopReceiverVariableBytecode] - ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta]]] - ifFalse: [needsFrame - ifFalse: [(descriptor needsFrameFunction isNil - or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) - ifTrue: [needsFrame := true] - ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta]]]. - descriptor isBranch ifTrue: - [distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. - targetPC := pc + descriptor numBytes + distance. - (self isBackwardBranch: descriptor at: pc exts: nExts in: methodObj) - ifTrue: [self initializeFixupAt: targetPC - initialPC] - ifFalse: - [latestContinuation := latestContinuation max: targetPC. - numFixups := numFixups + 1]]. - descriptor isBlockCreation ifTrue: - [numBlocks := numBlocks + 1. - distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. - targetPC := pc + descriptor numBytes + distance. - latestContinuation := latestContinuation max: targetPC. - numFixups := numFixups + 1]. - NewspeakVM ifTrue: - [descriptor hasIRC ifTrue: - [numIRCs := numIRCs + 1]]. - pc := pc + descriptor numBytes. - descriptor isExtension - ifTrue: [nExts := nExts + 1] - ifFalse: [nExts := extA := extB := 0]. - prevBCDescriptor := descriptor]. - ^numBlocks! Item was added: + ----- Method: SistaCogit>>maybeCountCounter (in category 'compile abstract instructions') ----- + maybeCountCounter + + numCounters := numCounters + 1! Item was added: + ----- Method: SistaCogit>>maybeInitNumCounters (in category 'compile abstract instructions') ----- + maybeInitNumCounters + + numCounters := 0! Item was removed: - ----- Method: SistaCogit>>scanMethod (in category 'compile abstract instructions') ----- - scanMethod - "Scan the method (and all embedded blocks) to determine - - what the last bytecode is; extra bytes at the end of a method are used to encode things like source pointers or temp names - - if the method needs a frame or not - - what are the targets of any backward branches. - - how many blocks it creates - - how many counters it needs/conditional branches it contains - Answer the block count or on error a negative error code" - | latestContinuation nExts descriptor pc numBlocks distance targetPC framelessStackDelta numFixups | - - self flag: 'numFixup should be reverted to inst var when moving back sistaCogit as subclass of RegisterAllocatingCogit'. - needsFrame := false. - numFixups := 0. - prevBCDescriptor := nil. - numCounters := 0. - self - cppIf: IMMUTABILITY - ifTrue: [needsTwoPath := false]. - NewspeakVM ifTrue: - [numIRCs := 0]. - (primitiveIndex > 0 - and: [coInterpreter isQuickPrimitiveIndex: primitiveIndex]) ifTrue: - [^0]. - pc := latestContinuation := initialPC. - numBlocks := framelessStackDelta := nExts := extA := extB := 0. - [pc <= endPC] whileTrue: - [byte0 := (objectMemory fetchByte: pc ofObject: methodObj) + bytecodeSetOffset. - descriptor := self generatorAt: byte0. - descriptor isExtension ifTrue: - [descriptor opcode = Nop ifTrue: "unknown bytecode tag; see Cogit class>>#generatorTableFrom:" - [^EncounteredUnknownBytecode]. - self loadSubsequentBytesForDescriptor: descriptor at: pc. - self perform: descriptor generator]. - (descriptor isReturn - and: [pc >= latestContinuation]) ifTrue: - [endPC := pc]. - self - cppIf: IMMUTABILITY - ifTrue: [(needsFrame and: [needsTwoPath not]) - ifFalse: [(descriptor needsFrameFunction isNil - or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) - ifTrue: [needsFrame := true. - needsTwoPath := descriptor generator == #genStoreAndPopReceiverVariableBytecode] - ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta]]] - ifFalse: [needsFrame - ifFalse: [(descriptor needsFrameFunction isNil - or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) - ifTrue: [needsFrame := true] - ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta]]]. - descriptor isBranch ifTrue: - [distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. - targetPC := pc + descriptor numBytes + distance. - (self isBackwardBranch: descriptor at: pc exts: nExts in: methodObj) - ifTrue: [self initializeFixupAt: targetPC - initialPC] - ifFalse: - [latestContinuation := latestContinuation max: targetPC. - numFixups := numFixups + 1. - (descriptor isBranchTrue or: [descriptor isBranchFalse]) ifTrue: - [numCounters := numCounters + 1]]]. - descriptor isBlockCreation ifTrue: - [numBlocks := numBlocks + 1. - distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. - targetPC := pc + descriptor numBytes + distance. - latestContinuation := latestContinuation max: targetPC. - numFixups := numFixups + 1]. - NewspeakVM ifTrue: - [descriptor hasIRC ifTrue: - [numIRCs := numIRCs + 1]]. - pc := pc + descriptor numBytes. - descriptor isExtension - ifTrue: [nExts := nExts + 1] - ifFalse: [nExts := extA := extB := 0]. - prevBCDescriptor := descriptor]. - ^numBlocks! Item was changed: SimpleStackBasedCogit subclass: #StackToRegisterMappingCogit + instanceVariableNames: 'prevBCDescriptor numPushNilsFunction pushNilSizeFunction methodOrBlockNumTemps regArgsHaveBeenPushed simSelf simStack simStackPtr simSpillBase optStatus ceCallCogCodePopReceiverArg0Regs ceCallCogCodePopReceiverArg1Arg0Regs methodAbortTrampolines picAbortTrampolines picMissTrampolines ceCall0ArgsPIC ceCall1ArgsPIC ceCall2ArgsPIC debugStackPointers debugFixupBreaks realCECallCogCodePopReceiverArg0Regs realCECallCogCodePopReceiverArg1Arg0Regs deadCode useTwoPaths' - instanceVariableNames: 'prevBCDescriptor numPushNilsFunction pushNilSizeFunction methodOrBlockNumTemps regArgsHaveBeenPushed simSelf simStack simStackPtr simSpillBase optStatus ceCallCogCodePopReceiverArg0Regs ceCallCogCodePopReceiverArg1Arg0Regs methodAbortTrampolines picAbortTrampolines picMissTrampolines ceCall0ArgsPIC ceCall1ArgsPIC ceCall2ArgsPIC debugStackPointers debugFixupBreaks realCECallCogCodePopReceiverArg0Regs realCECallCogCodePopReceiverArg1Arg0Regs deadCode needsTwoPath' classVariableNames: 'NeedsMergeFixupFlag NeedsNonMergeFixupFlag' poolDictionaries: 'CogCompilationConstants VMMethodCacheConstants VMObjectIndices VMStackFrameOffsets' category: 'VMMaker-JIT'! StackToRegisterMappingCogit class instanceVariableNames: 'numPushNilsFunction pushNilSizeFunction'! + !StackToRegisterMappingCogit commentStamp: 'eem 6/1/2016 14:50' prior: 0! - !StackToRegisterMappingCogit commentStamp: 'eem 12/19/2010 18:12' prior: 0! StackToRegisterMappingCogit is an optimizing code generator that eliminates a lot of stack operations and inlines some special selector arithmetic. It does so by a simple stack-to-register mapping scheme based on deferring the generation of code to produce operands until operand-consuming operations. The operations that consume operands are sends, stores and returns. See methods in the class-side documentation protocol for more detail. Instance Variables callerSavedRegMask: ceEnter0ArgsPIC: ceEnter1ArgsPIC: ceEnter2ArgsPIC: ceEnterCogCodePopReceiverArg0Regs: ceEnterCogCodePopReceiverArg1Arg0Regs: debugBytecodePointers: debugFixupBreaks: debugStackPointers: methodAbortTrampolines: methodOrBlockNumTemps: optStatus: picAbortTrampolines: picMissTrampolines: realCEEnterCogCodePopReceiverArg0Regs: realCEEnterCogCodePopReceiverArg1Arg0Regs: regArgsHaveBeenPushed: simSelf: simSpillBase: simStack: simStackPtr: traceSimStack: + useTwoPaths callerSavedRegMask - the bitmask of the ABI's caller-saved registers ceEnter0ArgsPIC ceEnter1ArgsPIC ceEnter2ArgsPIC - the trampoline for entering an N-arg PIC ceEnterCogCodePopReceiverArg0Regs ceEnterCogCodePopReceiverArg1Arg0Regs - teh trampoline for entering a method with N register args debugBytecodePointers - a Set of bytecode pcs for setting breakpoints (simulation only) debugFixupBreaks - a Set of fixup indices for setting breakpoints (simulation only) debugStackPointers - an Array of stack depths for each bytecode for code verification methodAbortTrampolines - a CArrayAccessor of abort trampolines for 0, 1, 2 and N args methodOrBlockNumTemps - the number of method or block temps (including args) in the current compilation unit (method or block) optStatus - the variable used to track the status of ReceiverResultReg for avoiding reloading that register with self between adjacent inst var accesses picAbortTrampolines - a CArrayAccessor of abort trampolines for 0, 1, 2 and N args picMissTrampolines - a CArrayAccessor of abort trampolines for 0, 1, 2 and N args realCEEnterCogCodePopReceiverArg0Regs realCEEnterCogCodePopReceiverArg1Arg0Regs - the real trampolines for ebtering machine code with N reg args when in the Debug regime regArgsHaveBeenPushed - whether the register args have been pushed before frame build (e.g. when an interpreter primitive is called) simSelf - the simulation stack entry representing self in the current compilation unit simSpillBase - the variable tracking how much of the simulation stack has been spilled to the real stack simStack - the simulation stack itself simStackPtr - the pointer to the top of the simulation stack + + useTwoPaths + - a variable controlling whether to create two paths through a method based on the existence of inst var stores. With immutability this causes a frameless path to be generated if an otherwise frameless method is frameful simply because of inst var stores. In this case the test to take the first frameless path is if the receiver is not immutable. Without immutability, if a frameless method contains two or more inst var stores, the first path will be code with no store check, chosen by a single check for the receiver being in new space. ! StackToRegisterMappingCogit class instanceVariableNames: 'numPushNilsFunction pushNilSizeFunction'! Item was changed: ----- Method: StackToRegisterMappingCogit class>>initializeBytecodeTableForNewspeakV4 (in category 'class initialization') ----- initializeBytecodeTableForNewspeakV4 "StackToRegisterMappingCogit initializeBytecodeTableForNewspeakV4" numPushNilsFunction := #v4:Num:Push:Nils:. pushNilSizeFunction := #v4PushNilSize:numInitialNils:. NSSendIsPCAnnotated := true. "IsNSSendCall used by SendAbsentImplicit" FirstSpecialSelector := 80. NumSpecialSelectors := 32. self flag: 'Special selector send class must be inlined to agree with the interpreter, which inlines class. If class is sent to e.g. a general instance of ProtoObject then unless class is inlined there will be an MNU. It must be that the Cointerpreter and Cogit have identical semantics. We get away with not hardwiring the other special selectors either because in the Cointerpreter they are not inlined or because they are inlined only to instances of classes for which there will always be a method.'. self generatorTableFrom: #( "1 byte bytecodes" (1 0 15 genPushReceiverVariableBytecode isInstVarRef needsFrameNever: 1) (1 16 31 genPushLiteralVariable16CasesBytecode needsFrameNever: 1) (1 32 63 genPushLiteralConstantBytecode needsFrameNever: 1) (1 64 75 genPushTemporaryVariableBytecode needsFrameIfMod16GENumArgs: 1) (1 76 76 genPushReceiverBytecode needsFrameNever: 1) (1 77 77 genExtPushPseudoVariableOrOuterBytecode needsFrameIfExtBGT2: 1) (1 78 78 genPushConstantZeroBytecode needsFrameNever: 1) (1 79 79 genPushConstantOneBytecode needsFrameNever: 1) (1 80 80 genSpecialSelectorArithmetic isMapped AddRR) (1 81 81 genSpecialSelectorArithmetic isMapped SubRR) (1 82 82 genSpecialSelectorComparison isMapped JumpLess) (1 83 83 genSpecialSelectorComparison isMapped JumpGreater) (1 84 84 genSpecialSelectorComparison isMapped JumpLessOrEqual) (1 85 85 genSpecialSelectorComparison isMapped JumpGreaterOrEqual) (1 86 86 genSpecialSelectorComparison isMapped JumpZero) (1 87 87 genSpecialSelectorComparison isMapped JumpNonZero) (1 88 93 genSpecialSelectorSend isMapped) " #* #/ #\\ #@ #bitShift: //" (1 94 94 genSpecialSelectorArithmetic isMapped AndRR) (1 95 95 genSpecialSelectorArithmetic isMapped OrRR) (1 96 101 genSpecialSelectorSend isMapped) "#at: #at:put: #size #next #nextPut: #atEnd" (1 102 102 genSpecialSelectorEqualsEquals needsFrameNever: notMapped -1) "not mapped because it is directly inlined (for now)" (1 103 103 genSpecialSelectorClass needsFrameIfStackGreaterThanOne: notMapped 0) "not mapped because it is directly inlined (for now)" (1 104 111 genSpecialSelectorSend isMapped) "#blockCopy: #value #value: #do: #new #new: #x #y" (1 112 127 genSendLiteralSelector0ArgsBytecode isMapped) (1 128 143 genSendLiteralSelector1ArgBytecode isMapped) (1 144 159 genSendLiteralSelector2ArgsBytecode isMapped) (1 160 175 genSendAbsentImplicit0ArgsBytecode isMapped hasIRC) + (1 176 183 genStoreAndPopReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability needsFrameIfImmutability: -1) - (1 176 183 genStoreAndPopReceiverVariableBytecode isInstVarRef isMappedIfImmutability needsFrameIfImmutability: -1) (1 184 191 genStoreAndPopTemporaryVariableBytecode) (1 192 199 genShortUnconditionalJump branch v3:ShortForward:Branch:Distance:) (1 200 207 genShortJumpIfTrue branch isBranchTrue isMapped "because of mustBeBoolean" v3:ShortForward:Branch:Distance:) (1 208 215 genShortJumpIfFalse branch isBranchFalse isMapped "because of mustBeBoolean" v3:ShortForward:Branch:Distance:) (1 216 216 genReturnReceiver return needsFrameIfInBlock: isMappedInBlock 0) (1 217 217 genReturnTopFromMethod return needsFrameIfInBlock: isMappedInBlock -1) (1 218 218 genExtReturnTopFromBlock return needsFrameNever: -1) (1 219 219 duplicateTopBytecode needsFrameNever: 1) (1 220 220 genPopStackBytecode needsFrameNever: -1) (1 221 221 genExtNopBytecode needsFrameNever: 0) (1 222 223 unknownBytecode) "2 byte bytecodes" (2 224 224 extABytecode extension needsFrameNever: 0) (2 225 225 extBBytecode extension needsFrameNever: 0) (2 226 226 genExtPushReceiverVariableBytecode isInstVarRef) (2 227 227 genExtPushLiteralVariableBytecode needsFrameNever: 1) (2 228 228 genExtPushLiteralBytecode needsFrameNever: 1) (2 229 229 genExtPushIntegerBytecode needsFrameNever: 1) (2 230 230 genLongPushTemporaryVariableBytecode) (2 231 231 genPushNewArrayBytecode) + (2 232 232 genExtStoreReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability) - (2 232 232 genExtStoreReceiverVariableBytecode isInstVarRef isMappedIfImmutability) (2 233 233 genExtStoreLiteralVariableBytecode isMappedIfImmutability) (2 234 234 genLongStoreTemporaryVariableBytecode) + (2 235 235 genExtStoreAndPopReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability) - (2 235 235 genExtStoreAndPopReceiverVariableBytecode isInstVarRef isMappedIfImmutability) (2 236 236 genExtStoreAndPopLiteralVariableBytecode isMappedIfImmutability) (2 237 237 genLongStoreAndPopTemporaryVariableBytecode) (2 238 238 genExtSendBytecode isMapped) (2 239 239 genExtSendSuperBytecode isMapped) (2 240 240 genExtSendAbsentImplicitBytecode isMapped hasIRC) (2 241 241 genExtSendAbsentDynamicSuperBytecode isMapped hasIRC) (2 242 242 genExtUnconditionalJump branch isMapped "because of interrupt check" v4:Long:Branch:Distance:) (2 243 243 genExtJumpIfTrue branch isBranchTrue isMapped "because of mustBeBoolean" v4:Long:Branch:Distance:) (2 244 244 genExtJumpIfFalse branch isBranchFalse isMapped "because of mustBeBoolean" v4:Long:Branch:Distance:) (2 245 245 genExtSendAbsentSelfBytecode isMapped hasIRC) (2 246 248 unknownBytecode) "3 byte bytecodes" (3 249 249 genCallPrimitiveBytecode) (3 250 250 genPushRemoteTempLongBytecode) (3 251 251 genStoreRemoteTempLongBytecode) (3 252 252 genStoreAndPopRemoteTempLongBytecode) (3 253 253 genExtPushClosureBytecode block v4:Block:Code:Size:) (3 254 254 genExtSendAbsentOuterBytecode isMapped hasIRC) (3 255 255 unknownBytecode))! Item was changed: ----- Method: StackToRegisterMappingCogit class>>initializeBytecodeTableForSistaV1 (in category 'class initialization') ----- initializeBytecodeTableForSistaV1 "StackToRegisterMappingCogit initializeBytecodeTableForSistaV1" numPushNilsFunction := #sistaV1:Num:Push:Nils:. pushNilSizeFunction := #sistaV1PushNilSize:numInitialNils:. BytecodeSetHasDirectedSuperSend := true. FirstSpecialSelector := 96. NumSpecialSelectors := 32. self flag: 'Special selector send class must be inlined to agree with the interpreter, which inlines class. If class is sent to e.g. a general instance of ProtoObject then unless class is inlined there will be an MNU. It must be that the Cointerpreter and Cogit have identical semantics. We get away with not hardwiring the other special selectors either because in the Cointerpreter they are not inlined or because they are inlined only to instances of classes for which there will always be a method.'. self generatorTableFrom: #( "1 byte bytecodes" "pushes" (1 0 15 genPushReceiverVariableBytecode isInstVarRef needsFrameNever: 1) (1 16 31 genPushLitVarDirSup16CasesBytecode needsFrameNever: 1) (1 32 63 genPushLiteralConstantBytecode needsFrameNever: 1) (1 64 75 genPushTemporaryVariableBytecode needsFrameIfMod16GENumArgs: 1) (1 76 76 genPushReceiverBytecode needsFrameNever: 1) (1 77 77 genPushConstantTrueBytecode needsFrameNever: 1) (1 78 78 genPushConstantFalseBytecode needsFrameNever: 1) (1 79 79 genPushConstantNilBytecode needsFrameNever: 1) (1 80 80 genPushConstantZeroBytecode needsFrameNever: 1) (1 81 81 genPushConstantOneBytecode needsFrameNever: 1) (1 82 82 genExtPushPseudoVariable) (1 83 83 duplicateTopBytecode needsFrameNever: 1) (1 84 87 unknownBytecode) "returns" (1 88 88 genReturnReceiver return needsFrameIfInBlock: isMappedInBlock 0) (1 89 89 genReturnTrue return needsFrameIfInBlock: isMappedInBlock 0) (1 90 90 genReturnFalse return needsFrameIfInBlock: isMappedInBlock 0) (1 91 91 genReturnNil return needsFrameIfInBlock: isMappedInBlock 0) (1 92 92 genReturnTopFromMethod return needsFrameIfInBlock: isMappedInBlock -1) (1 93 93 genReturnNilFromBlock return needsFrameNever: -1) (1 94 94 genReturnTopFromBlock return needsFrameNever: -1) (1 95 95 genExtNopBytecode needsFrameNever: 0) "sends" (1 96 96 genSpecialSelectorArithmetic isMapped AddRR) (1 97 97 genSpecialSelectorArithmetic isMapped SubRR) (1 98 98 genSpecialSelectorComparison isMapped JumpLess) (1 99 99 genSpecialSelectorComparison isMapped JumpGreater) (1 100 100 genSpecialSelectorComparison isMapped JumpLessOrEqual) (1 101 101 genSpecialSelectorComparison isMapped JumpGreaterOrEqual) (1 102 102 genSpecialSelectorComparison isMapped JumpZero) (1 103 103 genSpecialSelectorComparison isMapped JumpNonZero) (1 104 109 genSpecialSelectorSend isMapped) " #* #/ #\\ #@ #bitShift: //" (1 110 110 genSpecialSelectorArithmetic isMapped AndRR) (1 111 111 genSpecialSelectorArithmetic isMapped OrRR) (1 112 117 genSpecialSelectorSend isMapped) "#at: #at:put: #size #next #nextPut: #atEnd" (1 118 118 genSpecialSelectorEqualsEquals needsFrameNever: notMapped -1) "not mapped because it is directly inlined (for now)" (1 119 119 genSpecialSelectorClass needsFrameIfStackGreaterThanOne: notMapped 0) "not mapped because it is directly inlined (for now)" (1 120 127 genSpecialSelectorSend isMapped) "#blockCopy: #value #value: #do: #new #new: #x #y" (1 128 143 genSendLiteralSelector0ArgsBytecode isMapped) (1 144 159 genSendLiteralSelector1ArgBytecode isMapped) (1 160 175 genSendLiteralSelector2ArgsBytecode isMapped) "jumps" (1 176 183 genShortUnconditionalJump branch v3:ShortForward:Branch:Distance:) (1 184 191 genShortJumpIfTrue branch isBranchTrue isMapped "because of mustBeBoolean" v3:ShortForward:Branch:Distance:) (1 192 199 genShortJumpIfFalse branch isBranchFalse isMapped "because of mustBeBoolean" v3:ShortForward:Branch:Distance:) + (1 200 207 genStoreAndPopReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability needsFrameIfImmutability: -1) - (1 200 207 genStoreAndPopReceiverVariableBytecode isInstVarRef isMappedIfImmutability needsFrameIfImmutability: -1) (1 208 215 genStoreAndPopTemporaryVariableBytecode) (1 216 216 genPopStackBytecode needsFrameNever: -1) (1 217 217 genUnconditionalTrapBytecode isMapped) (1 218 223 unknownBytecode) "2 byte bytecodes" (2 224 224 extABytecode extension) (2 225 225 extBBytecode extension) "pushes" (2 226 226 genExtPushReceiverVariableBytecode isInstVarRef) "Needs a frame for context inst var access" (2 227 227 genExtPushLitVarDirSupBytecode needsFrameNever: 1) (2 228 228 genExtPushLiteralBytecode needsFrameNever: 1) (2 229 229 genLongPushTemporaryVariableBytecode) (2 230 230 genPushClosureTempsBytecode) (2 231 231 genPushNewArrayBytecode) (2 232 232 genExtPushIntegerBytecode needsFrameNever: 1) (2 233 233 genExtPushCharacterBytecode needsFrameNever: 1) "returns" "sends" (2 234 234 genExtSendBytecode isMapped) (2 235 235 genExtSendSuperBytecode isMapped) "sista bytecodes" (2 236 236 unknownBytecode) "jumps" (2 237 237 genExtUnconditionalJump branch isMapped "because of interrupt check" v4:Long:Branch:Distance:) (2 238 238 genExtJumpIfTrue branch isBranchTrue isMapped "because of mustBeBoolean" v4:Long:Branch:Distance:) (2 239 239 genExtJumpIfFalse branch isBranchFalse isMapped "because of mustBeBoolean" v4:Long:Branch:Distance:) "stores" + (2 240 240 genSistaExtStoreAndPopReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability) - (2 240 240 genSistaExtStoreAndPopReceiverVariableBytecode isInstVarRef isMappedIfImmutability) (2 241 241 genSistaExtStoreAndPopLiteralVariableBytecode isMappedIfImmutability) (2 242 242 genLongStoreAndPopTemporaryVariableBytecode) + (2 243 243 genSistaExtStoreReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability) - (2 243 243 genSistaExtStoreReceiverVariableBytecode isInstVarRef isMappedIfImmutability) (2 244 244 genSistaExtStoreLiteralVariableBytecode isMappedIfImmutability) (2 245 245 genLongStoreTemporaryVariableBytecode) (2 246 247 unknownBytecode) "3 byte bytecodes" (3 248 248 genCallPrimitiveBytecode) (3 249 249 unknownBytecode) "reserved for Push Float" (3 250 250 genExtPushClosureBytecode block v4:Block:Code:Size:) (3 251 251 genExtPushRemoteTempOrInstVarLongBytecode) (3 252 252 genExtStoreRemoteTempOrInstVarLongBytecode isMappedIfImmutability) (3 253 253 genExtStoreAndPopRemoteTempOrInstVarLongBytecode isMappedIfImmutability) (3 254 254 genExtJumpIfNotInstanceOfBehaviorsOrPopBytecode branch v4:Long:BranchIfNotInstanceOf:Distance:) (3 255 255 genExtPushFullClosureBytecode))! Item was changed: ----- Method: StackToRegisterMappingCogit class>>initializeBytecodeTableForSqueakV3PlusClosures (in category 'class initialization') ----- initializeBytecodeTableForSqueakV3PlusClosures "StackToRegisterMappingCogit initializeBytecodeTableForSqueakV3PlusClosures" numPushNilsFunction := #v3:Num:Push:Nils:. pushNilSizeFunction := #v3PushNilSize:numInitialNils:. FirstSpecialSelector := 176. NumSpecialSelectors := 32. self flag: 'Special selector send class must be inlined to agree with the interpreter, which inlines class. If class is sent to e.g. a general instance of ProtoObject then unless class is inlined there will be an MNU. It must be that the Cointerpreter and Cogit have identical semantics. We get away with not hardwiring the other special selectors either because in the Cointerpreter they are not inlined or because they are inlined only to instances of classes for which there will always be a method.'. self generatorTableFrom: #( (1 0 15 genPushReceiverVariableBytecode isInstVarRef needsFrameNever: 1) (1 16 31 genPushTemporaryVariableBytecode needsFrameIfMod16GENumArgs: 1) (1 32 63 genPushLiteralConstantBytecode needsFrameNever: 1) (1 64 95 genPushLiteralVariableBytecode needsFrameNever: 1) + (1 96 103 genStoreAndPopReceiverVariableBytecode isInstVarRef isInstVarStore isMappedIfImmutability needsFrameIfImmutability: -1) - (1 96 103 genStoreAndPopReceiverVariableBytecode isInstVarRef isMappedIfImmutability needsFrameIfImmutability: -1) (1 104 111 genStoreAndPopTemporaryVariableBytecode) (1 112 112 genPushReceiverBytecode needsFrameNever: 1) (1 113 113 genPushConstantTrueBytecode needsFrameNever: 1) (1 114 114 genPushConstantFalseBytecode needsFrameNever: 1) (1 115 115 genPushConstantNilBytecode needsFrameNever: 1) (1 116 119 genPushQuickIntegerConstantBytecode needsFrameNever: 1) "method returns in blocks need a frame because of nonlocalReturn:through:" (1 120 120 genReturnReceiver return needsFrameIfInBlock: isMappedInBlock 0) (1 121 121 genReturnTrue return needsFrameIfInBlock: isMappedInBlock 0) (1 122 122 genReturnFalse return needsFrameIfInBlock: isMappedInBlock 0) (1 123 123 genReturnNil return needsFrameIfInBlock: isMappedInBlock 0) (1 124 124 genReturnTopFromMethod return needsFrameIfInBlock: isMappedInBlock -1) (1 125 125 genReturnTopFromBlock return needsFrameNever: -1) (1 126 127 unknownBytecode) (2 128 128 extendedPushBytecode isInstVarRef) "well, maybe inst var ref" (2 129 129 extendedStoreBytecode isInstVarRef isMappedIfImmutability) "well, maybe inst var ref" (2 130 130 extendedStoreAndPopBytecode isInstVarRef isMappedIfImmutability) "well, maybe inst var ref" (2 131 131 genExtendedSendBytecode isMapped) (3 132 132 doubleExtendedDoAnythingBytecode isMapped) "well, maybe inst var ref" (2 133 133 genExtendedSuperBytecode isInstVarRef isMapped) (2 134 134 genSecondExtendedSendBytecode isMapped) (1 135 135 genPopStackBytecode needsFrameNever: -1) (1 136 136 duplicateTopBytecode needsFrameNever: 1) (1 137 137 genPushActiveContextBytecode) (2 138 138 genPushNewArrayBytecode)), ((initializationOptions at: #SpurObjectMemory ifAbsent: [false]) ifTrue: [#((3 139 139 genCallPrimitiveBytecode))] ifFalse: [#((1 139 139 unknownBytecode))]), #( (3 140 140 genPushRemoteTempLongBytecode) (3 141 141 genStoreRemoteTempLongBytecode) (3 142 142 genStoreAndPopRemoteTempLongBytecode) (4 143 143 genPushClosureCopyCopiedValuesBytecode block v3:Block:Code:Size:) (1 144 151 genShortUnconditionalJump branch v3:ShortForward:Branch:Distance:) (1 152 159 genShortJumpIfFalse branch isBranchFalse isMapped "because of mustBeBoolean" v3:ShortForward:Branch:Distance:) (2 160 163 genLongUnconditionalBackwardJump branch isMapped "because of interrupt check" v3:Long:Branch:Distance:) (2 164 167 genLongUnconditionalForwardJump branch v3:Long:Branch:Distance:) (2 168 171 genLongJumpIfTrue branch isBranchTrue isMapped "because of mustBeBoolean" v3:LongForward:Branch:Distance:) (2 172 175 genLongJumpIfFalse branch isBranchFalse isMapped "because of mustBeBoolean" v3:LongForward:Branch:Distance:) (1 176 176 genSpecialSelectorArithmetic isMapped AddRR) (1 177 177 genSpecialSelectorArithmetic isMapped SubRR) (1 178 178 genSpecialSelectorComparison isMapped JumpLess) (1 179 179 genSpecialSelectorComparison isMapped JumpGreater) (1 180 180 genSpecialSelectorComparison isMapped JumpLessOrEqual) (1 181 181 genSpecialSelectorComparison isMapped JumpGreaterOrEqual) (1 182 182 genSpecialSelectorComparison isMapped JumpZero) (1 183 183 genSpecialSelectorComparison isMapped JumpNonZero) (1 184 189 genSpecialSelectorSend isMapped) " #* #/ #\\ #@ #bitShift: //" (1 190 190 genSpecialSelectorArithmetic isMapped AndRR) (1 191 191 genSpecialSelectorArithmetic isMapped OrRR) (1 192 197 genSpecialSelectorSend isMapped) "#at: #at:put: #size #next #nextPut: #atEnd" (1 198 198 genSpecialSelectorEqualsEquals needsFrameNever: notMapped -1) "not mapped because it is directly inlined (for now)" (1 199 199 genSpecialSelectorClass needsFrameIfStackGreaterThanOne: notMapped 0) "not mapped because it is directly inlined (for now)" (1 200 207 genSpecialSelectorSend isMapped) "#blockCopy: #value #value: #do: #new #new: #x #y" (1 208 223 genSendLiteralSelector0ArgsBytecode isMapped) (1 224 239 genSendLiteralSelector1ArgBytecode isMapped) (1 240 255 genSendLiteralSelector2ArgsBytecode isMapped))! Item was changed: ----- Method: StackToRegisterMappingCogit>>compileFrameBuild (in category 'compile abstract instructions') ----- compileFrameBuild "Build a frame for a CogMethod activation. See CoInterpreter class>>initializeFrameIndices. Override to push the register receiver and register arguments, if any." self cppIf: IMMUTABILITY ifTrue: + [useTwoPaths ifTrue: - [needsTwoPath ifTrue: [self compileTwoPathFrameBuild. ^self]]. needsFrame ifFalse: + [useTwoPaths ifTrue: + [self compileTwoPathFramelessInit]. + self initSimStackForFramelessMethod: initialPC. - [self initSimStackForFramelessMethod: initialPC. ^self]. self genPushRegisterArgs. super compileFrameBuild. self initSimStackForFramefulMethod: initialPC! Item was changed: ----- Method: StackToRegisterMappingCogit>>compileTwoPathFrameBuild (in category 'compile abstract instructions') ----- compileTwoPathFrameBuild - "We are in a method where the frame is needed *only* for instance variable store, typically a setter method. This case has 20% overhead with Immutability compared to setter without immutability because of the stack frame creation. We compile two path, one where the object is immutable, one where it isn't. At the beginning of the frame build, we take one path or the other depending on the receiver mutability. Note: this specific case happens only where there are only instance variabel stores. We could do something similar for literal variable stores, but we don't as it's too uncommon." + + | jumpImmutable | - |jumpImmutable| self assert: needsFrame. + self assert: useTwoPaths. - self assert: IMMUTABILITY. - self assert: needsTwoPath. self assert: blockCount = 0. jumpImmutable := objectRepresentation genJumpImmutable: ReceiverResultReg scratchReg: TempReg. "first path. The receiver is mutable" + needsFrame := false. self initSimStackForFramelessMethod: initialPC. self compileMethodBody. "second path. The receiver is mutable" + useTwoPaths := false. "reset because it impacts inst var store compilation" + needsFrame := true. - needsTwoPath := false. "reset because it impact inst var store compilation" jumpImmutable jmpTarget: self Label. self genPushRegisterArgs. super compileFrameBuild. self initSimStackForFramefulMethod: initialPC! Item was added: + ----- Method: StackToRegisterMappingCogit>>compileTwoPathFramelessInit (in category 'compile abstract instructions') ----- + compileTwoPathFramelessInit + "We are in a frameless method with at least two inst var stores. We compile two paths, + one where the object is in new space, and one where it isn't. At the beginning + of the method, we take one path or the other depending on the receiver being in newSpace." + | jumpOld | + self deny: IMMUTABILITY. + self deny: needsFrame. + self assert: useTwoPaths. + jumpOld := objectRepresentation genJumpInOldSpace: ReceiverResultReg. + "first path. The receiver is young" + self initSimStackForFramelessMethod: initialPC. + self compileMethodBody. + "second path. The receiver is old" + useTwoPaths := false. "reset because it impacts inst var store compilation" + jumpOld jmpTarget: self Label! Item was changed: ----- Method: StackToRegisterMappingCogit>>genStorePop:slotIndex:destReg:needsStoreCheck:needsRestoreRcvr: (in category 'bytecode generator support') ----- genStorePop: popBoolean slotIndex: slotIndex destReg: destReg needsStoreCheck: needsStoreCheck needsRestoreRcvr: needsRestoreReceiver "This method expects destReg to hold the object to store into. In practice, it is almost always RcvrResultReg because it is mandatory for the various store checks. We could put any register there if no store check is needed" self cppIf: IMMUTABILITY ifTrue: + [useTwoPaths - [needsTwoPath ifTrue: [self "first path, receiver is mutable" genVanillaStorePop: popBoolean slotIndex: slotIndex destReg: destReg needsStoreCheck: needsStoreCheck] ifFalse: [self genImmCheckStorePop: popBoolean slotIndex: slotIndex destReg: destReg needsStoreCheck: needsStoreCheck needsRestoreRcvr: needsRestoreReceiver]] ifFalse: [self genVanillaStorePop: popBoolean slotIndex: slotIndex destReg: destReg needsStoreCheck: needsStoreCheck]. ! Item was changed: ----- Method: StackToRegisterMappingCogit>>genUpArrowReturn (in category 'bytecode generators') ----- genUpArrowReturn "Generate a method return from within a method or a block. Frameless method activation looks like CISCs (x86): receiver args sp-> ret pc. RISCs (ARM): receiver args ret pc in LR. A fully framed activation is described in CoInterpreter class>initializeFrameIndices. Return pops receiver and arguments off the stack. Callee pushes the result." | framelessReturn | deadCode := true. "can't fall through" inBlock ifTrue: [self assert: needsFrame. self CallRT: ceNonLocalReturnTrampoline. self annotateBytecode: self Label. ^0]. self cppIf: IMMUTABILITY + ifTrue: [framelessReturn := needsFrame and: [useTwoPaths not]] - ifTrue: [framelessReturn := needsFrame and: [needsTwoPath not]] ifFalse: [framelessReturn := needsFrame]. framelessReturn ifTrue: [self MoveR: FPReg R: SPReg. self PopR: FPReg. backEnd hasLinkRegister ifTrue: [self PopR: LinkReg]. self RetN: methodOrBlockNumArgs + 1 * objectMemory wordSize] ifFalse: [self RetN: ((methodOrBlockNumArgs > self numRegArgs "A method with an interpreter prim will push its register args for the prim. If the failure body is frameless the args must still be popped, see e.g. Behavior>>nextInstance." or: [regArgsHaveBeenPushed]) ifTrue: [methodOrBlockNumArgs + 1 * objectMemory wordSize] ifFalse: [0])]. ^0! Item was changed: ----- Method: StackToRegisterMappingCogit>>genVanillaStorePop:slotIndex:destReg:needsStoreCheck: (in category 'bytecode generator support') ----- genVanillaStorePop: popBoolean slotIndex: slotIndex destReg: destReg needsStoreCheck: needsStoreCheck | topReg | + + self cppIf: IMMUTABILITY + ifTrue: [] + ifFalse: "First path, receiver is in newSpace" + [(destReg = ReceiverResultReg and: [needsFrame not and: [useTwoPaths]]) ifTrue: + [topReg := self ssStorePop: popBoolean toPreferredReg: TempReg. + self MoveR: topReg + Mw: slotIndex * objectMemory wordSize + objectMemory baseHeaderSize + r: ReceiverResultReg. + traceStores > 0 ifTrue: + [topReg ~= TempReg ifTrue: + [self MoveR: topReg R: TempReg]. + self CallRT: ceTraceStoreTrampoline]. + ^0]]. + topReg := self allocateRegForStackEntryAt: 0 notConflictingWith: (self registerMaskFor: destReg). self ssStorePop: popBoolean toReg: topReg. objectRepresentation genStoreSourceReg: topReg slotIndex: slotIndex destReg: destReg scratchReg: TempReg inFrame: needsFrame + needsStoreCheck: needsStoreCheck! - needsStoreCheck: needsStoreCheck.! Item was added: + ----- Method: StackToRegisterMappingCogit>>maybeCountCounter (in category 'compile abstract instructions') ----- + maybeCountCounter + "This is a hook for SistaCogit" + ! Item was added: + ----- Method: StackToRegisterMappingCogit>>maybeCountFixup (in category 'compile abstract instructions') ----- + maybeCountFixup + "This is a hook for RegisterAllocatingCogit" + ! Item was added: + ----- Method: StackToRegisterMappingCogit>>maybeInitNumCounters (in category 'compile abstract instructions') ----- + maybeInitNumCounters + "This is a hook for SistaCogit" + ! Item was added: + ----- Method: StackToRegisterMappingCogit>>maybeInitNumFixups (in category 'compile abstract instructions') ----- + maybeInitNumFixups + "This is a hook for RegisterAllocatingCogit" + ! Item was changed: ----- Method: StackToRegisterMappingCogit>>scanMethod (in category 'compile abstract instructions') ----- scanMethod "Scan the method (and all embedded blocks) to determine - what the last bytecode is; extra bytes at the end of a method are used to encode things like source pointers or temp names - if the method needs a frame or not - what are the targets of any backward branches. - how many blocks it creates Answer the block count or on error a negative error code" + | latestContinuation nExts descriptor pc numBlocks distance targetPC framelessStackDelta seenInstVarStore | - | latestContinuation nExts descriptor pc numBlocks distance targetPC framelessStackDelta | + needsFrame := useTwoPaths := seenInstVarStore := false. + self maybeInitNumFixups. + self maybeInitNumCounters. - needsFrame := false. prevBCDescriptor := nil. - self cppIf: IMMUTABILITY ifTrue: [ needsTwoPath := false ]. NewspeakVM ifTrue: [numIRCs := 0]. (primitiveIndex > 0 and: [coInterpreter isQuickPrimitiveIndex: primitiveIndex]) ifTrue: [^0]. pc := latestContinuation := initialPC. numBlocks := framelessStackDelta := nExts := extA := extB := 0. [pc <= endPC] whileTrue: [byte0 := (objectMemory fetchByte: pc ofObject: methodObj) + bytecodeSetOffset. descriptor := self generatorAt: byte0. descriptor isExtension ifTrue: [descriptor opcode = Nop ifTrue: "unknown bytecode tag; see Cogit class>>#generatorTableFrom:" [^EncounteredUnknownBytecode]. self loadSubsequentBytesForDescriptor: descriptor at: pc. self perform: descriptor generator]. (descriptor isReturn and: [pc >= latestContinuation]) ifTrue: [endPC := pc]. + + needsFrame ifFalse: + [(descriptor needsFrameFunction isNil + or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) + ifTrue: + [needsFrame := true. + self cppIf: IMMUTABILITY + ifTrue: [useTwoPaths := descriptor isInstVarStore]] + ifFalse: + [framelessStackDelta := framelessStackDelta + descriptor stackDelta. + self cppIf: IMMUTABILITY + ifTrue: [] + ifFalse: + [descriptor isInstVarStore ifTrue: + [seenInstVarStore + ifTrue: [useTwoPaths := true] + ifFalse: [seenInstVarStore := true]]]]]. + - self cppIf: IMMUTABILITY - ifTrue: - [(needsFrame and: [needsTwoPath not]) ifFalse: - [(descriptor needsFrameFunction isNil - or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) - ifTrue: - [needsFrame := true. - needsTwoPath := descriptor generator == #genStoreAndPopReceiverVariableBytecode ] - ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta]]] - ifFalse: - [needsFrame ifFalse: - [(descriptor needsFrameFunction isNil - or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) - ifTrue: [needsFrame := true] - ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta]]]. - descriptor isBranch ifTrue: [distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. targetPC := pc + descriptor numBytes + distance. (self isBackwardBranch: descriptor at: pc exts: nExts in: methodObj) ifTrue: [self initializeFixupAt: targetPC - initialPC] + ifFalse: + [latestContinuation := latestContinuation max: targetPC. + self maybeCountFixup. + self maybeCountCounter]]. - ifFalse: [latestContinuation := latestContinuation max: targetPC]]. descriptor isBlockCreation ifTrue: [numBlocks := numBlocks + 1. distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. targetPC := pc + descriptor numBytes + distance. + latestContinuation := latestContinuation max: targetPC. + self maybeCountFixup]. + - latestContinuation := latestContinuation max: targetPC]. NewspeakVM ifTrue: [descriptor hasIRC ifTrue: [numIRCs := numIRCs + 1]]. pc := pc + descriptor numBytes. descriptor isExtension ifTrue: [nExts := nExts + 1] ifFalse: [nExts := extA := extB := 0]. prevBCDescriptor := descriptor]. ^numBlocks! From commits at squeakvm.org Wed Jun 1 23:55:06 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Wed Jun 1 23:54:55 2016 Subject: [Vm-dev] [commit][3734] CogVM source as per VMMaker.oscog-eem.1877 Message-ID: Revision: 3734 Author: eliot Date: 2016-06-01 16:55:01 -0700 (Wed, 01 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1877 Cogit: Revise Clement's two-path code for immutability to allow it to be used for frameless setters containing more than one inst var store, avoiding multiple store checks by checking once for the receiver being young. Good for a 4% speedup in the binary tree benchmark. Rename needsTwoPath to useTwoPaths. Refactor StackToRegisterMappingCogit>> scanMethod so that it is used by RegisterMappingCogit and SistaCogit without having to duplicate an already large method with very minor varations 3 times. Add an isInstVarStore property to CogBytecodeDescriptor and set it in the bytecode tables. Fix bug in ARM's concretizeSqrtRd. Modified Paths: -------------- branches/Cog/nsspur64src/vm/cogit.h branches/Cog/nsspur64src/vm/cogitX64.c branches/Cog/nsspursrc/vm/cogit.h branches/Cog/nsspursrc/vm/cogitARMv5.c branches/Cog/nsspursrc/vm/cogitIA32.c branches/Cog/nsspursrc/vm/cogitMIPSEL.c branches/Cog/spur64src/vm/cogit.h branches/Cog/spur64src/vm/cogitX64.c branches/Cog/spursistasrc/vm/cogit.h branches/Cog/spursistasrc/vm/cogitARMv5.c branches/Cog/spursistasrc/vm/cogitIA32.c branches/Cog/spursistasrc/vm/cogitMIPSEL.c branches/Cog/spursrc/vm/cogit.h branches/Cog/spursrc/vm/cogitARMv5.c branches/Cog/spursrc/vm/cogitIA32.c branches/Cog/spursrc/vm/cogitMIPSEL.c branches/Cog/src/vm/cogit.h branches/Cog/src/vm/cogitARMv5.c branches/Cog/src/vm/cogitIA32.c branches/Cog/src/vm/cogitMIPSEL.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Modified: branches/Cog/nsspur64src/vm/cogit.h =================================================================== --- branches/Cog/nsspur64src/vm/cogit.h 2016-06-01 19:32:08 UTC (rev 3733) +++ branches/Cog/nsspur64src/vm/cogit.h 2016-06-01 23:55:01 UTC (rev 3734) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + CCodeGenerator VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f */ Modified: branches/Cog/nsspur64src/vm/cogitX64.c =================================================================== --- branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-01 19:32:08 UTC (rev 3733) +++ branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-01 23:55:01 UTC (rev 3734) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + CCodeGenerator VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f from - StackToRegisterMappingCogit VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + StackToRegisterMappingCogit VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -352,6 +352,7 @@ unsigned isMappedInBlock : 1; unsigned isExtension : 1; unsigned isInstVarRef : 1; + unsigned isInstVarStore : 1; unsigned hasIRC : 1; } BytecodeDescriptor; @@ -1076,6 +1077,7 @@ #if IMMUTABILITY static void compileTwoPathFrameBuild(void); #endif /* IMMUTABILITY */ +static void compileTwoPathFramelessInit(void); static sqInt NoDbgRegParms cPICMissTrampolineFor(sqInt numArgs); static sqInt doubleExtendedDoAnythingBytecode(void); static sqInt duplicateTopBytecode(void); @@ -1292,518 +1294,518 @@ static AbstractInstruction * fullBlockEntry; static AbstractInstruction * fullBlockNoContextSwitchEntry; static BytecodeDescriptor generatorTable[512] = { - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushReceiverBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushConstantTrueBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushConstantFalseBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushConstantNilBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushQuickIntegerConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushQuickIntegerConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushQuickIntegerConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushQuickIntegerConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genReturnReceiver, 0, needsFrameIfInBlock, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genReturnTrue, 0, needsFrameIfInBlock, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genReturnFalse, 0, needsFrameIfInBlock, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genReturnNil, 0, needsFrameIfInBlock, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genReturnTopFromMethod, 0, needsFrameIfInBlock, -1, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genReturnTopFromBlock, 0, needsFrameNever, -1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0 }, - { unknownBytecode, 0, 0, 0, Nop, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { unknownBytecode, 0, 0, 0, Nop, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { extendedPushBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { extendedStoreBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { extendedStoreAndPopBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genExtendedSendBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { doubleExtendedDoAnythingBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genExtendedSuperBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 1, 0 }, - { genSecondExtendedSendBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genPopStackBytecode, 0, needsFrameNever, -1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { duplicateTopBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushActiveContextBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushNewArrayBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genCallPrimitiveBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushRemoteTempLongBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreRemoteTempLongBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopRemoteTempLongBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushClosureCopyCopiedValuesBytecode, v3BlockCodeSize, 0, 0, 0, 4, 0, 0, 0, 1, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genLongUnconditionalBackwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongUnconditionalBackwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongUnconditionalBackwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongUnconditionalBackwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongUnconditionalForwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genLongUnconditionalForwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genLongUnconditionalForwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genLongUnconditionalForwardJump, v3LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genLongJumpIfTrue, v3LongForwardBranchDistance, 0, 0, 0, 2, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfTrue, v3LongForwardBranchDistance, 0, 0, 0, 2, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfTrue, v3LongForwardBranchDistance, 0, 0, 0, 2, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfTrue, v3LongForwardBranchDistance, 0, 0, 0, 2, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfFalse, v3LongForwardBranchDistance, 0, 0, 0, 2, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfFalse, v3LongForwardBranchDistance, 0, 0, 0, 2, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfFalse, v3LongForwardBranchDistance, 0, 0, 0, 2, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genLongJumpIfFalse, v3LongForwardBranchDistance, 0, 0, 0, 2, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, AddRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, SubRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpLess, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpGreater, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpLessOrEqual, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpGreaterOrEqual, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpZero, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpNonZero, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, AndRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, OrRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorEqualsEquals, 0, needsFrameNever, -1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genSpecialSelectorClass, 0, needsFrameIfStackGreaterThanOne, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralVariable16CasesBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushLiteralConstantBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushReceiverBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtPushPseudoVariableOrOuterBytecode, 0, needsFrameIfExtBGT2, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushConstantZeroBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushConstantOneBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, AddRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, SubRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpLess, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpGreater, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpLessOrEqual, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpGreaterOrEqual, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpZero, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorComparison, 0, 0, 0, JumpNonZero, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, AndRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorArithmetic, 0, 0, 0, OrRR, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorEqualsEquals, 0, needsFrameNever, -1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genSpecialSelectorClass, 0, needsFrameIfStackGreaterThanOne, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSpecialSelectorSend, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector1ArgBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendLiteralSelector2ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genSendAbsentImplicit0ArgsBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopReceiverVariableBytecode, 0, needsFrameIfImmutability, -1, 0, 1, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortUnconditionalJump, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfTrue, v3ShortForwardBranchDistance, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genShortJumpIfFalse, v3ShortForwardBranchDistance, 0, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genReturnReceiver, 0, needsFrameIfInBlock, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genReturnTopFromMethod, 0, needsFrameIfInBlock, -1, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0 }, - { genExtReturnTopFromBlock, 0, needsFrameNever, -1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0 }, - { duplicateTopBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPopStackBytecode, 0, needsFrameNever, -1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtNopBytecode, 0, needsFrameNever, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { unknownBytecode, 0, 0, 0, Nop, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { unknownBytecode, 0, 0, 0, Nop, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { extABytecode, 0, needsFrameNever, 0, 0, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { extBBytecode, 0, needsFrameNever, 0, 0, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { genExtPushReceiverVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 1, 0 }, - { genExtPushLiteralVariableBytecode, 0, needsFrameNever, 1, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtPushLiteralBytecode, 0, needsFrameNever, 1, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtPushIntegerBytecode, 0, needsFrameNever, 1, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genLongPushTemporaryVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushNewArrayBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtStoreReceiverVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genExtStoreLiteralVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 0, 0 }, - { genLongStoreTemporaryVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtStoreAndPopReceiverVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 1, 0 }, - { genExtStoreAndPopLiteralVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, IMMUTABILITY, 0, 0, 0, 0 }, - { genLongStoreAndPopTemporaryVariableBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtSendBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genExtSendSuperBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genExtSendAbsentImplicitBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genExtSendAbsentDynamicSuperBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { genExtUnconditionalJump, v4LongBranchDistance, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genExtJumpIfTrue, v4LongBranchDistance, 0, 0, 0, 2, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, - { genExtJumpIfFalse, v4LongBranchDistance, 0, 0, 0, 2, 0, 1, 0, 0, 1, 0, 0, 0, 0 }, - { genExtSendAbsentSelfBytecode, 0, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { unknownBytecode, 0, 0, 0, Nop, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { unknownBytecode, 0, 0, 0, Nop, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { unknownBytecode, 0, 0, 0, Nop, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, - { genCallPrimitiveBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genPushRemoteTempLongBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreRemoteTempLongBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genStoreAndPopRemoteTempLongBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, - { genExtPushClosureBytecode, v4BlockCodeSize, 0, 0, 0, 3, 0, 0, 0, 1, 0, 0, 0, 0, 0 }, - { genExtSendAbsentOuterBytecode, 0, 0, 0, 0, 3, 0, 0, 0, 0, 1, 0, 0, 0, 1 }, - { unknownBytecode, 0, 0, 0, Nop, 3, 0, 0, 0, 0, 0, 0, 1, 0, 0 } + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushReceiverVariableBytecode, 0, needsFrameNever, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0 }, + { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, + { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, + { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, + { genPushTemporaryVariableBytecode, 0, needsFrameIfMod16GENumArgs, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, @@ Diff output truncated at 50000 characters. @@ From commits at source.squeak.org Thu Jun 2 00:58:49 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Jun 2 00:58:50 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1878.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1878.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1878 Author: eem Time: 1 June 2016, 5:56:53.625028 pm UUID: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 Ancestors: VMMaker.oscog-eem.1877 Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. This is clearly unsatisfactory;. the ciode fails to slow Smalltalk code. We'd like to run the GC but Spur's style is not to GC in primitives. If we change the plugin to do GC in primtiives we lose the speed advantage of the no-GC style of code. One approach might be to estimate the memory needed as early as possible, and run a GC if not enough memory is available for the result, recomputing base pointers if GC is run. This would avoid the awful remapOop:in: style whioch is pessimistic; it puts things in a stack and takes them back out whether a GC is needed or not. We shoudl use an optimistic algorithm; especially for something as performance sensitive as large integer arithmetic. =============== Diff against VMMaker.oscog-eem.1877 =============== Item was changed: ----- Method: LargeIntegersPlugin>>digit:Lshift: (in category 'oop functions') ----- digit: anOop Lshift: shiftCount "Attention: this method invalidates all oop's!! Only newOop is valid at return." "Does not normalize." | newOop highBit newDigitLen newByteLen oldDigitLen | oldDigitLen := self digitSizeOfLargeInt: anOop. (highBit := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) len: oldDigitLen) = 0 ifTrue: [^ interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) indexableSize: 1]. newByteLen := highBit + shiftCount + 7 // 8. + self remapOop: anOop in: + [newOop := interpreterProxy + instantiateClass: (interpreterProxy fetchClassOf: anOop) + indexableSize: newByteLen]. + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) - indexableSize: newByteLen]. newDigitLen := newByteLen + 3 // 4. self cDigitLshift: shiftCount from: (self pointerToFirstDigitOfLargeInt: anOop) len: oldDigitLen to: (self pointerToFirstDigitOfLargeInt: newOop) len: newDigitLen. ^ newOop! Item was changed: ----- Method: LargeIntegersPlugin>>digit:Rshift:lookfirst: (in category 'oop functions') ----- digit: anOop Rshift: shiftCount lookfirst: a "Attention: this method invalidates all oop's!! Only newBytes is valid at return." "Shift right 32*digitShift+bitShift bits, 0<=bitShift<32. Discard all digits beyond a, and all zeroes at or below a." "Does not normalize." | newByteLen newOop oldBitLen newBitLen oldDigitLen newDigitLen | oldBitLen := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) len: a. oldDigitLen := oldBitLen + 31 // 32. newBitLen := oldBitLen - shiftCount. newBitLen <= 0 ifTrue: ["All bits lost" ^ interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) indexableSize: 0]. newByteLen := newBitLen + 7 // 8. newDigitLen := newByteLen + 3 // 4. + self remapOop: anOop in: + [newOop := interpreterProxy + instantiateClass: (interpreterProxy fetchClassOf: anOop) + indexableSize: newByteLen]. + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) - indexableSize: newByteLen]. self cDigitRshift: shiftCount from: (self pointerToFirstDigitOfLargeInt: anOop) len: oldDigitLen to: (self pointerToFirstDigitOfLargeInt: newOop) len: newDigitLen. ^ newOop! Item was changed: ----- Method: LargeIntegersPlugin>>digitAddLarge:with: (in category 'oop functions') ----- digitAddLarge: firstInteger with: secondInteger "Does not need to normalize!!" | over firstDigitLen secondDigitLen shortInt shortDigitLen longInt longDigitLen sum newSum neg | firstDigitLen := self digitSizeOfLargeInt: firstInteger. secondDigitLen := self digitSizeOfLargeInt: secondInteger. neg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. firstDigitLen <= secondDigitLen ifTrue: [shortInt := firstInteger. shortDigitLen := firstDigitLen. longInt := secondInteger. longDigitLen := secondDigitLen] ifFalse: [shortInt := secondInteger. shortDigitLen := secondDigitLen. longInt := firstInteger. longDigitLen := firstDigitLen]. " sum := Integer new: len neg: firstInteger negative." self remapOop: #(shortInt longInt ) in: [sum := self createLargeIntegerNeg: neg digitLength: longDigitLen]. + sum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. over := self cDigitAdd: (self pointerToFirstDigitOfLargeInt: shortInt) len: shortDigitLen with: (self pointerToFirstDigitOfLargeInt: longInt) len: longDigitLen into: (self pointerToFirstDigitOfLargeInt: sum). over > 0 ifTrue: ["sum := sum growby: 1." self remapOop: sum in: [newSum := self createLargeIntegerNeg: neg byteLength: longDigitLen * 4 + 1]. + newSum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. self cDigitCopyFrom: (self pointerToFirstDigitOfLargeInt: sum) to: (self pointerToFirstDigitOfLargeInt: newSum) len: longDigitLen. sum := newSum. "C index!!" self cDigitOf: (self pointerToFirstDigitOfLargeInt: sum) at: longDigitLen put: over] ifFalse: [sum := neg ifTrue: [self normalizeNegative: sum] ifFalse: [self normalizePositive: sum]]. ^ sum! Item was changed: ----- Method: LargeIntegersPlugin>>digitBitLogic:with:opIndex: (in category 'oop functions') ----- digitBitLogic: firstInteger with: secondInteger opIndex: opIx "Bit logic here is only implemented for positive integers or Zero; if rec or arg is negative, it fails." | firstLarge secondLarge firstLen secondLen shortLen shortLarge longLen longLarge result | (interpreterProxy isIntegerObject: firstInteger) ifTrue: + [(interpreterProxy integerValueOf: firstInteger) < 0 ifTrue: + [^ interpreterProxy primitiveFail]. - [(interpreterProxy integerValueOf: firstInteger) - < 0 ifTrue: [^ interpreterProxy primitiveFail]. "convert it to a not normalized LargeInteger" self remapOop: secondInteger in: [firstLarge := self createLargeFromSmallInteger: firstInteger]] ifFalse: [(interpreterProxy isLargePositiveIntegerObject: firstInteger) ifFalse: [^ interpreterProxy primitiveFail]. firstLarge := firstInteger]. (interpreterProxy isIntegerObject: secondInteger) ifTrue: + [(interpreterProxy integerValueOf: secondInteger) < 0 ifTrue: + [^ interpreterProxy primitiveFail]. - [(interpreterProxy integerValueOf: secondInteger) - < 0 ifTrue: [^ interpreterProxy primitiveFail]. "convert it to a not normalized LargeInteger" self remapOop: firstLarge in: [secondLarge := self createLargeFromSmallInteger: secondInteger]] ifFalse: [(interpreterProxy isLargePositiveIntegerObject: secondInteger) ifFalse: [^ interpreterProxy primitiveFail]. secondLarge := secondInteger]. firstLen := self byteSizeOfLargeInt: firstLarge. secondLen := self byteSizeOfLargeInt: secondLarge. firstLen < secondLen ifTrue: [shortLen := firstLen. shortLarge := firstLarge. longLen := secondLen. longLarge := secondLarge] ifFalse: [shortLen := secondLen. shortLarge := secondLarge. longLen := firstLen. longLarge := firstLarge]. + self remapOop: #(shortLarge longLarge) in: + [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. + result ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. - self remapOop: #(shortLarge longLarge ) in: [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. self cDigitOp: opIx short: (self pointerToFirstDigitOfLargeInt: shortLarge) len: shortLen + 3 // 4 long: (self pointerToFirstDigitOfLargeInt: longLarge) len: longLen + 3 // 4 into: (self pointerToFirstDigitOfLargeInt: result). interpreterProxy failed ifTrue: [^ 0]. + ^self normalizePositive: result! - ^ self normalizePositive: result! Item was changed: ----- Method: LargeIntegersPlugin>>digitMontgomery:times:modulo:mInvModB: (in category 'oop functions') ----- digitMontgomery: firstLarge times: secondLarge modulo: thirdLarge mInvModB: mInv | firstLen secondLen thirdLen prod | firstLen := self digitSizeOfLargeInt: firstLarge. secondLen := self digitSizeOfLargeInt: secondLarge. thirdLen := self digitSizeOfLargeInt: thirdLarge. (firstLen <= thirdLen and: [secondLen <= thirdLen]) ifFalse: [^interpreterProxy primitiveFail]. self remapOop: #(firstLarge secondLarge thirdLarge) in: [prod := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: thirdLen * 4]. + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. self cDigitMontgomery: (self pointerToFirstDigitOfLargeInt: firstLarge) len: firstLen times: (self pointerToFirstDigitOfLargeInt: secondLarge) len: secondLen modulo: (self pointerToFirstDigitOfLargeInt: thirdLarge) len: thirdLen mInvModB: mInv into: (self pointerToFirstDigitOfLargeInt: prod). ^self normalizePositive: prod! Item was changed: ----- Method: LargeIntegersPlugin>>digitMultiplyLarge:with:negative: (in category 'oop functions') ----- digitMultiplyLarge: firstInteger with: secondInteger negative: neg "Normalizes." | firstLen secondLen shortInt shortLen longInt longLen prod | firstLen := self byteSizeOfLargeInt: firstInteger. secondLen := self byteSizeOfLargeInt: secondInteger. firstLen <= secondLen ifTrue: [shortInt := firstInteger. shortLen := firstLen. longInt := secondInteger. longLen := secondLen] ifFalse: [shortInt := secondInteger. shortLen := secondLen. longInt := firstInteger. longLen := firstLen]. self remapOop: #(shortInt longInt) in: [prod := self createLargeIntegerNeg: neg byteLength: longLen + shortLen]. + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. self cDigitMultiply: (self pointerToFirstDigitOfLargeInt: shortInt) len: shortLen + 3 // 4 with: (self pointerToFirstDigitOfLargeInt: longInt) len: longLen + 3 // 4 into: (self pointerToFirstDigitOfLargeInt: prod) len: longLen + shortLen + 3 // 4. ^neg ifTrue: [self normalizeNegative: prod] ifFalse: [self normalizePositive: prod]! Item was changed: ----- Method: LargeIntegersPlugin>>digitSubLarge:with: (in category 'oop functions') ----- digitSubLarge: firstInteger with: secondInteger "Normalizes." | firstDigitLen secondDigitLen larger largeDigitLen smaller smallerDigitLen neg resDigitLen res firstNeg | firstNeg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. firstDigitLen := self digitSizeOfLargeInt: firstInteger. secondDigitLen := self digitSizeOfLargeInt: secondInteger. firstDigitLen = secondDigitLen ifTrue: [[firstDigitLen > 1 and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) = (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]] whileTrue: [firstDigitLen := firstDigitLen - 1]. secondDigitLen := firstDigitLen]. (firstDigitLen < secondDigitLen or: [firstDigitLen = secondDigitLen and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) < (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]]) ifTrue: [larger := secondInteger. largeDigitLen := secondDigitLen. smaller := firstInteger. smallerDigitLen := firstDigitLen. neg := firstNeg == false] ifFalse: [larger := firstInteger. largeDigitLen := firstDigitLen. smaller := secondInteger. smallerDigitLen := secondDigitLen. neg := firstNeg]. resDigitLen := largeDigitLen. self remapOop: #(smaller larger) in: [res := self createLargeIntegerNeg: neg digitLength: resDigitLen]. + res ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. self cDigitSub: (self pointerToFirstDigitOfLargeInt: smaller) len: smallerDigitLen with: (self pointerToFirstDigitOfLargeInt: larger) len: largeDigitLen into: (self pointerToFirstDigitOfLargeInt: res). ^neg ifTrue: [self normalizeNegative: res] ifFalse: [self normalizePositive: res]! From commits at squeakvm.org Thu Jun 2 01:01:02 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Thu Jun 2 01:00:50 2016 Subject: [Vm-dev] [commit][3735] CogVm source as per VMMaker.oscog-eem.1878 Message-ID: Revision: 3735 Author: eliot Date: 2016-06-01 18:00:59 -0700 (Wed, 01 Jun 2016) Log Message: ----------- CogVm source as per VMMaker.oscog-eem.1878 Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. Stops (2 raisedTo: 100000000) basicSize crashing system. This fix is clearly unsatisfactory;. the ciode fails to slow Smalltalk code. We'd like to run the GC but Spur's style is not to GC in primitives. If we change the plugin to do GC in primtiives we lose the speed advantage of the no-GC style of code. One approach might be to estimate the memory needed as early as possible, and run a GC if not enough memory is available for the result, recomputing base pointers if GC is run. This would avoid the awful remapOop:in: style whioch is pessimistic; it puts things in a stack and takes them back out whether a GC is needed or not. We should use an optimistic algorithm; especially for something as performance sensitive as large integer arithmetic. Modified Paths: -------------- branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Property changes on: branches/Cog/platforms/Cross/vm/sqSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Wed Jun 1 16:52:50 PDT 2016 + Wed Jun 1 17:58:41 PDT 2016 Modified: branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c =================================================================== --- branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c 2016-06-01 23:55:01 UTC (rev 3734) +++ branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c 2016-06-02 01:00:59 UTC (rev 3735) @@ -1,9 +1,9 @@ /* Automatically generated by - SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.1878 uuid: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 from - LargeIntegersPlugin VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + LargeIntegersPlugin VMMaker.oscog-eem.1878 uuid: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 */ -static char __buildInfo[] = "LargeIntegersPlugin VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; +static char __buildInfo[] = "LargeIntegersPlugin VMMaker.oscog-eem.1878 uuid: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 " __DATE__ ; @@ -32,6 +32,10 @@ #include "sqMemoryAccess.h" +/*** Constants ***/ +#define PrimErrNoMemory 9 + + /*** Function Prototypes ***/ static sqInt anyBitOfLargeIntfromto(sqInt anOop, sqInt start, sqInt stopArg); static sqInt byteSizeOfCSI(sqInt csi); @@ -145,6 +149,7 @@ static sqInt (*popRemappableOop)(void); static usqInt (*positive32BitValueOf)(sqInt oop); static sqInt (*primitiveFail)(void); +static sqInt (*primitiveFailFor)(sqInt reasonCode); static sqInt (*pushRemappableOop)(sqInt oop); static sqInt (*slotSizeOf)(sqInt oop); static sqInt (*stObjectatput)(sqInt array, sqInt index, sqInt value); @@ -172,6 +177,7 @@ extern sqInt popRemappableOop(void); extern usqInt positive32BitValueOf(sqInt oop); extern sqInt primitiveFail(void); +extern sqInt primitiveFailFor(sqInt reasonCode); extern sqInt pushRemappableOop(sqInt oop); extern sqInt slotSizeOf(sqInt oop); extern sqInt stObjectatput(sqInt array, sqInt index, sqInt value); @@ -184,9 +190,9 @@ struct VirtualMachine* interpreterProxy; static const char *moduleName = #ifdef SQUEAK_BUILTIN_PLUGIN - "LargeIntegers v2.0 VMMaker.oscog-eem.1876 (i)" + "LargeIntegers v2.0 VMMaker.oscog-eem.1878 (i)" #else - "LargeIntegers v2.0 VMMaker.oscog-eem.1876 (e)" + "LargeIntegers v2.0 VMMaker.oscog-eem.1878 (e)" #endif ; static const int orOpIndex = 1; @@ -556,7 +562,7 @@ sqInt i; sqInt i1; sqInt limit; - sqInt rshift; + int rshift; digitShift = shiftCount / 32; bitShift = shiftCount % 32; @@ -795,7 +801,7 @@ sqInt digitShift; sqInt i; sqInt j; - sqInt leftShift; + int leftShift; sqInt limit; sqInt start; @@ -988,9 +994,9 @@ digitSize = (byteSize + 3) / 4; for (ix = 1; ix <= digitSize; ix += 1) { /* begin cDigitOf:at:put: */ - aValue = ((unsigned int) (((usqInt) ((val < 0 - ? 0 - val - : val))) >> ((ix - 1) * 32))); + aValue = ((usqInt) ((val < 0 + ? 0 - val + : val))) >> ((ix - 1) * 32); pDigit[ix - 1] = (SQ_SWAP_4_BYTES_IF_BIGENDIAN(aValue)); } return res; @@ -1072,6 +1078,9 @@ shortInt = popRemappableOop() #endif /* SPURVM */ ; + if (!(sum)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitAdd:len:with:len:into: */ pWordShort = ((unsigned int *) (((unsigned int *) (firstIndexableField(shortInt))))); pWordLong = ((unsigned int *) (((unsigned int *) (firstIndexableField(longInt))))); @@ -1103,6 +1112,9 @@ sum = popRemappableOop() #endif /* SPURVM */ ; + if (!(newSum)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitCopyFrom:to:len: */ pFrom = ((unsigned int *) (((unsigned int *) (firstIndexableField(sum))))); pTo = ((unsigned int *) (((unsigned int *) (firstIndexableField(newSum))))); @@ -1215,6 +1227,9 @@ shortLarge = popRemappableOop() #endif /* SPURVM */ ; + if (!(result)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitOp:short:len:long:len:into: */ pWordShort = ((unsigned int *) (((unsigned int *) (firstIndexableField(shortLarge))))); pWordLong = ((unsigned int *) (((unsigned int *) (firstIndexableField(longLarge))))); @@ -1293,7 +1308,7 @@ unsigned long long a; unsigned long long b; int cond; - sqInt d; + int d; unsigned int dh; sqInt div; sqInt divLen; @@ -1564,6 +1579,9 @@ firstLarge = popRemappableOop() #endif /* SPURVM */ ; + if (!(prod)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitMontgomery:len:times:len:modulo:len:mInvModB:into: */ pFirst = ((unsigned int *) (((unsigned int *) (firstIndexableField(firstLarge))))); pSecond = ((unsigned int *) (((unsigned int *) (firstIndexableField(secondLarge))))); @@ -1683,6 +1701,9 @@ shortInt = popRemappableOop() #endif /* SPURVM */ ; + if (!(prod)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitMultiply:len:with:len:into:len: */ pWordShort = ((unsigned int *) (((unsigned int *) (firstIndexableField(shortInt))))); pWordLong = ((unsigned int *) (((unsigned int *) (firstIndexableField(longInt))))); @@ -1793,7 +1814,7 @@ sqInt i; sqInt largeDigitLen; sqInt larger; - sqInt neg; + int neg; unsigned int *pWordLarge; unsigned int *pWordRes; unsigned int *pWordSmall; @@ -1847,6 +1868,9 @@ smaller = popRemappableOop() #endif /* SPURVM */ ; + if (!(res)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitSub:len:with:len:into: */ pWordSmall = ((unsigned int *) (((unsigned int *) (firstIndexableField(smaller))))); pWordLarge = ((unsigned int *) (((unsigned int *) (firstIndexableField(larger))))); @@ -1891,7 +1915,7 @@ sqInt oldDigitLen; unsigned int *pFrom; unsigned int *pTo; - sqInt rshift; + int rshift; oldDigitLen = ((slotSizeOf(anOop)) + 3) / 4; if (((highBit = cDigitHighBitlen(((unsigned int *) (firstIndexableField(anOop))), oldDigitLen))) == 0) { @@ -1908,6 +1932,9 @@ anOop = popRemappableOop() #endif /* SPURVM */ ; + if (!(newOop)) { + return primitiveFailFor(PrimErrNoMemory); + } newDigitLen = (newByteLen + 3) / 4; /* begin cDigitLshift:from:len:to:len: */ pFrom = ((unsigned int *) (((unsigned int *) (firstIndexableField(anOop))))); @@ -1964,7 +1991,7 @@ sqInt i; sqInt j; unsigned int lastDigit; - sqInt leftShift; + int leftShift; sqInt limit; sqInt newBitLen; sqInt newByteLen; @@ -2008,6 +2035,9 @@ anOop = popRemappableOop() #endif /* SPURVM */ ; + if (!(newOop)) { + return primitiveFailFor(PrimErrNoMemory); + } /* begin cDigitRshift:from:len:to:len: */ pFrom = ((unsigned int *) (((unsigned int *) (firstIndexableField(anOop))))); pTo = ((unsigned int *) (((unsigned int *) (firstIndexableField(newOop))))); @@ -2432,6 +2462,10 @@ shortInt = popRemappableOop() #endif /* SPURVM */ ; + if (!(sum)) { + _return_value = primitiveFailFor(PrimErrNoMemory); + goto l4; + } /* begin cDigitAdd:len:with:len:into: */ pWordShort = ((unsigned int *) (((unsigned int *) (firstIndexableField(shortInt))))); pWordLong = ((unsigned int *) (((unsigned int *) (firstIndexableField(longInt))))); @@ -2463,6 +2497,10 @@ sum = popRemappableOop() #endif /* SPURVM */ ; + if (!(newSum)) { + _return_value = primitiveFailFor(PrimErrNoMemory); + goto l4; + } /* begin cDigitCopyFrom:to:len: */ pFrom = ((unsigned int *) (((unsigned int *) (firstIndexableField(sum))))); pTo = ((unsigned int *) (((unsigned int *) (firstIndexableField(newSum))))); @@ -2482,6 +2520,7 @@ : normalizePositive(sum)); } _return_value = sum; +l4: /* end digitAddLarge:with: */; if (failed()) { return null; } @@ -2558,7 +2597,7 @@ sqInt aLarge; sqInt aLargeInteger; sqInt anInteger; - sqInt rShift; + int rShift; sqInt shiftCount; sqInt _return_value; @@ -2778,7 +2817,7 @@ unsigned long long a; unsigned long long b; int cond; - sqInt d; + int d; unsigned int dh; sqInt div; sqInt divLen; @@ -3189,6 +3228,10 @@ shortInt = popRemappableOop() #endif /* SPURVM */ ; + if (!(prod)) { + _return_value = primitiveFailFor(PrimErrNoMemory); + goto l2; + } /* begin cDigitMultiply:len:with:len:into:len: */ pWordShort = ((unsigned int *) (((unsigned int *) (firstIndexableField(shortInt))))); pWordLong = ((unsigned int *) (((unsigned int *) (firstIndexableField(longInt))))); @@ -3226,6 +3269,7 @@ _return_value = (neg ? normalizeNegative(prod) : normalizePositive(prod)); +l2: /* end digitMultiplyLarge:with:negative: */; if (failed()) { return null; } @@ -3244,7 +3288,7 @@ sqInt i; sqInt largeDigitLen; sqInt larger; - sqInt neg; + int neg; unsigned int *pWordLarge; unsigned int *pWordRes; unsigned int *pWordSmall; @@ -3347,6 +3391,10 @@ smaller = popRemappableOop() #endif /* SPURVM */ ; + if (!(res)) { + _return_value = primitiveFailFor(PrimErrNoMemory); + goto l2; + } /* begin cDigitSub:len:with:len:into: */ pWordSmall = ((unsigned int *) (((unsigned int *) (firstIndexableField(smaller))))); pWordLarge = ((unsigned int *) (((unsigned int *) (firstIndexableField(larger))))); @@ -3365,6 +3413,7 @@ _return_value = (neg ? normalizeNegative(res) : normalizePositive(res)); +l2: /* end digitSubLarge:with: */; if (failed()) { return null; } @@ -3539,6 +3588,10 @@ firstLarge = popRemappableOop() #endif /* SPURVM */ ; + if (!(prod)) { + _return_value = primitiveFailFor(PrimErrNoMemory); + goto l2; + } /* begin cDigitMontgomery:len:times:len:modulo:len:mInvModB:into: */ pFirst = ((unsigned int *) (((unsigned int *) (firstIndexableField(firstLarge))))); pSecond = ((unsigned int *) (((unsigned int *) (firstIndexableField(secondLarge))))); @@ -3688,6 +3741,7 @@ popRemappableOop = interpreterProxy->popRemappableOop; positive32BitValueOf = interpreterProxy->positive32BitValueOf; primitiveFail = interpreterProxy->primitiveFail; + primitiveFailFor = interpreterProxy->primitiveFailFor; pushRemappableOop = interpreterProxy->pushRemappableOop; slotSizeOf = interpreterProxy->slotSizeOf; stObjectatput = interpreterProxy->stObjectatput; From commits at source.squeak.org Thu Jun 2 01:07:00 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Jun 2 01:07:00 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1879.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1879.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1879 Author: eem Time: 1 June 2016, 6:05:04.876264 pm UUID: 46459a03-d9ee-4422-9c65-f863b50b7992 Ancestors: VMMaker.oscog-eem.1878 Follow-up to VMMaker.oscog-eem.1878: Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. =============== Diff against VMMaker.oscog-eem.1878 =============== Item was changed: ----- Method: LargeIntegersPlugin>>largeInt:growTo: (in category 'oop util') ----- largeInt: aBytesObject growTo: newByteLen "Attention: this method invalidates all oop's!! Only newBytes is valid at return." "Does not normalize." | newBytes oldDigitLen newDigitLen copyLen | + self remapOop: aBytesObject in: + [newBytes := interpreterProxy + instantiateClass: (interpreterProxy fetchClassOf: aBytesObject) + indexableSize: newByteLen]. + newBytes ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. - self remapOop: aBytesObject in: [newBytes := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: aBytesObject) - indexableSize: newByteLen]. newDigitLen := newByteLen + 3 // 4. oldDigitLen := self digitSizeOfLargeInt: aBytesObject. copyLen := oldDigitLen < newDigitLen ifTrue: [oldDigitLen] ifFalse: [newDigitLen]. self cDigitCopyFrom: (self pointerToFirstDigitOfLargeInt: aBytesObject) to: (self pointerToFirstDigitOfLargeInt: newBytes) len: copyLen. ^newBytes! From commits at squeakvm.org Thu Jun 2 01:08:20 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Thu Jun 2 01:08:08 2016 Subject: [Vm-dev] [commit][3736] CogVM source as per VMMaker.oscog-eem.1879 Message-ID: Revision: 3736 Author: eliot Date: 2016-06-01 18:08:20 -0700 (Wed, 01 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1879 Follow-up to VMMaker.oscog-eem.1878: Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. Modified Paths: -------------- branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Property changes on: branches/Cog/platforms/Cross/vm/sqSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Wed Jun 1 17:58:41 PDT 2016 + Wed Jun 1 18:07:02 PDT 2016 Modified: branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c =================================================================== --- branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c 2016-06-02 01:00:59 UTC (rev 3735) +++ branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c 2016-06-02 01:08:20 UTC (rev 3736) @@ -1,9 +1,9 @@ /* Automatically generated by - SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.1878 uuid: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 + SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.1879 uuid: 46459a03-d9ee-4422-9c65-f863b50b7992 from - LargeIntegersPlugin VMMaker.oscog-eem.1878 uuid: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 + LargeIntegersPlugin VMMaker.oscog-eem.1879 uuid: 46459a03-d9ee-4422-9c65-f863b50b7992 */ -static char __buildInfo[] = "LargeIntegersPlugin VMMaker.oscog-eem.1878 uuid: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 " __DATE__ ; +static char __buildInfo[] = "LargeIntegersPlugin VMMaker.oscog-eem.1879 uuid: 46459a03-d9ee-4422-9c65-f863b50b7992 " __DATE__ ; @@ -190,9 +190,9 @@ struct VirtualMachine* interpreterProxy; static const char *moduleName = #ifdef SQUEAK_BUILTIN_PLUGIN - "LargeIntegers v2.0 VMMaker.oscog-eem.1878 (i)" + "LargeIntegers v2.0 VMMaker.oscog-eem.1879 (i)" #else - "LargeIntegers v2.0 VMMaker.oscog-eem.1878 (e)" + "LargeIntegers v2.0 VMMaker.oscog-eem.1879 (e)" #endif ; static const int orOpIndex = 1; @@ -2150,6 +2150,9 @@ aBytesObject = popRemappableOop() #endif /* SPURVM */ ; + if (!(newBytes)) { + return primitiveFailFor(PrimErrNoMemory); + } newDigitLen = (newByteLen + 3) / 4; oldDigitLen = ((slotSizeOf(aBytesObject)) + 3) / 4; copyLen = (oldDigitLen < newDigitLen From eliot.miranda at gmail.com Thu Jun 2 01:19:12 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 2 01:19:17 2016 Subject: [Vm-dev] Re: [squeak-dev] 2 raisedTo: 100000000` crashes VM In-Reply-To: References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> Message-ID: Thanks all, On Wed, Jun 1, 2016 at 1:48 PM, Bert Freudenberg wrote: > On 01.06.2016, at 19:45, Eliot Miranda wrote: > > (2 raisedTo: 100000000) basicSize > > So which VM does it fail on? > > Mac Spur 5.0.3692 > > - Bert - OK, tis fixed in VMMaker.oscog-eem.1879. Reporting - 774 tallies, 6,836 msec. **Tree** ... [100 (6,836) [] SmalltalkEditor(TextEditor) evaluateSelectionAndDo: [ 100 (6,836) Compiler evaluate:in:to:notifying:ifFail:logged: [ 100 (6,836) Compiler evaluateCue:ifFail:logged: [ 100 (6,836) Compiler evaluateCue:ifFail: [ 100 (6,836) UndefinedObject DoIt [ 100 (6,836) AndreasSystemProfiler class spyOn: [ 100 (6,836) BlockClosure ensure: [ 100 (6,836) [] AndreasSystemProfiler class spyOn: [ 100 (6,836) AndreasSystemProfiler spyOn: [ 100 (6,836) BlockClosure ensure: [ 100 (6,836) [] UndefinedObject DoIt [ 100 (6,836) SmallInteger(Integer) timesRepeat: [ 100 (6,836) [[]] UndefinedObject DoIt [ 100 (6,836) SmallInteger(Number) raisedTo: [ 100 (6,836) SmallInteger(Number) raisedToInteger: [ 98.45 (6,730) LargePositiveInteger * [ 98.44 (6,730) LargePositiveInteger(Integer) * [ 98.44 (6,730) LargePositiveInteger(Integer) digitMultiply:neg: [ 50.36 (3,442) SmalltalkImage primitiveGarbageCollect [ 28.3 (1,935) LargePositiveInteger normalize [ 28.3 (1,935) LargePositiveInteger(Integer) growto: [ 28.26 (1,932) LargePositiveInteger(Integer) copyto: [ 28.26 (1,932) SmalltalkImage primitiveGarbageCollect **Leaves** 78.61 (5,374) SmalltalkImage primitiveGarbageCollect **Memory** old -16,777,216 bytes young +15,421,544 bytes used -1,355,672 bytes free -15,421,544 bytes **GCs** full 14 totalling 5,279ms (77.0% uptime), avg 377.0ms incr 1 totalling 0ms (0.0% uptime), avg 0.0ms tenures 0 root table 0 overflows **Processes** Total process switches: 1596 Without Profiler: 48 Stack page overflows: 4567 Stack page divorces: 15 -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/e62ae0c8/attachment.htm From eliot.miranda at gmail.com Thu Jun 2 01:21:05 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 2 01:21:07 2016 Subject: [Vm-dev] Amazing ARM simulator experience In-Reply-To: References: Message-ID: Hi Dimitris, On Wed, Jun 1, 2016 at 3:07 PM, Dimitris Chloupis wrote: > > My first computer that my father bought me in 1988 was an Amstrad CPC 6128 > , with a 4 Mhz CPU and 128kb Ram > > My latest computer is a late 2013 quad core 3 Ghz iMac with 8 gb memory. > Which makes it at least 3000 times faster than my Amstrad , technology has > come a long way the past 30 years. I could not imagine this future even in > my wildest dreams. > > By Gdb you mean the GNU debugger ? > Yes. Gdb comes with a lot of different simulators. So far for executing machine code in Cog we've used Bochs for x86 and x86_64, Gdb for ARM v6 and hand-written Smalltalk for MIPSEL. > > On Wed, Jun 1, 2016 at 8:43 PM Eliot Miranda > wrote: > >> >> Hi All, >> >> just had to tell people about this morning's experience using the ARM >> simulator. I've been building Smalltalk VMs since 1983, so 33 years. My >> first on the Three Rivers PERQ was dog slow. My undergraduate project was >> done the the National Semiconductor 32016 based Whitechapel Computer Works >> workstation and its and 32032-based successor. >> >> This morning I was revamping register management in Cog's ARMv5/v6 back >> end, making more registers available by using two of the C argument >> registers for two of registers the Cogit assigns to various fixed tasks, >> and using store and load multiple instructions to save and restore >> concisely the registers around calls into the runtime. >> >> Remember the architecture here. The simulator generates ARM machine code >> into the ByteArray that re[resents the address space, holding all of >> generated machine code, a small C stack, and the Smalltalk heap. A plugin, >> derived from Gdb's ARM simulator written in C, interprets that machine >> code, running for a couple of milliseconds at a time in a loop, applying >> breakpoint calculations, and asserts on every call into the run-time, and >> that calls into the run-time and accesses of variables in the simulator is >> done by using illegal addresses in the generated machine code. Each >> illegal access causes the Gdb-derived machine code interpreter to return >> with an error, this error is turned into an exception, the handler for >> which maps the specific illegal address into a variable or message >> selector, accesses the variable or activates the message selector, >> providing the result, and allowing the execution to continue. >> >> In changing the register management I had a test case that worked, an >> image that prompted for an expression ands evaluated it, which worked both >> in the simulator and with the generated VM. But the real VM, crashed when >> used on a proper image. So to debug I started launching the real >> interactive image in the simulator. >> >> Well, the amazing experience is that that image, whose machine code is >> being _interpreted by a C program_ feels /faster/ than my 32016 based >> implementation back in 1984-ish. Quite amazing. I can open windows, type >> text, access source code (was playing with Message Names) etc. It's >> sluggish, but usable. Amazing how fast modern machines are. All on my >> 2012 vintage 2.2 Ghz Core i7 MacBook Pro. I'm blown away :-) >> >> _,,,^..^,,,_ >> best, Eliot >> > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/7dba5362/attachment.htm From rmacnak at gmail.com Thu Jun 2 02:19:52 2016 From: rmacnak at gmail.com (Ryan Macnak) Date: Thu Jun 2 02:19:54 2016 Subject: [Vm-dev] Amazing ARM simulator experience In-Reply-To: References: Message-ID: I'll second that simulators are an essential tool for building a JIT. In the Dart VM, we have our own simulators for ARM, ARM64 and MIPS that allow us to test changes against all the architectures we support, locally on our x64 workstations. When we first got the VM running on iOS, we were even running the ARM simulator on the iPhone to work around the no-JITing-unless-you're-Apple policy (we have since completed an AOT mode). Although it was sluggish compared to its JIT counterpart running on Android, it was certainly usable. And given our loading code is also implemented in Dart, having simulators allows us to cross-compile AOT code for Android and iOS from x64 desktops. On Wed, Jun 1, 2016 at 6:21 PM, Eliot Miranda wrote: > > Hi Dimitris, > > On Wed, Jun 1, 2016 at 3:07 PM, Dimitris Chloupis > wrote: > >> >> My first computer that my father bought me in 1988 was an Amstrad CPC >> 6128 , with a 4 Mhz CPU and 128kb Ram >> >> My latest computer is a late 2013 quad core 3 Ghz iMac with 8 gb memory. >> Which makes it at least 3000 times faster than my Amstrad , technology has >> come a long way the past 30 years. I could not imagine this future even in >> my wildest dreams. >> >> By Gdb you mean the GNU debugger ? >> > > Yes. Gdb comes with a lot of different simulators. So far for executing > machine code in Cog we've used Bochs for x86 and x86_64, Gdb for ARM v6 and > hand-written Smalltalk for MIPSEL. > > >> >> On Wed, Jun 1, 2016 at 8:43 PM Eliot Miranda >> wrote: >> >>> >>> Hi All, >>> >>> just had to tell people about this morning's experience using the >>> ARM simulator. I've been building Smalltalk VMs since 1983, so 33 years. >>> My first on the Three Rivers PERQ was dog slow. My undergraduate project >>> was done the the National Semiconductor 32016 based Whitechapel Computer >>> Works workstation and its and 32032-based successor. >>> >>> This morning I was revamping register management in Cog's ARMv5/v6 back >>> end, making more registers available by using two of the C argument >>> registers for two of registers the Cogit assigns to various fixed tasks, >>> and using store and load multiple instructions to save and restore >>> concisely the registers around calls into the runtime. >>> >>> Remember the architecture here. The simulator generates ARM machine >>> code into the ByteArray that re[resents the address space, holding all of >>> generated machine code, a small C stack, and the Smalltalk heap. A plugin, >>> derived from Gdb's ARM simulator written in C, interprets that machine >>> code, running for a couple of milliseconds at a time in a loop, applying >>> breakpoint calculations, and asserts on every call into the run-time, and >>> that calls into the run-time and accesses of variables in the simulator is >>> done by using illegal addresses in the generated machine code. Each >>> illegal access causes the Gdb-derived machine code interpreter to return >>> with an error, this error is turned into an exception, the handler for >>> which maps the specific illegal address into a variable or message >>> selector, accesses the variable or activates the message selector, >>> providing the result, and allowing the execution to continue. >>> >>> In changing the register management I had a test case that worked, an >>> image that prompted for an expression ands evaluated it, which worked both >>> in the simulator and with the generated VM. But the real VM, crashed when >>> used on a proper image. So to debug I started launching the real >>> interactive image in the simulator. >>> >>> Well, the amazing experience is that that image, whose machine code is >>> being _interpreted by a C program_ feels /faster/ than my 32016 based >>> implementation back in 1984-ish. Quite amazing. I can open windows, type >>> text, access source code (was playing with Message Names) etc. It's >>> sluggish, but usable. Amazing how fast modern machines are. All on my >>> 2012 vintage 2.2 Ghz Core i7 MacBook Pro. I'm blown away :-) >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160601/d0eb5ac0/attachment-0001.htm From lewis at mail.msen.com Thu Jun 2 04:12:49 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Thu Jun 2 04:12:51 2016 Subject: [Vm-dev] Need a good comment for SystemTracerSpur (was: Tracing a Spur Image from Smalltalk) In-Reply-To: <1456502344939-4881224.post@n4.nabble.com> References: <1456502344939-4881224.post@n4.nabble.com> Message-ID: <20160602041249.GA80138@shell.msen.com> Hi Tim, The latest version of your system tracer for Spur (on squeaksource) is in SystemTracing-tfel.41. The SystemTracerSpur class would benefit from a class comment to explain with it can (and cannot) do. Would you mind adding a comment to clarify? My understanding is that SystemTracerSpur traces a 32-bit V3 image to 32-bit Spur, although it is not clear if the traced image can then be run under a Spur VM (I suspect not, but I am not sure). We also have 64-bit Spur images available, and these will require tracing support either with SystemTracer, or using the VMMaker tracing that Eliot has already provided. So I think that this might get confusing soon, and a class comment will help to explain it. Thanks! Dave On Fri, Feb 26, 2016 at 07:59:04AM -0800, timfelgentreff wrote: > > I've updated the SystemTracer package to trace a Spur-format image. > > This works as far as I can tell, producing a header that looks just like the > header produced by the VM and the objects written also look good. I can also > open the image in RSqueak, but not on Spur. It crashes immediately and > produces a Smalltalk backtrace that looks like it never manages to return > from the image-saving method (but the names in the Stack-trace all look ok, > leading me to believe that enough objects got written ok to figure out > classes, method names, find the right Process to run and so forth). > > Curiously, the old SystemTracer2 class that writes Cog-format images also > produces images that cannot be opened by Cog VMs, only Interpreter VMs. So I > assume there are other assumptions that maybe the JIT makes when starting > up. > > So my question is, what assumptions could there be, and where could I start > looking. > > Cheers, > Tim > > (If you're wondering why I'm using the Smalltalk-level tracing at all - in > our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code fast > enough that we no longer have to rely on C code from plugins or optional > primitives, we're trying to see how far we can push this, and e.g. write the > image from within itself, too.) > > > > -- > View this message in context: http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224.html > Sent from the Squeak VM mailing list archive at Nabble.com. From btc at openinworld.com Thu Jun 2 05:35:15 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 2 05:35:39 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1878.mcz In-Reply-To: <574f84ce.01e5420a.38242.08e4SMTPIN_ADDED_MISSING@mx.google.com> References: <574f84ce.01e5420a.38242.08e4SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Jun 2, 2016 at 8:57 AM, wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1878.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.1878 > Author: eem > Time: 1 June 2016, 5:56:53.625028 pm > UUID: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 > Ancestors: VMMaker.oscog-eem.1877 > > Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. > > This is clearly unsatisfactory;. the ciode fails to slow Smalltalk code. We'd like to run the GC but Spur's style is not to GC in primitives. Hi Eliot, Does "not to GC *in* primitives" mean from the Image's or VM's perspective? Naively I wonder if your approach to primitives failing due to forwarders would apply here. If the primitive runs out of space, set a flag before failing, and at the same point you test and resolve forwarders, then retry the primitive, you could check for this flag, run a GC (outside of the primitive from the VM's perspective?), then retry the primitive ?? cheers -ben > If we change the plugin to do GC in primitives we lose the speed advantage of the no-GC style of code. One approach might be to estimate the memory needed as early as possible, and run a GC if not enough memory is available for the result, recomputing base pointers if GC is run. This would avoid the awful remapOop:in: style whioch is pessimistic; it puts things in a stack and takes them back out whether a GC is needed or not. We shoudl use an optimistic algorithm; especially for something as performance sensitive as large integer arithmetic. > > =============== Diff against VMMaker.oscog-eem.1877 =============== > > Item was changed: > ----- Method: LargeIntegersPlugin>>digit:Lshift: (in category 'oop functions') ----- > digit: anOop Lshift: shiftCount > "Attention: this method invalidates all oop's!! Only newOop is valid at return." > "Does not normalize." > | newOop highBit newDigitLen newByteLen oldDigitLen | > oldDigitLen := self digitSizeOfLargeInt: anOop. > (highBit := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) > len: oldDigitLen) = 0 ifTrue: [^ interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) indexableSize: 1]. > newByteLen := highBit + shiftCount + 7 // 8. > + self remapOop: anOop in: > + [newOop := interpreterProxy > + instantiateClass: (interpreterProxy fetchClassOf: anOop) > + indexableSize: newByteLen]. > + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) > - indexableSize: newByteLen]. > newDigitLen := newByteLen + 3 // 4. > self > cDigitLshift: shiftCount > from: (self pointerToFirstDigitOfLargeInt: anOop) > len: oldDigitLen > to: (self pointerToFirstDigitOfLargeInt: newOop) > len: newDigitLen. > ^ newOop! > > Item was changed: > ----- Method: LargeIntegersPlugin>>digit:Rshift:lookfirst: (in category 'oop functions') ----- > digit: anOop Rshift: shiftCount lookfirst: a > "Attention: this method invalidates all oop's!! Only newBytes is valid at return." > "Shift right 32*digitShift+bitShift bits, 0<=bitShift<32. > Discard all digits beyond a, and all zeroes at or below a." > "Does not normalize." > | newByteLen newOop oldBitLen newBitLen oldDigitLen newDigitLen | > oldBitLen := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) len: a. > oldDigitLen := oldBitLen + 31 // 32. > newBitLen := oldBitLen - shiftCount. > newBitLen <= 0 ifTrue: ["All bits lost" > ^ interpreterProxy > instantiateClass: (interpreterProxy fetchClassOf: anOop) > indexableSize: 0]. > newByteLen := newBitLen + 7 // 8. > newDigitLen := newByteLen + 3 // 4. > + self remapOop: anOop in: > + [newOop := interpreterProxy > + instantiateClass: (interpreterProxy fetchClassOf: anOop) > + indexableSize: newByteLen]. > + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) > - indexableSize: newByteLen]. > self > cDigitRshift: shiftCount > from: (self pointerToFirstDigitOfLargeInt: anOop) > len: oldDigitLen > to: (self pointerToFirstDigitOfLargeInt: newOop) > len: newDigitLen. > ^ newOop! > > Item was changed: > ----- Method: LargeIntegersPlugin>>digitAddLarge:with: (in category 'oop functions') ----- > digitAddLarge: firstInteger with: secondInteger > "Does not need to normalize!!" > | over firstDigitLen secondDigitLen shortInt shortDigitLen longInt longDigitLen sum newSum neg | > > firstDigitLen := self digitSizeOfLargeInt: firstInteger. > secondDigitLen := self digitSizeOfLargeInt: secondInteger. > neg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. > firstDigitLen <= secondDigitLen > ifTrue: > [shortInt := firstInteger. > shortDigitLen := firstDigitLen. > longInt := secondInteger. > longDigitLen := secondDigitLen] > ifFalse: > [shortInt := secondInteger. > shortDigitLen := secondDigitLen. > longInt := firstInteger. > longDigitLen := firstDigitLen]. > " sum := Integer new: len neg: firstInteger negative." > self remapOop: #(shortInt longInt ) in: [sum := self createLargeIntegerNeg: neg digitLength: longDigitLen]. > + sum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > over := self > cDigitAdd: (self pointerToFirstDigitOfLargeInt: shortInt) > len: shortDigitLen > with: (self pointerToFirstDigitOfLargeInt: longInt) > len: longDigitLen > into: (self pointerToFirstDigitOfLargeInt: sum). > over > 0 > ifTrue: > ["sum := sum growby: 1." > self remapOop: sum in: [newSum := self createLargeIntegerNeg: neg byteLength: longDigitLen * 4 + 1]. > + newSum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > self > cDigitCopyFrom: (self pointerToFirstDigitOfLargeInt: sum) > to: (self pointerToFirstDigitOfLargeInt: newSum) > len: longDigitLen. > sum := newSum. > "C index!!" > self cDigitOf: (self pointerToFirstDigitOfLargeInt: sum) > at: longDigitLen put: over] > ifFalse: > [sum := neg > ifTrue: [self normalizeNegative: sum] > ifFalse: [self normalizePositive: sum]]. > ^ sum! > > Item was changed: > ----- Method: LargeIntegersPlugin>>digitBitLogic:with:opIndex: (in category 'oop functions') ----- > digitBitLogic: firstInteger with: secondInteger opIndex: opIx > "Bit logic here is only implemented for positive integers or Zero; > if rec or arg is negative, it fails." > | firstLarge secondLarge firstLen secondLen shortLen shortLarge longLen longLarge result | > (interpreterProxy isIntegerObject: firstInteger) > ifTrue: > + [(interpreterProxy integerValueOf: firstInteger) < 0 ifTrue: > + [^ interpreterProxy primitiveFail]. > - [(interpreterProxy integerValueOf: firstInteger) > - < 0 ifTrue: [^ interpreterProxy primitiveFail]. > "convert it to a not normalized LargeInteger" > self remapOop: secondInteger in: [firstLarge := self createLargeFromSmallInteger: firstInteger]] > ifFalse: > [(interpreterProxy isLargePositiveIntegerObject: firstInteger) ifFalse: [^ interpreterProxy primitiveFail]. > firstLarge := firstInteger]. > (interpreterProxy isIntegerObject: secondInteger) > ifTrue: > + [(interpreterProxy integerValueOf: secondInteger) < 0 ifTrue: > + [^ interpreterProxy primitiveFail]. > - [(interpreterProxy integerValueOf: secondInteger) > - < 0 ifTrue: [^ interpreterProxy primitiveFail]. > "convert it to a not normalized LargeInteger" > self remapOop: firstLarge in: [secondLarge := self createLargeFromSmallInteger: secondInteger]] > ifFalse: > [(interpreterProxy isLargePositiveIntegerObject: secondInteger) ifFalse: [^ interpreterProxy primitiveFail]. > secondLarge := secondInteger]. > firstLen := self byteSizeOfLargeInt: firstLarge. > secondLen := self byteSizeOfLargeInt: secondLarge. > firstLen < secondLen > ifTrue: > [shortLen := firstLen. > shortLarge := firstLarge. > longLen := secondLen. > longLarge := secondLarge] > ifFalse: > [shortLen := secondLen. > shortLarge := secondLarge. > longLen := firstLen. > longLarge := firstLarge]. > + self remapOop: #(shortLarge longLarge) in: > + [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. > + result ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > - self remapOop: #(shortLarge longLarge ) in: [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. > self > cDigitOp: opIx > short: (self pointerToFirstDigitOfLargeInt: shortLarge) > len: shortLen + 3 // 4 > long: (self pointerToFirstDigitOfLargeInt: longLarge) > len: longLen + 3 // 4 > into: (self pointerToFirstDigitOfLargeInt: result). > interpreterProxy failed ifTrue: [^ 0]. > + ^self normalizePositive: result! > - ^ self normalizePositive: result! > > Item was changed: > ----- Method: LargeIntegersPlugin>>digitMontgomery:times:modulo:mInvModB: (in category 'oop functions') ----- > digitMontgomery: firstLarge times: secondLarge modulo: thirdLarge mInvModB: mInv > > | firstLen secondLen thirdLen prod | > firstLen := self digitSizeOfLargeInt: firstLarge. > secondLen := self digitSizeOfLargeInt: secondLarge. > thirdLen := self digitSizeOfLargeInt: thirdLarge. > (firstLen <= thirdLen and: [secondLen <= thirdLen]) ifFalse: [^interpreterProxy primitiveFail]. > > self remapOop: #(firstLarge secondLarge thirdLarge) > in: [prod := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: thirdLen * 4]. > + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > self > cDigitMontgomery: (self pointerToFirstDigitOfLargeInt: firstLarge) > len: firstLen > times: (self pointerToFirstDigitOfLargeInt: secondLarge) > len: secondLen > modulo: (self pointerToFirstDigitOfLargeInt: thirdLarge) > len: thirdLen > mInvModB: mInv > into: (self pointerToFirstDigitOfLargeInt: prod). > ^self normalizePositive: prod! > > Item was changed: > ----- Method: LargeIntegersPlugin>>digitMultiplyLarge:with:negative: (in category 'oop functions') ----- > digitMultiplyLarge: firstInteger with: secondInteger negative: neg > "Normalizes." > | firstLen secondLen shortInt shortLen longInt longLen prod | > firstLen := self byteSizeOfLargeInt: firstInteger. > secondLen := self byteSizeOfLargeInt: secondInteger. > firstLen <= secondLen > ifTrue: > [shortInt := firstInteger. > shortLen := firstLen. > longInt := secondInteger. > longLen := secondLen] > ifFalse: > [shortInt := secondInteger. > shortLen := secondLen. > longInt := firstInteger. > longLen := firstLen]. > self remapOop: #(shortInt longInt) in: [prod := self createLargeIntegerNeg: neg byteLength: longLen + shortLen]. > + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > self > cDigitMultiply: (self pointerToFirstDigitOfLargeInt: shortInt) > len: shortLen + 3 // 4 > with: (self pointerToFirstDigitOfLargeInt: longInt) > len: longLen + 3 // 4 > into: (self pointerToFirstDigitOfLargeInt: prod) > len: longLen + shortLen + 3 // 4. > ^neg > ifTrue: [self normalizeNegative: prod] > ifFalse: [self normalizePositive: prod]! > > Item was changed: > ----- Method: LargeIntegersPlugin>>digitSubLarge:with: (in category 'oop functions') ----- > digitSubLarge: firstInteger with: secondInteger > "Normalizes." > | firstDigitLen secondDigitLen larger largeDigitLen smaller smallerDigitLen neg resDigitLen res firstNeg | > firstNeg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. > firstDigitLen := self digitSizeOfLargeInt: firstInteger. > secondDigitLen := self digitSizeOfLargeInt: secondInteger. > firstDigitLen = secondDigitLen ifTrue: > [[firstDigitLen > 1 > and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) = (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]] > whileTrue: [firstDigitLen := firstDigitLen - 1]. > secondDigitLen := firstDigitLen]. > (firstDigitLen < secondDigitLen > or: [firstDigitLen = secondDigitLen > and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) < (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]]) > ifTrue: > [larger := secondInteger. > largeDigitLen := secondDigitLen. > smaller := firstInteger. > smallerDigitLen := firstDigitLen. > neg := firstNeg == false] > ifFalse: > [larger := firstInteger. > largeDigitLen := firstDigitLen. > smaller := secondInteger. > smallerDigitLen := secondDigitLen. > neg := firstNeg]. > resDigitLen := largeDigitLen. > self remapOop: #(smaller larger) > in: [res := self createLargeIntegerNeg: neg digitLength: resDigitLen]. > + res ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. > self > cDigitSub: (self pointerToFirstDigitOfLargeInt: smaller) > len: smallerDigitLen > with: (self pointerToFirstDigitOfLargeInt: larger) > len: largeDigitLen > into: (self pointerToFirstDigitOfLargeInt: res). > ^neg > ifTrue: [self normalizeNegative: res] > ifFalse: [self normalizePositive: res]! > From btc at openinworld.com Thu Jun 2 05:49:55 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 2 05:50:17 2016 Subject: [Vm-dev] Amazing ARM simulator experience In-Reply-To: References: Message-ID: On Thu, Jun 2, 2016 at 10:19 AM, Ryan Macnak wrote: > > I'll second that simulators are an essential tool for building a JIT. In the Dart VM, we have our own simulators for ARM, ARM64 and MIPS that allow us to test changes against all the architectures we support, locally on our x64 workstations. When we first got the VM running on iOS, we were even running the ARM simulator on the iPhone to work around the no-JITing-unless-you're-Apple policy (we have since completed an AOT mode). Although it was sluggish compared to its JIT counterpart running on Android, it was certainly usable. And given our loading code is also implemented in Dart, having simulators allows us to cross-compile AOT code for Android and iOS from x64 desktops. One thing I've been contemplating for a while, given that Sista will IIUC cache hotspot info in the Image, enabling a hot-start, would that be a reasonable workaround for Apple's no-JIT policy. You could use unit tests to warm up Sista then code-sign the whole resultant image ?? btw I got curious what exactly the policy[1] was... "Further protection is provided by iOS using ARM?s Execute Never (XN) feature, which marks memory pages as non-executable. Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript JIT compiler." [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf cheers -ben From eliot.miranda at gmail.com Thu Jun 2 09:38:10 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 2 09:38:15 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1878.mcz In-Reply-To: References: <574f84ce.01e5420a.38242.08e4SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <0B9692AC-2212-4349-B6BD-F8C5AF8327D9@gmail.com> Ben, > On Jun 1, 2016, at 10:35 PM, Ben Coman wrote: > > >> On Thu, Jun 2, 2016 at 8:57 AM, wrote: >> >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1878.mcz >> >> ==================== Summary ==================== >> >> Name: VMMaker.oscog-eem.1878 >> Author: eem >> Time: 1 June 2016, 5:56:53.625028 pm >> UUID: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 >> Ancestors: VMMaker.oscog-eem.1877 >> >> Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. >> >> This is clearly unsatisfactory;. the ciode fails to slow Smalltalk code. We'd like to run the GC but Spur's style is not to GC in primitives. > > Hi Eliot, > > Does "not to GC *in* primitives" mean from the Image's or VM's perspective? > > Naively I wonder if your approach to primitives failing due to forwarders > would apply here. If the primitive runs out of space, set a flag > before failing, > and at the same point you test and resolve forwarders, then retry the primitive, > you could check for this flag, run a GC (outside of the primitive from > the VM's perspective?), > then retry the primitive ?? that...is an excellent idea! Beautiful and very easy to implement. The primitive error code can be tested and if it is PrimErrNoMemory the check-for-failure handler can run the GC before retrying. I shall implement this tomorrow. Thanks /very/ much. > cheers -ben > >> If we change the plugin to do GC in primitives we lose the speed advantage of the no-GC style of code. One approach might be to estimate the memory needed as early as possible, and run a GC if not enough memory is available for the result, recomputing base pointers if GC is run. This would avoid the awful remapOop:in: style whioch is pessimistic; it puts things in a stack and takes them back out whether a GC is needed or not. We shoudl use an optimistic algorithm; especially for something as performance sensitive as large integer arithmetic. >> >> =============== Diff against VMMaker.oscog-eem.1877 =============== >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digit:Lshift: (in category 'oop functions') ----- >> digit: anOop Lshift: shiftCount >> "Attention: this method invalidates all oop's!! Only newOop is valid at return." >> "Does not normalize." >> | newOop highBit newDigitLen newByteLen oldDigitLen | >> oldDigitLen := self digitSizeOfLargeInt: anOop. >> (highBit := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) >> len: oldDigitLen) = 0 ifTrue: [^ interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) indexableSize: 1]. >> newByteLen := highBit + shiftCount + 7 // 8. >> + self remapOop: anOop in: >> + [newOop := interpreterProxy >> + instantiateClass: (interpreterProxy fetchClassOf: anOop) >> + indexableSize: newByteLen]. >> + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) >> - indexableSize: newByteLen]. >> newDigitLen := newByteLen + 3 // 4. >> self >> cDigitLshift: shiftCount >> from: (self pointerToFirstDigitOfLargeInt: anOop) >> len: oldDigitLen >> to: (self pointerToFirstDigitOfLargeInt: newOop) >> len: newDigitLen. >> ^ newOop! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digit:Rshift:lookfirst: (in category 'oop functions') ----- >> digit: anOop Rshift: shiftCount lookfirst: a >> "Attention: this method invalidates all oop's!! Only newBytes is valid at return." >> "Shift right 32*digitShift+bitShift bits, 0<=bitShift<32. >> Discard all digits beyond a, and all zeroes at or below a." >> "Does not normalize." >> | newByteLen newOop oldBitLen newBitLen oldDigitLen newDigitLen | >> oldBitLen := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) len: a. >> oldDigitLen := oldBitLen + 31 // 32. >> newBitLen := oldBitLen - shiftCount. >> newBitLen <= 0 ifTrue: ["All bits lost" >> ^ interpreterProxy >> instantiateClass: (interpreterProxy fetchClassOf: anOop) >> indexableSize: 0]. >> newByteLen := newBitLen + 7 // 8. >> newDigitLen := newByteLen + 3 // 4. >> + self remapOop: anOop in: >> + [newOop := interpreterProxy >> + instantiateClass: (interpreterProxy fetchClassOf: anOop) >> + indexableSize: newByteLen]. >> + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) >> - indexableSize: newByteLen]. >> self >> cDigitRshift: shiftCount >> from: (self pointerToFirstDigitOfLargeInt: anOop) >> len: oldDigitLen >> to: (self pointerToFirstDigitOfLargeInt: newOop) >> len: newDigitLen. >> ^ newOop! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitAddLarge:with: (in category 'oop functions') ----- >> digitAddLarge: firstInteger with: secondInteger >> "Does not need to normalize!!" >> | over firstDigitLen secondDigitLen shortInt shortDigitLen longInt longDigitLen sum newSum neg | >> >> firstDigitLen := self digitSizeOfLargeInt: firstInteger. >> secondDigitLen := self digitSizeOfLargeInt: secondInteger. >> neg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. >> firstDigitLen <= secondDigitLen >> ifTrue: >> [shortInt := firstInteger. >> shortDigitLen := firstDigitLen. >> longInt := secondInteger. >> longDigitLen := secondDigitLen] >> ifFalse: >> [shortInt := secondInteger. >> shortDigitLen := secondDigitLen. >> longInt := firstInteger. >> longDigitLen := firstDigitLen]. >> " sum := Integer new: len neg: firstInteger negative." >> self remapOop: #(shortInt longInt ) in: [sum := self createLargeIntegerNeg: neg digitLength: longDigitLen]. >> + sum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> over := self >> cDigitAdd: (self pointerToFirstDigitOfLargeInt: shortInt) >> len: shortDigitLen >> with: (self pointerToFirstDigitOfLargeInt: longInt) >> len: longDigitLen >> into: (self pointerToFirstDigitOfLargeInt: sum). >> over > 0 >> ifTrue: >> ["sum := sum growby: 1." >> self remapOop: sum in: [newSum := self createLargeIntegerNeg: neg byteLength: longDigitLen * 4 + 1]. >> + newSum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitCopyFrom: (self pointerToFirstDigitOfLargeInt: sum) >> to: (self pointerToFirstDigitOfLargeInt: newSum) >> len: longDigitLen. >> sum := newSum. >> "C index!!" >> self cDigitOf: (self pointerToFirstDigitOfLargeInt: sum) >> at: longDigitLen put: over] >> ifFalse: >> [sum := neg >> ifTrue: [self normalizeNegative: sum] >> ifFalse: [self normalizePositive: sum]]. >> ^ sum! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitBitLogic:with:opIndex: (in category 'oop functions') ----- >> digitBitLogic: firstInteger with: secondInteger opIndex: opIx >> "Bit logic here is only implemented for positive integers or Zero; >> if rec or arg is negative, it fails." >> | firstLarge secondLarge firstLen secondLen shortLen shortLarge longLen longLarge result | >> (interpreterProxy isIntegerObject: firstInteger) >> ifTrue: >> + [(interpreterProxy integerValueOf: firstInteger) < 0 ifTrue: >> + [^ interpreterProxy primitiveFail]. >> - [(interpreterProxy integerValueOf: firstInteger) >> - < 0 ifTrue: [^ interpreterProxy primitiveFail]. >> "convert it to a not normalized LargeInteger" >> self remapOop: secondInteger in: [firstLarge := self createLargeFromSmallInteger: firstInteger]] >> ifFalse: >> [(interpreterProxy isLargePositiveIntegerObject: firstInteger) ifFalse: [^ interpreterProxy primitiveFail]. >> firstLarge := firstInteger]. >> (interpreterProxy isIntegerObject: secondInteger) >> ifTrue: >> + [(interpreterProxy integerValueOf: secondInteger) < 0 ifTrue: >> + [^ interpreterProxy primitiveFail]. >> - [(interpreterProxy integerValueOf: secondInteger) >> - < 0 ifTrue: [^ interpreterProxy primitiveFail]. >> "convert it to a not normalized LargeInteger" >> self remapOop: firstLarge in: [secondLarge := self createLargeFromSmallInteger: secondInteger]] >> ifFalse: >> [(interpreterProxy isLargePositiveIntegerObject: secondInteger) ifFalse: [^ interpreterProxy primitiveFail]. >> secondLarge := secondInteger]. >> firstLen := self byteSizeOfLargeInt: firstLarge. >> secondLen := self byteSizeOfLargeInt: secondLarge. >> firstLen < secondLen >> ifTrue: >> [shortLen := firstLen. >> shortLarge := firstLarge. >> longLen := secondLen. >> longLarge := secondLarge] >> ifFalse: >> [shortLen := secondLen. >> shortLarge := secondLarge. >> longLen := firstLen. >> longLarge := firstLarge]. >> + self remapOop: #(shortLarge longLarge) in: >> + [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. >> + result ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> - self remapOop: #(shortLarge longLarge ) in: [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. >> self >> cDigitOp: opIx >> short: (self pointerToFirstDigitOfLargeInt: shortLarge) >> len: shortLen + 3 // 4 >> long: (self pointerToFirstDigitOfLargeInt: longLarge) >> len: longLen + 3 // 4 >> into: (self pointerToFirstDigitOfLargeInt: result). >> interpreterProxy failed ifTrue: [^ 0]. >> + ^self normalizePositive: result! >> - ^ self normalizePositive: result! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitMontgomery:times:modulo:mInvModB: (in category 'oop functions') ----- >> digitMontgomery: firstLarge times: secondLarge modulo: thirdLarge mInvModB: mInv >> >> | firstLen secondLen thirdLen prod | >> firstLen := self digitSizeOfLargeInt: firstLarge. >> secondLen := self digitSizeOfLargeInt: secondLarge. >> thirdLen := self digitSizeOfLargeInt: thirdLarge. >> (firstLen <= thirdLen and: [secondLen <= thirdLen]) ifFalse: [^interpreterProxy primitiveFail]. >> >> self remapOop: #(firstLarge secondLarge thirdLarge) >> in: [prod := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: thirdLen * 4]. >> + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitMontgomery: (self pointerToFirstDigitOfLargeInt: firstLarge) >> len: firstLen >> times: (self pointerToFirstDigitOfLargeInt: secondLarge) >> len: secondLen >> modulo: (self pointerToFirstDigitOfLargeInt: thirdLarge) >> len: thirdLen >> mInvModB: mInv >> into: (self pointerToFirstDigitOfLargeInt: prod). >> ^self normalizePositive: prod! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitMultiplyLarge:with:negative: (in category 'oop functions') ----- >> digitMultiplyLarge: firstInteger with: secondInteger negative: neg >> "Normalizes." >> | firstLen secondLen shortInt shortLen longInt longLen prod | >> firstLen := self byteSizeOfLargeInt: firstInteger. >> secondLen := self byteSizeOfLargeInt: secondInteger. >> firstLen <= secondLen >> ifTrue: >> [shortInt := firstInteger. >> shortLen := firstLen. >> longInt := secondInteger. >> longLen := secondLen] >> ifFalse: >> [shortInt := secondInteger. >> shortLen := secondLen. >> longInt := firstInteger. >> longLen := firstLen]. >> self remapOop: #(shortInt longInt) in: [prod := self createLargeIntegerNeg: neg byteLength: longLen + shortLen]. >> + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitMultiply: (self pointerToFirstDigitOfLargeInt: shortInt) >> len: shortLen + 3 // 4 >> with: (self pointerToFirstDigitOfLargeInt: longInt) >> len: longLen + 3 // 4 >> into: (self pointerToFirstDigitOfLargeInt: prod) >> len: longLen + shortLen + 3 // 4. >> ^neg >> ifTrue: [self normalizeNegative: prod] >> ifFalse: [self normalizePositive: prod]! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitSubLarge:with: (in category 'oop functions') ----- >> digitSubLarge: firstInteger with: secondInteger >> "Normalizes." >> | firstDigitLen secondDigitLen larger largeDigitLen smaller smallerDigitLen neg resDigitLen res firstNeg | >> firstNeg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. >> firstDigitLen := self digitSizeOfLargeInt: firstInteger. >> secondDigitLen := self digitSizeOfLargeInt: secondInteger. >> firstDigitLen = secondDigitLen ifTrue: >> [[firstDigitLen > 1 >> and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) = (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]] >> whileTrue: [firstDigitLen := firstDigitLen - 1]. >> secondDigitLen := firstDigitLen]. >> (firstDigitLen < secondDigitLen >> or: [firstDigitLen = secondDigitLen >> and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) < (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]]) >> ifTrue: >> [larger := secondInteger. >> largeDigitLen := secondDigitLen. >> smaller := firstInteger. >> smallerDigitLen := firstDigitLen. >> neg := firstNeg == false] >> ifFalse: >> [larger := firstInteger. >> largeDigitLen := firstDigitLen. >> smaller := secondInteger. >> smallerDigitLen := secondDigitLen. >> neg := firstNeg]. >> resDigitLen := largeDigitLen. >> self remapOop: #(smaller larger) >> in: [res := self createLargeIntegerNeg: neg digitLength: resDigitLen]. >> + res ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitSub: (self pointerToFirstDigitOfLargeInt: smaller) >> len: smallerDigitLen >> with: (self pointerToFirstDigitOfLargeInt: larger) >> len: largeDigitLen >> into: (self pointerToFirstDigitOfLargeInt: res). >> ^neg >> ifTrue: [self normalizeNegative: res] >> ifFalse: [self normalizePositive: res]! >> From eliot.miranda at gmail.com Thu Jun 2 09:49:28 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 2 09:49:32 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1878.mcz In-Reply-To: References: <574f84ce.01e5420a.38242.08e4SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: > On Jun 1, 2016, at 10:35 PM, Ben Coman wrote: > > >> On Thu, Jun 2, 2016 at 8:57 AM, wrote: >> >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1878.mcz >> >> ==================== Summary ==================== >> >> Name: VMMaker.oscog-eem.1878 >> Author: eem >> Time: 1 June 2016, 5:56:53.625028 pm >> UUID: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 >> Ancestors: VMMaker.oscog-eem.1877 >> >> Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. >> >> This is clearly unsatisfactory;. the ciode fails to slow Smalltalk code. We'd like to run the GC but Spur's style is not to GC in primitives. > > Hi Eliot, > > Does "not to GC *in* primitives" mean from the Image's or VM's perspective? and to answer your question... From the image's perspective it means that the image is in control of when to run the global stop-the-world mark-sweep GC and hence have the choice between FC or growth via adding a memory segment. We don't have a MemoryPolicy yet, but the code is factored to make it possible. This is really grata for flexibility because one can choose a policy that reflects the amount of ram you have in your machine, the behaviour of your app, etc. From the VM's perspective... In V3 primitives must be aware that any vanilla allocation could cause a GC, causing one to have to write in an unnatural and inefficient style. In Spur no objects move during a primitive so that derived pointers into objects (eg the pointers to the first bytes in large integer operands of the large integer primitives) can be held and don't need to be recomputed after GC. Hence in Spur remapOop:in: adds no code to the evaluation of its last block argument, whereas in V3 it pushes and pops the variables named by its first argument to/from the remapBuffer stack in the rare chance that there will be a GC. > Naively I wonder if your approach to primitives failing due to forwarders > would apply here. If the primitive runs out of space, set a flag > before failing, > and at the same point you test and resolve forwarders, then retry the primitive, > you could check for this flag, run a GC (outside of the primitive from > the VM's perspective?), > then retry the primitive ?? Again, cool; thanks!! I love open source ;-) > cheers -ben > >> If we change the plugin to do GC in primitives we lose the speed advantage of the no-GC style of code. One approach might be to estimate the memory needed as early as possible, and run a GC if not enough memory is available for the result, recomputing base pointers if GC is run. This would avoid the awful remapOop:in: style whioch is pessimistic; it puts things in a stack and takes them back out whether a GC is needed or not. We shoudl use an optimistic algorithm; especially for something as performance sensitive as large integer arithmetic. >> >> =============== Diff against VMMaker.oscog-eem.1877 =============== >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digit:Lshift: (in category 'oop functions') ----- >> digit: anOop Lshift: shiftCount >> "Attention: this method invalidates all oop's!! Only newOop is valid at return." >> "Does not normalize." >> | newOop highBit newDigitLen newByteLen oldDigitLen | >> oldDigitLen := self digitSizeOfLargeInt: anOop. >> (highBit := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) >> len: oldDigitLen) = 0 ifTrue: [^ interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) indexableSize: 1]. >> newByteLen := highBit + shiftCount + 7 // 8. >> + self remapOop: anOop in: >> + [newOop := interpreterProxy >> + instantiateClass: (interpreterProxy fetchClassOf: anOop) >> + indexableSize: newByteLen]. >> + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) >> - indexableSize: newByteLen]. >> newDigitLen := newByteLen + 3 // 4. >> self >> cDigitLshift: shiftCount >> from: (self pointerToFirstDigitOfLargeInt: anOop) >> len: oldDigitLen >> to: (self pointerToFirstDigitOfLargeInt: newOop) >> len: newDigitLen. >> ^ newOop! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digit:Rshift:lookfirst: (in category 'oop functions') ----- >> digit: anOop Rshift: shiftCount lookfirst: a >> "Attention: this method invalidates all oop's!! Only newBytes is valid at return." >> "Shift right 32*digitShift+bitShift bits, 0<=bitShift<32. >> Discard all digits beyond a, and all zeroes at or below a." >> "Does not normalize." >> | newByteLen newOop oldBitLen newBitLen oldDigitLen newDigitLen | >> oldBitLen := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) len: a. >> oldDigitLen := oldBitLen + 31 // 32. >> newBitLen := oldBitLen - shiftCount. >> newBitLen <= 0 ifTrue: ["All bits lost" >> ^ interpreterProxy >> instantiateClass: (interpreterProxy fetchClassOf: anOop) >> indexableSize: 0]. >> newByteLen := newBitLen + 7 // 8. >> newDigitLen := newByteLen + 3 // 4. >> + self remapOop: anOop in: >> + [newOop := interpreterProxy >> + instantiateClass: (interpreterProxy fetchClassOf: anOop) >> + indexableSize: newByteLen]. >> + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) >> - indexableSize: newByteLen]. >> self >> cDigitRshift: shiftCount >> from: (self pointerToFirstDigitOfLargeInt: anOop) >> len: oldDigitLen >> to: (self pointerToFirstDigitOfLargeInt: newOop) >> len: newDigitLen. >> ^ newOop! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitAddLarge:with: (in category 'oop functions') ----- >> digitAddLarge: firstInteger with: secondInteger >> "Does not need to normalize!!" >> | over firstDigitLen secondDigitLen shortInt shortDigitLen longInt longDigitLen sum newSum neg | >> >> firstDigitLen := self digitSizeOfLargeInt: firstInteger. >> secondDigitLen := self digitSizeOfLargeInt: secondInteger. >> neg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. >> firstDigitLen <= secondDigitLen >> ifTrue: >> [shortInt := firstInteger. >> shortDigitLen := firstDigitLen. >> longInt := secondInteger. >> longDigitLen := secondDigitLen] >> ifFalse: >> [shortInt := secondInteger. >> shortDigitLen := secondDigitLen. >> longInt := firstInteger. >> longDigitLen := firstDigitLen]. >> " sum := Integer new: len neg: firstInteger negative." >> self remapOop: #(shortInt longInt ) in: [sum := self createLargeIntegerNeg: neg digitLength: longDigitLen]. >> + sum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> over := self >> cDigitAdd: (self pointerToFirstDigitOfLargeInt: shortInt) >> len: shortDigitLen >> with: (self pointerToFirstDigitOfLargeInt: longInt) >> len: longDigitLen >> into: (self pointerToFirstDigitOfLargeInt: sum). >> over > 0 >> ifTrue: >> ["sum := sum growby: 1." >> self remapOop: sum in: [newSum := self createLargeIntegerNeg: neg byteLength: longDigitLen * 4 + 1]. >> + newSum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitCopyFrom: (self pointerToFirstDigitOfLargeInt: sum) >> to: (self pointerToFirstDigitOfLargeInt: newSum) >> len: longDigitLen. >> sum := newSum. >> "C index!!" >> self cDigitOf: (self pointerToFirstDigitOfLargeInt: sum) >> at: longDigitLen put: over] >> ifFalse: >> [sum := neg >> ifTrue: [self normalizeNegative: sum] >> ifFalse: [self normalizePositive: sum]]. >> ^ sum! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitBitLogic:with:opIndex: (in category 'oop functions') ----- >> digitBitLogic: firstInteger with: secondInteger opIndex: opIx >> "Bit logic here is only implemented for positive integers or Zero; >> if rec or arg is negative, it fails." >> | firstLarge secondLarge firstLen secondLen shortLen shortLarge longLen longLarge result | >> (interpreterProxy isIntegerObject: firstInteger) >> ifTrue: >> + [(interpreterProxy integerValueOf: firstInteger) < 0 ifTrue: >> + [^ interpreterProxy primitiveFail]. >> - [(interpreterProxy integerValueOf: firstInteger) >> - < 0 ifTrue: [^ interpreterProxy primitiveFail]. >> "convert it to a not normalized LargeInteger" >> self remapOop: secondInteger in: [firstLarge := self createLargeFromSmallInteger: firstInteger]] >> ifFalse: >> [(interpreterProxy isLargePositiveIntegerObject: firstInteger) ifFalse: [^ interpreterProxy primitiveFail]. >> firstLarge := firstInteger]. >> (interpreterProxy isIntegerObject: secondInteger) >> ifTrue: >> + [(interpreterProxy integerValueOf: secondInteger) < 0 ifTrue: >> + [^ interpreterProxy primitiveFail]. >> - [(interpreterProxy integerValueOf: secondInteger) >> - < 0 ifTrue: [^ interpreterProxy primitiveFail]. >> "convert it to a not normalized LargeInteger" >> self remapOop: firstLarge in: [secondLarge := self createLargeFromSmallInteger: secondInteger]] >> ifFalse: >> [(interpreterProxy isLargePositiveIntegerObject: secondInteger) ifFalse: [^ interpreterProxy primitiveFail]. >> secondLarge := secondInteger]. >> firstLen := self byteSizeOfLargeInt: firstLarge. >> secondLen := self byteSizeOfLargeInt: secondLarge. >> firstLen < secondLen >> ifTrue: >> [shortLen := firstLen. >> shortLarge := firstLarge. >> longLen := secondLen. >> longLarge := secondLarge] >> ifFalse: >> [shortLen := secondLen. >> shortLarge := secondLarge. >> longLen := firstLen. >> longLarge := firstLarge]. >> + self remapOop: #(shortLarge longLarge) in: >> + [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. >> + result ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> - self remapOop: #(shortLarge longLarge ) in: [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. >> self >> cDigitOp: opIx >> short: (self pointerToFirstDigitOfLargeInt: shortLarge) >> len: shortLen + 3 // 4 >> long: (self pointerToFirstDigitOfLargeInt: longLarge) >> len: longLen + 3 // 4 >> into: (self pointerToFirstDigitOfLargeInt: result). >> interpreterProxy failed ifTrue: [^ 0]. >> + ^self normalizePositive: result! >> - ^ self normalizePositive: result! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitMontgomery:times:modulo:mInvModB: (in category 'oop functions') ----- >> digitMontgomery: firstLarge times: secondLarge modulo: thirdLarge mInvModB: mInv >> >> | firstLen secondLen thirdLen prod | >> firstLen := self digitSizeOfLargeInt: firstLarge. >> secondLen := self digitSizeOfLargeInt: secondLarge. >> thirdLen := self digitSizeOfLargeInt: thirdLarge. >> (firstLen <= thirdLen and: [secondLen <= thirdLen]) ifFalse: [^interpreterProxy primitiveFail]. >> >> self remapOop: #(firstLarge secondLarge thirdLarge) >> in: [prod := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: thirdLen * 4]. >> + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitMontgomery: (self pointerToFirstDigitOfLargeInt: firstLarge) >> len: firstLen >> times: (self pointerToFirstDigitOfLargeInt: secondLarge) >> len: secondLen >> modulo: (self pointerToFirstDigitOfLargeInt: thirdLarge) >> len: thirdLen >> mInvModB: mInv >> into: (self pointerToFirstDigitOfLargeInt: prod). >> ^self normalizePositive: prod! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitMultiplyLarge:with:negative: (in category 'oop functions') ----- >> digitMultiplyLarge: firstInteger with: secondInteger negative: neg >> "Normalizes." >> | firstLen secondLen shortInt shortLen longInt longLen prod | >> firstLen := self byteSizeOfLargeInt: firstInteger. >> secondLen := self byteSizeOfLargeInt: secondInteger. >> firstLen <= secondLen >> ifTrue: >> [shortInt := firstInteger. >> shortLen := firstLen. >> longInt := secondInteger. >> longLen := secondLen] >> ifFalse: >> [shortInt := secondInteger. >> shortLen := secondLen. >> longInt := firstInteger. >> longLen := firstLen]. >> self remapOop: #(shortInt longInt) in: [prod := self createLargeIntegerNeg: neg byteLength: longLen + shortLen]. >> + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitMultiply: (self pointerToFirstDigitOfLargeInt: shortInt) >> len: shortLen + 3 // 4 >> with: (self pointerToFirstDigitOfLargeInt: longInt) >> len: longLen + 3 // 4 >> into: (self pointerToFirstDigitOfLargeInt: prod) >> len: longLen + shortLen + 3 // 4. >> ^neg >> ifTrue: [self normalizeNegative: prod] >> ifFalse: [self normalizePositive: prod]! >> >> Item was changed: >> ----- Method: LargeIntegersPlugin>>digitSubLarge:with: (in category 'oop functions') ----- >> digitSubLarge: firstInteger with: secondInteger >> "Normalizes." >> | firstDigitLen secondDigitLen larger largeDigitLen smaller smallerDigitLen neg resDigitLen res firstNeg | >> firstNeg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. >> firstDigitLen := self digitSizeOfLargeInt: firstInteger. >> secondDigitLen := self digitSizeOfLargeInt: secondInteger. >> firstDigitLen = secondDigitLen ifTrue: >> [[firstDigitLen > 1 >> and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) = (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]] >> whileTrue: [firstDigitLen := firstDigitLen - 1]. >> secondDigitLen := firstDigitLen]. >> (firstDigitLen < secondDigitLen >> or: [firstDigitLen = secondDigitLen >> and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) < (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]]) >> ifTrue: >> [larger := secondInteger. >> largeDigitLen := secondDigitLen. >> smaller := firstInteger. >> smallerDigitLen := firstDigitLen. >> neg := firstNeg == false] >> ifFalse: >> [larger := firstInteger. >> largeDigitLen := firstDigitLen. >> smaller := secondInteger. >> smallerDigitLen := secondDigitLen. >> neg := firstNeg]. >> resDigitLen := largeDigitLen. >> self remapOop: #(smaller larger) >> in: [res := self createLargeIntegerNeg: neg digitLength: resDigitLen]. >> + res ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >> self >> cDigitSub: (self pointerToFirstDigitOfLargeInt: smaller) >> len: smallerDigitLen >> with: (self pointerToFirstDigitOfLargeInt: larger) >> len: largeDigitLen >> into: (self pointerToFirstDigitOfLargeInt: res). >> ^neg >> ifTrue: [self normalizeNegative: res] >> ifFalse: [self normalizePositive: res]! >> From bera.clement at gmail.com Thu Jun 2 10:10:59 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Thu Jun 2 10:11:22 2016 Subject: [Vm-dev] Amazing ARM simulator experience In-Reply-To: References: Message-ID: On Thu, Jun 2, 2016 at 7:49 AM, Ben Coman wrote: > > On Thu, Jun 2, 2016 at 10:19 AM, Ryan Macnak wrote: > > > > I'll second that simulators are an essential tool for building a JIT. In > the Dart VM, we have our own simulators for ARM, ARM64 and MIPS that allow > us to test changes against all the architectures we support, locally on our > x64 workstations. When we first got the VM running on iOS, we were even > running the ARM simulator on the iPhone to work around the > no-JITing-unless-you're-Apple policy (we have since completed an AOT mode). > Although it was sluggish compared to its JIT counterpart running on > Android, it was certainly usable. And given our loading code is also > implemented in Dart, having simulators allows us to cross-compile AOT code > for Android and iOS from x64 desktops. > > > One thing I've been contemplating for a while, given that Sista will > IIUC cache hotspot info in the Image, enabling a hot-start, would that > be a reasonable workaround for Apple's no-JIT policy. You could use > unit tests to warm up Sista then code-sign the whole resultant image > ?? > > > Yes and no. One problem is that the sista image has optimized code in the form of bytecoded method. The baseline JIT is still required to generate the machine code. So the application would need a prepackaged machine code zone, which is not possible without some work right now. Currently sista methods are optimized to use the baseline JIT as the back-end and are not optimized for the interpreter. Another problem is things like inline caches that patch the machine code. We would need to change that logic. One way would be to keep in the cache values in a non executable memory zone, another one would be to have inline cache failure never patch the code. Currently the Stack VM works on iOS and the Stack VM interpreter is very fast (between 10 and 20% overhead compared to the ASM template production version of Java's hotspot). There are multiple solutions to boost the performance on iOS using the existing infrastructure, but there is no obvious way on how to make that production ready in less than (optimistically) 6 months of work. > btw I got curious what exactly the policy[1] was... "Further > protection is provided by iOS using ARM?s Execute Never (XN) feature, > which marks memory pages as non-executable. Memory pages marked as > both writable and executable can be used only by apps under tightly > controlled conditions: The kernel checks for the presence of the > Apple-only dynamic code-signing entitlement. Even then, only a single > mmap call can be made to request an executable and writable page, > which is given a randomized address. Safari uses this functionality > for its JavaScript JIT compiler." > Ahah. "Apple-only". How fancy. > > [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf > > cheers -ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160602/7e5273bd/attachment-0001.htm From lists at fniephaus.com Thu Jun 2 10:12:29 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Thu Jun 2 10:12:41 2016 Subject: [Vm-dev] Re: [squeak-dev] 2 raisedTo: 100000000` crashes VM In-Reply-To: References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> Message-ID: Thanks, Eliot! On Thu, Jun 2, 2016 at 3:19 AM Eliot Miranda wrote: > Thanks all, > > On Wed, Jun 1, 2016 at 1:48 PM, Bert Freudenberg > wrote: > >> On 01.06.2016, at 19:45, Eliot Miranda wrote: >> > (2 raisedTo: 100000000) basicSize >> > So which VM does it fail on? >> >> Mac Spur 5.0.3692 >> >> - Bert - > > > OK, tis fixed in VMMaker.oscog-eem.1879. > > Reporting - 774 tallies, 6,836 msec. > > **Tree** > ... > [100 (6,836) [] SmalltalkEditor(TextEditor) evaluateSelectionAndDo: > [ 100 (6,836) Compiler evaluate:in:to:notifying:ifFail:logged: > [ 100 (6,836) Compiler evaluateCue:ifFail:logged: > [ 100 (6,836) Compiler evaluateCue:ifFail: > [ 100 (6,836) UndefinedObject DoIt > [ 100 (6,836) AndreasSystemProfiler class spyOn: > [ 100 (6,836) BlockClosure ensure: > [ 100 (6,836) [] AndreasSystemProfiler class spyOn: > [ 100 (6,836) AndreasSystemProfiler spyOn: > [ 100 (6,836) BlockClosure ensure: > [ 100 (6,836) [] UndefinedObject DoIt > [ 100 (6,836) SmallInteger(Integer) timesRepeat: > [ 100 (6,836) [[]] UndefinedObject DoIt > [ 100 (6,836) SmallInteger(Number) raisedTo: > [ 100 (6,836) SmallInteger(Number) > raisedToInteger: > [ 98.45 (6,730) LargePositiveInteger * > [ 98.44 (6,730) > LargePositiveInteger(Integer) * > [ 98.44 (6,730) > LargePositiveInteger(Integer) digitMultiply:neg: > [ 50.36 (3,442) SmalltalkImage > primitiveGarbageCollect > [ 28.3 (1,935) LargePositiveInteger > normalize > [ 28.3 (1,935) > LargePositiveInteger(Integer) growto: > [ 28.26 (1,932) > LargePositiveInteger(Integer) copyto: > [ 28.26 (1,932) SmalltalkImage > primitiveGarbageCollect > **Leaves** > 78.61 (5,374) SmalltalkImage primitiveGarbageCollect > > **Memory** > old -16,777,216 bytes > young +15,421,544 bytes > used -1,355,672 bytes > free -15,421,544 bytes > > **GCs** > full 14 totalling 5,279ms (77.0% uptime), avg 377.0ms > incr 1 totalling 0ms (0.0% uptime), avg 0.0ms > tenures 0 > root table 0 overflows > > **Processes** > Total process switches: 1596 > Without Profiler: 48 > Stack page overflows: 4567 > Stack page divorces: 15 > > > > > -- > _,,,^..^,,,_ > best, Eliot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160602/217a0e95/attachment.htm From bert at freudenbergs.de Thu Jun 2 10:24:38 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Jun 2 10:24:43 2016 Subject: [Vm-dev] Re: 2 raisedTo: 100000000` crashes VM In-Reply-To: References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> Message-ID: <913182FE-1E10-47AD-9C24-6C47EB0C70D2@freudenbergs.de> On 02.06.2016, at 03:19, Eliot Miranda wrote: > OK, tis fixed in VMMaker.oscog-eem.1879. > > Reporting - 774 tallies, 6,836 msec. Nice! Is this finally a benchmark where SqueakJS can beat other VMs? [10 timesRepeat: [(2 raisedTo: 100000000) basicSize]] timeToRun Interp: 18042 ms Cog: 7965 ms Spur: ? SqueakJS: 2821 ms (*) :D - Bert - (*) http://bertfreudenberg.github.io/SqueakJS/run/#url=http://freudenbergs.de/bert/squeakjs&files=[Squeak4.5-13680.image,Squeak4.5-13680.changes,SqueakV41.sources] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4207 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160602/5c65ad0f/smime.bin From btc at openinworld.com Thu Jun 2 13:14:47 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 2 13:15:11 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1878.mcz In-Reply-To: <0B9692AC-2212-4349-B6BD-F8C5AF8327D9@gmail.com> References: <574f84ce.01e5420a.38242.08e4SMTPIN_ADDED_MISSING@mx.google.com> <0B9692AC-2212-4349-B6BD-F8C5AF8327D9@gmail.com> Message-ID: On Thu, Jun 2, 2016 at 5:38 PM, Eliot Miranda wrote: > > Ben, > >> On Jun 1, 2016, at 10:35 PM, Ben Coman wrote: >> >> >>> On Thu, Jun 2, 2016 at 8:57 AM, wrote: >>> >>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1878.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: VMMaker.oscog-eem.1878 >>> Author: eem >>> Time: 1 June 2016, 5:56:53.625028 pm >>> UUID: 71f5bdb3-74c3-4a8c-bbb9-c78c327e4823 >>> Ancestors: VMMaker.oscog-eem.1877 >>> >>> Check for allocation failure in the LargeIntegersPlugin and fail primitives when space runs out. >>> >>> This is clearly unsatisfactory;. the ciode fails to slow Smalltalk code. We'd like to run the GC but Spur's style is not to GC in primitives. >> >> Hi Eliot, >> >> Does "not to GC *in* primitives" mean from the Image's or VM's perspective? >> >> Naively I wonder if your approach to primitives failing due to forwarders >> would apply here. If the primitive runs out of space, set a flag >> before failing, >> and at the same point you test and resolve forwarders, then retry the primitive, >> you could check for this flag, run a GC (outside of the primitive from >> the VM's perspective?), >> then retry the primitive ?? > > that...is an excellent idea! Beautiful and very easy to implement. The primitive error code can be tested and if it is PrimErrNoMemory the check-for-failure handler can run the GC before retrying. I shall implement this tomorrow. Thanks /very/ much. Call it payback for time invested in my newbie VM questions :) :) Yes, open source is cool! Many eyeballs and all that jazz. cheers -ben > >> cheers -ben >> >>> If we change the plugin to do GC in primitives we lose the speed advantage of the no-GC style of code. One approach might be to estimate the memory needed as early as possible, and run a GC if not enough memory is available for the result, recomputing base pointers if GC is run. This would avoid the awful remapOop:in: style whioch is pessimistic; it puts things in a stack and takes them back out whether a GC is needed or not. We shoudl use an optimistic algorithm; especially for something as performance sensitive as large integer arithmetic. >>> >>> =============== Diff against VMMaker.oscog-eem.1877 =============== >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digit:Lshift: (in category 'oop functions') ----- >>> digit: anOop Lshift: shiftCount >>> "Attention: this method invalidates all oop's!! Only newOop is valid at return." >>> "Does not normalize." >>> | newOop highBit newDigitLen newByteLen oldDigitLen | >>> oldDigitLen := self digitSizeOfLargeInt: anOop. >>> (highBit := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) >>> len: oldDigitLen) = 0 ifTrue: [^ interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) indexableSize: 1]. >>> newByteLen := highBit + shiftCount + 7 // 8. >>> + self remapOop: anOop in: >>> + [newOop := interpreterProxy >>> + instantiateClass: (interpreterProxy fetchClassOf: anOop) >>> + indexableSize: newByteLen]. >>> + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) >>> - indexableSize: newByteLen]. >>> newDigitLen := newByteLen + 3 // 4. >>> self >>> cDigitLshift: shiftCount >>> from: (self pointerToFirstDigitOfLargeInt: anOop) >>> len: oldDigitLen >>> to: (self pointerToFirstDigitOfLargeInt: newOop) >>> len: newDigitLen. >>> ^ newOop! >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digit:Rshift:lookfirst: (in category 'oop functions') ----- >>> digit: anOop Rshift: shiftCount lookfirst: a >>> "Attention: this method invalidates all oop's!! Only newBytes is valid at return." >>> "Shift right 32*digitShift+bitShift bits, 0<=bitShift<32. >>> Discard all digits beyond a, and all zeroes at or below a." >>> "Does not normalize." >>> | newByteLen newOop oldBitLen newBitLen oldDigitLen newDigitLen | >>> oldBitLen := self cDigitHighBit: (self pointerToFirstDigitOfLargeInt: anOop) len: a. >>> oldDigitLen := oldBitLen + 31 // 32. >>> newBitLen := oldBitLen - shiftCount. >>> newBitLen <= 0 ifTrue: ["All bits lost" >>> ^ interpreterProxy >>> instantiateClass: (interpreterProxy fetchClassOf: anOop) >>> indexableSize: 0]. >>> newByteLen := newBitLen + 7 // 8. >>> newDigitLen := newByteLen + 3 // 4. >>> + self remapOop: anOop in: >>> + [newOop := interpreterProxy >>> + instantiateClass: (interpreterProxy fetchClassOf: anOop) >>> + indexableSize: newByteLen]. >>> + newOop ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> - self remapOop: anOop in: [newOop := interpreterProxy instantiateClass: (interpreterProxy fetchClassOf: anOop) >>> - indexableSize: newByteLen]. >>> self >>> cDigitRshift: shiftCount >>> from: (self pointerToFirstDigitOfLargeInt: anOop) >>> len: oldDigitLen >>> to: (self pointerToFirstDigitOfLargeInt: newOop) >>> len: newDigitLen. >>> ^ newOop! >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digitAddLarge:with: (in category 'oop functions') ----- >>> digitAddLarge: firstInteger with: secondInteger >>> "Does not need to normalize!!" >>> | over firstDigitLen secondDigitLen shortInt shortDigitLen longInt longDigitLen sum newSum neg | >>> >>> firstDigitLen := self digitSizeOfLargeInt: firstInteger. >>> secondDigitLen := self digitSizeOfLargeInt: secondInteger. >>> neg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. >>> firstDigitLen <= secondDigitLen >>> ifTrue: >>> [shortInt := firstInteger. >>> shortDigitLen := firstDigitLen. >>> longInt := secondInteger. >>> longDigitLen := secondDigitLen] >>> ifFalse: >>> [shortInt := secondInteger. >>> shortDigitLen := secondDigitLen. >>> longInt := firstInteger. >>> longDigitLen := firstDigitLen]. >>> " sum := Integer new: len neg: firstInteger negative." >>> self remapOop: #(shortInt longInt ) in: [sum := self createLargeIntegerNeg: neg digitLength: longDigitLen]. >>> + sum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> over := self >>> cDigitAdd: (self pointerToFirstDigitOfLargeInt: shortInt) >>> len: shortDigitLen >>> with: (self pointerToFirstDigitOfLargeInt: longInt) >>> len: longDigitLen >>> into: (self pointerToFirstDigitOfLargeInt: sum). >>> over > 0 >>> ifTrue: >>> ["sum := sum growby: 1." >>> self remapOop: sum in: [newSum := self createLargeIntegerNeg: neg byteLength: longDigitLen * 4 + 1]. >>> + newSum ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> self >>> cDigitCopyFrom: (self pointerToFirstDigitOfLargeInt: sum) >>> to: (self pointerToFirstDigitOfLargeInt: newSum) >>> len: longDigitLen. >>> sum := newSum. >>> "C index!!" >>> self cDigitOf: (self pointerToFirstDigitOfLargeInt: sum) >>> at: longDigitLen put: over] >>> ifFalse: >>> [sum := neg >>> ifTrue: [self normalizeNegative: sum] >>> ifFalse: [self normalizePositive: sum]]. >>> ^ sum! >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digitBitLogic:with:opIndex: (in category 'oop functions') ----- >>> digitBitLogic: firstInteger with: secondInteger opIndex: opIx >>> "Bit logic here is only implemented for positive integers or Zero; >>> if rec or arg is negative, it fails." >>> | firstLarge secondLarge firstLen secondLen shortLen shortLarge longLen longLarge result | >>> (interpreterProxy isIntegerObject: firstInteger) >>> ifTrue: >>> + [(interpreterProxy integerValueOf: firstInteger) < 0 ifTrue: >>> + [^ interpreterProxy primitiveFail]. >>> - [(interpreterProxy integerValueOf: firstInteger) >>> - < 0 ifTrue: [^ interpreterProxy primitiveFail]. >>> "convert it to a not normalized LargeInteger" >>> self remapOop: secondInteger in: [firstLarge := self createLargeFromSmallInteger: firstInteger]] >>> ifFalse: >>> [(interpreterProxy isLargePositiveIntegerObject: firstInteger) ifFalse: [^ interpreterProxy primitiveFail]. >>> firstLarge := firstInteger]. >>> (interpreterProxy isIntegerObject: secondInteger) >>> ifTrue: >>> + [(interpreterProxy integerValueOf: secondInteger) < 0 ifTrue: >>> + [^ interpreterProxy primitiveFail]. >>> - [(interpreterProxy integerValueOf: secondInteger) >>> - < 0 ifTrue: [^ interpreterProxy primitiveFail]. >>> "convert it to a not normalized LargeInteger" >>> self remapOop: firstLarge in: [secondLarge := self createLargeFromSmallInteger: secondInteger]] >>> ifFalse: >>> [(interpreterProxy isLargePositiveIntegerObject: secondInteger) ifFalse: [^ interpreterProxy primitiveFail]. >>> secondLarge := secondInteger]. >>> firstLen := self byteSizeOfLargeInt: firstLarge. >>> secondLen := self byteSizeOfLargeInt: secondLarge. >>> firstLen < secondLen >>> ifTrue: >>> [shortLen := firstLen. >>> shortLarge := firstLarge. >>> longLen := secondLen. >>> longLarge := secondLarge] >>> ifFalse: >>> [shortLen := secondLen. >>> shortLarge := secondLarge. >>> longLen := firstLen. >>> longLarge := firstLarge]. >>> + self remapOop: #(shortLarge longLarge) in: >>> + [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. >>> + result ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> - self remapOop: #(shortLarge longLarge ) in: [result := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: longLen]. >>> self >>> cDigitOp: opIx >>> short: (self pointerToFirstDigitOfLargeInt: shortLarge) >>> len: shortLen + 3 // 4 >>> long: (self pointerToFirstDigitOfLargeInt: longLarge) >>> len: longLen + 3 // 4 >>> into: (self pointerToFirstDigitOfLargeInt: result). >>> interpreterProxy failed ifTrue: [^ 0]. >>> + ^self normalizePositive: result! >>> - ^ self normalizePositive: result! >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digitMontgomery:times:modulo:mInvModB: (in category 'oop functions') ----- >>> digitMontgomery: firstLarge times: secondLarge modulo: thirdLarge mInvModB: mInv >>> >>> | firstLen secondLen thirdLen prod | >>> firstLen := self digitSizeOfLargeInt: firstLarge. >>> secondLen := self digitSizeOfLargeInt: secondLarge. >>> thirdLen := self digitSizeOfLargeInt: thirdLarge. >>> (firstLen <= thirdLen and: [secondLen <= thirdLen]) ifFalse: [^interpreterProxy primitiveFail]. >>> >>> self remapOop: #(firstLarge secondLarge thirdLarge) >>> in: [prod := interpreterProxy instantiateClass: interpreterProxy classLargePositiveInteger indexableSize: thirdLen * 4]. >>> + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> self >>> cDigitMontgomery: (self pointerToFirstDigitOfLargeInt: firstLarge) >>> len: firstLen >>> times: (self pointerToFirstDigitOfLargeInt: secondLarge) >>> len: secondLen >>> modulo: (self pointerToFirstDigitOfLargeInt: thirdLarge) >>> len: thirdLen >>> mInvModB: mInv >>> into: (self pointerToFirstDigitOfLargeInt: prod). >>> ^self normalizePositive: prod! >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digitMultiplyLarge:with:negative: (in category 'oop functions') ----- >>> digitMultiplyLarge: firstInteger with: secondInteger negative: neg >>> "Normalizes." >>> | firstLen secondLen shortInt shortLen longInt longLen prod | >>> firstLen := self byteSizeOfLargeInt: firstInteger. >>> secondLen := self byteSizeOfLargeInt: secondInteger. >>> firstLen <= secondLen >>> ifTrue: >>> [shortInt := firstInteger. >>> shortLen := firstLen. >>> longInt := secondInteger. >>> longLen := secondLen] >>> ifFalse: >>> [shortInt := secondInteger. >>> shortLen := secondLen. >>> longInt := firstInteger. >>> longLen := firstLen]. >>> self remapOop: #(shortInt longInt) in: [prod := self createLargeIntegerNeg: neg byteLength: longLen + shortLen]. >>> + prod ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> self >>> cDigitMultiply: (self pointerToFirstDigitOfLargeInt: shortInt) >>> len: shortLen + 3 // 4 >>> with: (self pointerToFirstDigitOfLargeInt: longInt) >>> len: longLen + 3 // 4 >>> into: (self pointerToFirstDigitOfLargeInt: prod) >>> len: longLen + shortLen + 3 // 4. >>> ^neg >>> ifTrue: [self normalizeNegative: prod] >>> ifFalse: [self normalizePositive: prod]! >>> >>> Item was changed: >>> ----- Method: LargeIntegersPlugin>>digitSubLarge:with: (in category 'oop functions') ----- >>> digitSubLarge: firstInteger with: secondInteger >>> "Normalizes." >>> | firstDigitLen secondDigitLen larger largeDigitLen smaller smallerDigitLen neg resDigitLen res firstNeg | >>> firstNeg := interpreterProxy isLargeNegativeIntegerObject: firstInteger. >>> firstDigitLen := self digitSizeOfLargeInt: firstInteger. >>> secondDigitLen := self digitSizeOfLargeInt: secondInteger. >>> firstDigitLen = secondDigitLen ifTrue: >>> [[firstDigitLen > 1 >>> and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) = (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]] >>> whileTrue: [firstDigitLen := firstDigitLen - 1]. >>> secondDigitLen := firstDigitLen]. >>> (firstDigitLen < secondDigitLen >>> or: [firstDigitLen = secondDigitLen >>> and: [(self unsafeDigitOfLargeInt: firstInteger at: firstDigitLen) < (self unsafeDigitOfLargeInt: secondInteger at: firstDigitLen)]]) >>> ifTrue: >>> [larger := secondInteger. >>> largeDigitLen := secondDigitLen. >>> smaller := firstInteger. >>> smallerDigitLen := firstDigitLen. >>> neg := firstNeg == false] >>> ifFalse: >>> [larger := firstInteger. >>> largeDigitLen := firstDigitLen. >>> smaller := secondInteger. >>> smallerDigitLen := secondDigitLen. >>> neg := firstNeg]. >>> resDigitLen := largeDigitLen. >>> self remapOop: #(smaller larger) >>> in: [res := self createLargeIntegerNeg: neg digitLength: resDigitLen]. >>> + res ifNil: [^interpreterProxy primitiveFailFor: PrimErrNoMemory]. >>> self >>> cDigitSub: (self pointerToFirstDigitOfLargeInt: smaller) >>> len: smallerDigitLen >>> with: (self pointerToFirstDigitOfLargeInt: larger) >>> len: largeDigitLen >>> into: (self pointerToFirstDigitOfLargeInt: res). >>> ^neg >>> ifTrue: [self normalizeNegative: res] >>> ifFalse: [self normalizePositive: res]! >>> From btc at openinworld.com Fri Jun 3 04:52:09 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 3 04:52:36 2016 Subject: [Vm-dev] primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) Message-ID: On Sun, May 22, 2016 at 2:15 AM, Eliot Miranda wrote: > > On Fri, May 20, 2016 at 7:52 PM, Ben Coman wrote: >> >> On Sat, May 21, 2016 at 4:36 AM, Cl?ment Bera wrote: >> > >> > On Fri, May 20, 2016 at 7:51 PM, Ben Coman wrote: >> >> >> >> On Fri, May 20, 2016 at 9:25 PM, Cl?ment Bera wrote: >> >> > On Thu, May 19, 2016 at 3:42 PM, Ben Coman wrote: >> > There is a better way of solving this, and that is to use a pragma to identify a method that contains such a suspension point, and have the process terminate code look for the pragma and act accordingly. For example, the pragma could have a terminate action, sent to the receiver with the context as argument, e.g. > > Mutex>>critical: mutuallyExcludedBlock > > ^lock waitAcquire > ifNil: mutuallyExcludedBlock > ifNotNil:[ mutuallyExcludedBlock ensure: [lock release] ] > > (and here I'm guessing...) > > Mutex>> ensureMutexUnlockedInCritical: aContext > "long-winded comment explaining the corner case, referencing tests, etc, etc and how it is solved on terminate buy this method" > (aContext pc = aContext initialPC > and: [self inTheCorner]) ifTrue: > [self doTheRightThingTM] > > So on terminate the stack is walked (it is anyway) looking for unwinds or onTerminate: markers. Any onTerminate: markers are evaluated, and the corner case is solved. The pragma approach also allows for visibility in the code. I think this general < onTerminate: > pragma might be useful, but I'd like to keep it in the back pocket for the moment while I explore another idea for primitive retry after a process resumes. I still have a concern that #primitiveOwnedLockWaitAcquire sleeps at the bottom of the primitive, thus if the sleeping process is resumed, it continues into the critical section without having gained the mutex, which seems a bit fragile. Retrying #primitiveOwnedLockWaitAcquire immediately after waking would effectively have the process sleep at the top of the primitive, and *not*proceed until it *really* holds the lock.. So I'm thinking out loud here to formulate my thoughts, and in case there is some major impediment you can help me fail fast... One possibility is putting "self maybeRetryFailureAfterWaking" in #slowPrimitiveResponse, similar to maybeRetryFailureDueToForwarding and (guessing) maybeRetryFailureDueToLowMemory. The difficulty seems to be that process's primFailCode doesn't hold across process suspension(??). As an aside, it seems fragile that IIUC it is possible for primFailCode to be set by one process, which if then suspended will carry over to fail the new active process. Perhaps somewhere like externalSetStackPageAndPointersForSuspendedContextOfProcess: should zero primFailCode. Anyway... I thought one way to retain primFailCode across process suspension might be to push it to the stack in #transferTo: and pop primFailCode from the stack in externalSetStackPageAndPointersForSuspendedContextOfProcess: except that I see that method called from a few places, so messing with the stack here is probably a bad idea. Another way might be for Process to get an additional instance variable 'suspendedPrimitiveFailCode' which again could be set in #transferTo: (or even more specifically only in #primitiveOwnedLockWaitAcquire). That is, #transferTo: might have... oldProc := objectMemory fetchPointer: ActiveProcessIndex ofObject: sched. objectMemory storePointer: SuspendedPrimitiveFailCodeIndex ofObject: oldProc withValue: primFailCode ... primFailCode := objectMemory fetchPointer: SuspendedPrimitiveFailCodeIndex ofObject: newProc. self externalSetStackPageAndPointersForSuspendedContextOfProcess: newProc. The additional advantage here might be that the saving and restoring of primFailCode is localised to one method. I'm hoping that change (plus similar in Cog) might be sufficient to facilitate behaviour like this... process 1 1. invokes slowPrimitiveResponse 2. dispatches to primitiveOwnedLockWaitAcquire 3. calls primitiveFailFor: PrimErrRetryAfterWaking 4. primitiveFail saved into Process object 5. process goes to sleep 6. later after process 1 woken 7. primitiveFail restored from Process object 8. returns to slowPrimitiveResponse 9. if PrimErrRetryAfterWaking 10. dispatch to primitiveOwnedLockWaitAcquire (goto step 2) Maybe there would need to be a step 9a to checkForInterrupts to avoid too tight a loop locking the image, but maybe this is already done somewhere in the suspend/resume process. So I'm now going to try coding the second way in the StackVM, and then look at how it might be done in Cog. All feedback appreciated. cheers -ben From btc at openinworld.com Fri Jun 3 07:08:04 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 3 07:08:27 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) In-Reply-To: References: Message-ID: On Fri, Jun 3, 2016 at 12:52 PM, Ben Coman wrote: > On Sun, May 22, 2016 at 2:15 AM, Eliot Miranda wrote: >> >> On Fri, May 20, 2016 at 7:52 PM, Ben Coman wrote: >>> >>> On Sat, May 21, 2016 at 4:36 AM, Cl?ment Bera wrote: >>> > >>> > On Fri, May 20, 2016 at 7:51 PM, Ben Coman wrote: >>> >> >>> >> On Fri, May 20, 2016 at 9:25 PM, Cl?ment Bera wrote: >>> >> > On Thu, May 19, 2016 at 3:42 PM, Ben Coman wrote: >>> >> There is a better way of solving this, and that is to use a pragma to identify a method that contains such a suspension point, and have the process terminate code look for the pragma and act accordingly. For example, the pragma could have a terminate action, sent to the receiver with the context as argument, e.g. >> >> Mutex>>critical: mutuallyExcludedBlock >> >> ^lock waitAcquire >> ifNil: mutuallyExcludedBlock >> ifNotNil:[ mutuallyExcludedBlock ensure: [lock release] ] >> >> (and here I'm guessing...) >> >> Mutex>> ensureMutexUnlockedInCritical: aContext >> "long-winded comment explaining the corner case, referencing tests, etc, etc and how it is solved on terminate buy this method" >> (aContext pc = aContext initialPC >> and: [self inTheCorner]) ifTrue: >> [self doTheRightThingTM] >> >> So on terminate the stack is walked (it is anyway) looking for unwinds or onTerminate: markers. Any onTerminate: markers are evaluated, and the corner case is solved. The pragma approach also allows for visibility in the code. > > I think this general < onTerminate: > pragma might be useful, but I'd > like to keep it in the back pocket for the moment while I explore > another idea for primitive retry after a process resumes. > > > I still have a concern that #primitiveOwnedLockWaitAcquire sleeps at > the bottom of the primitive, thus if the sleeping process is resumed, > it continues into the critical section without having gained the > mutex, which seems a bit fragile. Retrying > #primitiveOwnedLockWaitAcquire immediately after waking would > effectively have the process sleep at the top of the primitive, and > *not*proceed until it *really* holds the lock.. > > So I'm thinking out loud here to formulate my thoughts, and in case > there is some major impediment you can help me fail fast... > > One possibility is putting "self maybeRetryFailureAfterWaking" > in #slowPrimitiveResponse, similar to maybeRetryFailureDueToForwarding > and (guessing) maybeRetryFailureDueToLowMemory. The difficulty seems > to be that process's primFailCode doesn't hold across process > suspension(??). > > As an aside, it seems fragile that IIUC it is possible for > primFailCode to be set by one process, which if then suspended will > carry over to fail the new active process. Perhaps somewhere like > externalSetStackPageAndPointersForSuspendedContextOfProcess: should > zero primFailCode. > > Anyway... I thought one way to retain primFailCode across process > suspension might be to push it to the stack in #transferTo: and pop > primFailCode from the stack in > externalSetStackPageAndPointersForSuspendedContextOfProcess: > except that I see that method called from a few places, so messing > with the stack here is probably a bad idea. > > Another way might be for Process to get an additional instance > variable 'suspendedPrimitiveFailCode' which again could be set in > #transferTo: (or even more specifically only in > #primitiveOwnedLockWaitAcquire). That is, > > #transferTo: might have... > > oldProc := objectMemory fetchPointer: ActiveProcessIndex ofObject: sched. > objectMemory > storePointer: SuspendedPrimitiveFailCodeIndex > ofObject: oldProc > withValue: primFailCode > ... > primFailCode := objectMemory > fetchPointer: SuspendedPrimitiveFailCodeIndex > ofObject: newProc. > self externalSetStackPageAndPointersForSuspendedContextOfProcess: newProc. > > Whoops, for a start, that needed to be... objectMemory storeInteger: SuspendedPrimitiveFailCodeIndex ofObject: oldProc withValue: primFailCode. primFailCode := objectMemory fetchInteger: SuspendedPrimitiveFailCodeIndex ofObject: newProc. > The additional advantage here might be that the saving and restoring > of primFailCode is localised to one method. I'm hoping that change > (plus similar in Cog) might be sufficient to facilitate behaviour like > this... > > process 1 > 1. invokes slowPrimitiveResponse > 2. dispatches to primitiveOwnedLockWaitAcquire > 3. calls primitiveFailFor: PrimErrRetryAfterWaking > 4. primitiveFail saved into Process object > 5. process goes to sleep > > 6. later after process 1 woken > 7. primitiveFail restored from Process object > 8. returns to slowPrimitiveResponse > 9. if PrimErrRetryAfterWaking > 10. dispatch to primitiveOwnedLockWaitAcquire (goto step 2) > > Maybe there would need to be a step 9a to checkForInterrupts to avoid > too tight a loop locking the image, but maybe this is already done > somewhere in the suspend/resume process. > > So I'm now going to try coding the second way in the StackVM, and then > look at how it might be done in Cog. All feedback appreciated. > > cheers -ben From maxleske at gmail.com Fri Jun 3 07:56:03 2016 From: maxleske at gmail.com (Max Leske) Date: Fri Jun 3 07:56:07 2016 Subject: [Vm-dev] Context>>copyTo: doesn't update closure home Message-ID: <0F2C1119-ED0F-46E0-B6DF-1EDCA92ACE8D@gmail.com> Hi, Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack. My proposal is to implement Context>>postCopy closureOrNil ifNil: [ ^ self ]. closureOrNil outerContext: self and BlockClosure>>outerContext: aContext outerContext := aContext Thoughts? Cheers, Max From btc at openinworld.com Fri Jun 3 08:11:27 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 3 08:11:49 2016 Subject: [Vm-dev] Exploring the simulator - method args Message-ID: When I use menu item [set break selector...] and the debugger appears, what is the easiest way to view the arguments of the method? (btw, thanks for you last answer Tim.) cheers -ben From maxleske at gmail.com Fri Jun 3 09:02:30 2016 From: maxleske at gmail.com (Max Leske) Date: Fri Jun 3 09:02:33 2016 Subject: [Vm-dev] Context>>copyTo: doesn't update closure home Message-ID: I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder. Max > Hi, > > Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack. > > My proposal is to implement > > Context>>postCopy > closureOrNil ifNil: [ ^ self ]. > > closureOrNil outerContext: self > > and > > BlockClosure>>outerContext: aContext > outerContext := aContext > > > Thoughts? > > Cheers, > Max From bera.clement at gmail.com Fri Jun 3 09:20:10 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Fri Jun 3 09:20:32 2016 Subject: [Vm-dev] Exploring the simulator - method args In-Reply-To: References: Message-ID: Hi Ben, I would do [print ext head frame] from the simulator menu. It prints the head frame and you can see the arguments printed as string as well as their addresses. On Fri, Jun 3, 2016 at 10:11 AM, Ben Coman wrote: > > When I use menu item [set break selector...] and the debugger appears, > what is the easiest way to view the arguments of the method? > > > (btw, thanks for you last answer Tim.) > > cheers -ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/5f822d2d/attachment-0001.htm From bera.clement at gmail.com Fri Jun 3 10:30:39 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Fri Jun 3 10:31:01 2016 Subject: [Vm-dev] Context>>copyTo: doesn't update closure home In-Reply-To: References: Message-ID: The way I understand it the closure is shared between the original and the copied stack. If you change the closure outerContext to match the copied context, then non local returns / debugging won't work any more on the original stack. As you mentioned, updating all the closures referencing the context as their outer context is non trivial. I believe you can do it lazily (at least that's my conclusion from the sista experience where I need to do that if the outer context is deoptimized). The only cases where the outerContext is used are non local returns and debugging. If a non local return fails, it calls the #cannotReturn: call-back. You can change the code there to do the right think if the outer context is not correct (like setting the correct outer context and retrying the non local return). You can also change the BlockClosure code to check at each outerContext in-image read if the outerContext is valid or not. I think that's much better than updating ahead of time all the closure instances. Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContext'. On Fri, Jun 3, 2016 at 11:02 AM, Max Leske wrote: > > I see at least one problem: at the point where we make a copy of a > context, the closures that reference it are either in callees or not on the > stack at all. Therefore we would need to take note of all the closures we > meet on the way and update the outer contexts only if we find them on the > stack. That makes copying a whole lot harder. > > Max > > > Hi, > > > > Is anybody aware of a reason for why Context>>copyTo: should not update > the home of closures (which is currently the case)? This behaviour becomes > a problem when I want to simulate #stepThrough: on a copied stack, since > the home of a closure will never be found on the stack. > > > > My proposal is to implement > > > > Context>>postCopy > > closureOrNil ifNil: [ ^ self ]. > > > > closureOrNil outerContext: self > > > > and > > > > BlockClosure>>outerContext: aContext > > outerContext := aContext > > > > > > Thoughts? > > > > Cheers, > > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/fac10019/attachment.htm From btc at openinworld.com Fri Jun 3 10:33:00 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 3 10:33:24 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) In-Reply-To: References: Message-ID: On Fri, Jun 3, 2016 at 3:08 PM, Ben Coman wrote: > On Fri, Jun 3, 2016 at 12:52 PM, Ben Coman wrote: >> On Sun, May 22, 2016 at 2:15 AM, Eliot Miranda wrote: >>> >>> On Fri, May 20, 2016 at 7:52 PM, Ben Coman wrote: >>>> >>>> On Sat, May 21, 2016 at 4:36 AM, Cl?ment Bera wrote: >>>> > >>>> > On Fri, May 20, 2016 at 7:51 PM, Ben Coman wrote: >>>> >> >>>> >> On Fri, May 20, 2016 at 9:25 PM, Cl?ment Bera wrote: >>>> >> > On Thu, May 19, 2016 at 3:42 PM, Ben Coman wrote: >>>> >>> There is a better way of solving this, and that is to use a pragma to identify a method that contains such a suspension point, and have the process terminate code look for the pragma and act accordingly. For example, the pragma could have a terminate action, sent to the receiver with the context as argument, e.g. >>> >>> Mutex>>critical: mutuallyExcludedBlock >>> >>> ^lock waitAcquire >>> ifNil: mutuallyExcludedBlock >>> ifNotNil:[ mutuallyExcludedBlock ensure: [lock release] ] >>> >>> (and here I'm guessing...) >>> >>> Mutex>> ensureMutexUnlockedInCritical: aContext >>> "long-winded comment explaining the corner case, referencing tests, etc, etc and how it is solved on terminate buy this method" >>> (aContext pc = aContext initialPC >>> and: [self inTheCorner]) ifTrue: >>> [self doTheRightThingTM] >>> >>> So on terminate the stack is walked (it is anyway) looking for unwinds or onTerminate: markers. Any onTerminate: markers are evaluated, and the corner case is solved. The pragma approach also allows for visibility in the code. >> >> I think this general < onTerminate: > pragma might be useful, but I'd >> like to keep it in the back pocket for the moment while I explore >> another idea for primitive retry after a process resumes. >> >> >> I still have a concern that #primitiveOwnedLockWaitAcquire sleeps at >> the bottom of the primitive, thus if the sleeping process is resumed, >> it continues into the critical section without having gained the >> mutex, which seems a bit fragile. Retrying >> #primitiveOwnedLockWaitAcquire immediately after waking would >> effectively have the process sleep at the top of the primitive, and >> *not*proceed until it *really* holds the lock.. >> >> So I'm thinking out loud here to formulate my thoughts, and in case >> there is some major impediment you can help me fail fast... >> >> One possibility is putting "self maybeRetryFailureAfterWaking" >> in #slowPrimitiveResponse, similar to maybeRetryFailureDueToForwarding >> and (guessing) maybeRetryFailureDueToLowMemory. The difficulty seems >> to be that process's primFailCode doesn't hold across process >> suspension(??). >> >> As an aside, it seems fragile that IIUC it is possible for >> primFailCode to be set by one process, which if then suspended will >> carry over to fail the new active process. Perhaps somewhere like >> externalSetStackPageAndPointersForSuspendedContextOfProcess: should >> zero primFailCode. >> >> Anyway... I thought one way to retain primFailCode across process >> suspension might be to push it to the stack in #transferTo: and pop >> primFailCode from the stack in >> externalSetStackPageAndPointersForSuspendedContextOfProcess: >> except that I see that method called from a few places, so messing >> with the stack here is probably a bad idea. >> >> Another way might be for Process to get an additional instance >> variable 'suspendedPrimitiveFailCode' which again could be set in >> #transferTo: (or even more specifically only in >> #primitiveOwnedLockWaitAcquire). That is, >> >> #transferTo: might have... >> >> oldProc := objectMemory fetchPointer: ActiveProcessIndex ofObject: sched. >> objectMemory >> storePointer: SuspendedPrimitiveFailCodeIndex >> ofObject: oldProc >> withValue: primFailCode >> ... >> primFailCode := objectMemory >> fetchPointer: SuspendedPrimitiveFailCodeIndex >> ofObject: newProc. >> self externalSetStackPageAndPointersForSuspendedContextOfProcess: newProc. >> >> > > Whoops, for a start, that needed to be (*1*)... > objectMemory > storeInteger: SuspendedPrimitiveFailCodeIndex > ofObject: oldProc > withValue: primFailCode. > primFailCode := objectMemory > fetchInteger: SuspendedPrimitiveFailCodeIndex > ofObject: newProc. > > >> The additional advantage here might be that the saving and restoring >> of primFailCode is localised to one method. I'm hoping that change >> (plus similar in Cog) might be sufficient to facilitate behaviour like >> this... >> >> process 1 >> 1. invokes slowPrimitiveResponse >> 2. dispatches to primitiveOwnedLockWaitAcquire >> 3. calls primitiveFailFor: PrimErrRetryAfterWaking >> 4. primitiveFail saved into Process object >> 5. process goes to sleep >> >> 6. later after process 1 woken >> 7. primitiveFail restored from Process object >> 8. returns to slowPrimitiveResponse >> 9. if PrimErrRetryAfterWaking >> 10. dispatch to primitiveOwnedLockWaitAcquire (goto step 2) >> >> Maybe there would need to be a step 9a to checkForInterrupts to avoid >> too tight a loop locking the image, but maybe this is already done >> somewhere in the suspend/resume process. >> >> So I'm now going to try coding the second way in the StackVM, and then >> look at how it might be done in Cog. All feedback appreciated. >> >> cheers -ben My my experiment to better understand this is running the simulator thus... | cos | cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager). cos desiredNumStackPages: 8. cos openOn: 'ownedlock-reader.image'. cos openAsMorph; run and at the simulator's REPL input box running... o := OwnedLock new. o experiment1. ! where OwnedLock>>experiment1 is... | result | result := OrderedCollection new: 20. result myAdd: 0. [result myAdd: 11. [result myAdd: 12. self experimentSuccessAndSleep] on: Error do: [result myAdd: 13]. result myAdd: 14] forkAt: 72. [result myAdd: 21. [result myAdd: 22. self experimentFailAndWakeOther] on: Error do: [result myAdd: 23]. result myAdd: 24] forkAt: 71. result myAdd: 8. self experimentSuccessAndWakeOther. result myAdd: 9. ^result. The current VM produces a result of... OrderedCollection(0 11 12 21 22 13 14 24 8 9) but I'm hoping to get something like... OrderedCollection(0 11 12 21 22 14 23 24 8 9) Where the primitives are... primitiveExperimentSuccessAndSleep | ownedLock activeProc | ownedLock := self stackTop. activeProc := self activeProcess. self addLastLink: activeProc toList: ownedLock. self transferTo: self wakeHighestPriority. primitiveExperimentFailAndWakeOther | ownedLock waitingProcess | ownedLock := self stackTop. self primitiveFailFor: 42. (self isEmptyList: ownedLock) ifFalse: [waitingProcess := self removeFirstLinkOfList: ownedLock. self resume: waitingProcess preemptedYieldingIf: preemptionYields] primitiveExperimentSuccessAndWakeOther | ownedLock waitingProcess | ownedLock := self stackTop. "rcvr" (self isEmptyList: ownedLock) ifFalse: [waitingProcess := self removeFirstLinkOfList: ownedLock. self resume: waitingProcess preemptedYieldingIf: preemptionYields] From maxleske at gmail.com Fri Jun 3 11:04:20 2016 From: maxleske at gmail.com (Max Leske) Date: Fri Jun 3 11:04:25 2016 Subject: [Pharo-dev] [Vm-dev] Context>>copyTo: doesn't update closure home In-Reply-To: References: Message-ID: <0494682B-ED96-4DDE-92F1-56EB2A113F33@gmail.com> > On 03 Jun 2016, at 12:30, Cl?ment Bera wrote: > > The way I understand it the closure is shared between the original and the copied stack. If you change the closure outerContext to match the copied context, then non local returns / debugging won't work any more on the original stack. That?s true, I didn?t think of that. > > As you mentioned, updating all the closures referencing the context as their outer context is non trivial. I believe you can do it lazily (at least that's my conclusion from the sista experience where I need to do that if the outer context is deoptimized). The only cases where the outerContext is used are non local returns and debugging. If a non local return fails, it calls the #cannotReturn: call-back. You can change the code there to do the right think if the outer context is not correct (like setting the correct outer context and retrying the non local return). You can also change the BlockClosure code to check at each outerContext in-image read if the outerContext is valid or not. I think that's much better than updating ahead of time all the closure instances. I think I?ll have to do something like this, yes. > > Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContext?. No, I don?t want to risk anything. Although it probably wouldn?t hurt in most cases. Thanks Cl?ment. > > On Fri, Jun 3, 2016 at 11:02 AM, Max Leske > wrote: > > I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder. > > Max > > > Hi, > > > > Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack. > > > > My proposal is to implement > > > > Context>>postCopy > > closureOrNil ifNil: [ ^ self ]. > > > > closureOrNil outerContext: self > > > > and > > > > BlockClosure>>outerContext: aContext > > outerContext := aContext > > > > > > Thoughts? > > > > Cheers, > > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/f5352c03/attachment-0001.htm From btc at openinworld.com Fri Jun 3 12:30:44 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 3 12:31:09 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) In-Reply-To: References: Message-ID: On Fri, Jun 3, 2016 at 6:33 PM, Ben Coman wrote: > where OwnedLock>>experiment1 is... > | result | > result := OrderedCollection new: 20. > result myAdd: 0. btw, OrderedCollection>>myAdd: is direct copy of OrderderedCollection>>add: just so [set break selector...] can distinguish these from every send of add: in the image. > The current VM produces a result of... > OrderedCollection(0 11 12 21 22 13 14 24 8 9) > > but I'm hoping to get something like... > OrderedCollection(0 11 12 21 22 14 23 24 8 9) After loading my 'ownedlock-reader.image' with an unchaged VM, then adding these two lines to transferTo: > objectMemory > storeInteger: SuspendedPrimitiveFailCodeIndex > ofObject: oldProc > withValue: primFailCode. > primFailCode := objectMemory > fetchInteger: SuspendedPrimitiveFailCodeIndex > ofObject: newProc. then executing... OwnedLock new experiment1 ! I get an AssertionFailure in... Spur32BitMMLESimulator>>fetchPointer: fieldIndex ofObject: objOop self assert: (self isForwarded: objOop) not. self assert: (fieldIndex >= 0 and: [fieldIndex < (self numSlotsOfAny: objOop) or: [fieldIndex = 0 "forwarders and free objs"]]). ^super fetchPointer: fieldIndex ofObject: objOop where... objOop ==> 16r2D2490: a(n) OwnedLock 16r41A280 nil 16r41A280 nil 16r41A280 nil fieldIndex ==> 3 self numSlotsOfAny: objOop ==> 3 One thing I'm curious about is why the " < " and not a " <= " ? super fetchPointer: fieldIndex ofObject: objOop successfully returns... 16r41A280: a(n) UndefinedObject btw, here is the call stack... -16r106C [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock -16r104C BlockClosure>on:do: 16r2D29C8: a(n) BlockClosure -16r1024 [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock -16r1008 [] in BlockClosure>newProcess 16r2D27E8: a(n) BlockClosure and the ext head frame... -16r106C [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock -16r1064/3559: rcvr/clsr: 16r2D29C8 a BlockClosure -16r1068/3558:cllr ip/ctxt: 16rA3F922=10746146 -16r106C/3557: saved fp: -16r104C=-4172 -16r1070/3556: method: 16r81EF10 a CompiledMethod -16r1074/3555: flags: 16r1010001=16842753 numArgs: 0 hasContext: true isBlock: true -16r1078/3554: context: 16r2D29F8=2959864 -16r107C/3553: receiver: 16r2D2490 an OwnedLock -16r1080/3552: temp/stck: 16r2D24A8 an OrderedCollection -16r1084/3551: temp/stck: 16r2D2490 an OwnedLock and the int head frame... -16r108C OwnedLock(Process)>suspend 16r2D2490: a(n) OwnedLock -16r1084/3551: rcvr/clsr: 16r2D2490 an OwnedLock -16r1088/3550:cllr ip/ctxt: 16r81EFBB=8515515 -16r108C/3549: saved fp: -16r106C=-4204 -16r1090/3548: method: 16r10DF5B0 a CompiledMethod -16r1094/3547: flags: 16r1=1 numArgs: 0 hasContext: false isBlock: false -16r1098/3546: context: 16r41A280=4301440 -16r109C/3545: receiver: 16r2D2490 an OwnedLock -16r10A0/3544: temp/stck: 16r41A280 nil What is the difference between ext and int head frames? One thing I find curious here is "OwnedLock(Process)>suspend". Does this indicate that #suspend was sent to an OwnedLock and looked up the hierarchy to find the method in Process? But OwnedLock doesn't inherit from Process, it inherits from LinkedList. cheers -ben From lists at fniephaus.com Fri Jun 3 12:59:49 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Fri Jun 3 13:00:02 2016 Subject: [Vm-dev] Re: [squeak-dev] Re: 2 raisedTo: 100000000` crashes VM In-Reply-To: <913182FE-1E10-47AD-9C24-6C47EB0C70D2@freudenbergs.de> References: <7900E39A-3F6D-48A4-8B48-7584056009F4@freudenbergs.de> <6625BEB1-1314-4464-8F44-58796517E55A@freudenbergs.de> <913182FE-1E10-47AD-9C24-6C47EB0C70D2@freudenbergs.de> Message-ID: On my machine: SqueakJS: 2832ms RSqueak: 2523ms (*) (*) using fallback Smalltalk code for large integer; https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/rsqueak/bundle/RSqueak.zip Maybe the JITs realize that the result of "2 raisedTo: ...." is not being used and omit the calculation? -- On Thu, Jun 2, 2016 at 12:24 PM Bert Freudenberg wrote: > On 02.06.2016, at 03:19, Eliot Miranda wrote: > > OK, tis fixed in VMMaker.oscog-eem.1879. > > > > Reporting - 774 tallies, 6,836 msec. > > Nice! > > Is this finally a benchmark where SqueakJS can beat other VMs? > > [10 timesRepeat: [(2 raisedTo: 100000000) basicSize]] timeToRun > > Interp: 18042 ms > Cog: 7965 ms > Spur: ? > SqueakJS: 2821 ms (*) > > :D > > - Bert - > > (*) > http://bertfreudenberg.github.io/SqueakJS/run/#url=http://freudenbergs.de/bert/squeakjs&files=[Squeak4.5-13680.image,Squeak4.5-13680.changes,SqueakV41.sources] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/a8a195ff/attachment.htm From timfelgentreff at gmail.com Fri Jun 3 12:38:35 2016 From: timfelgentreff at gmail.com (timfelgentreff) Date: Fri Jun 3 13:16:32 2016 Subject: [Vm-dev] Re: Need a good comment for SystemTracerSpur (was: Tracing a Spur Image from Smalltalk) In-Reply-To: <20160602041249.GA80138@shell.msen.com> References: <1456502344939-4881224.post@n4.nabble.com> <20160602041249.GA80138@shell.msen.com> Message-ID: <1464957515946-4899020.post@n4.nabble.com> Hi David, sorry for dropping this and not having time to put more work into it. You're right, this will get confusing. Right now the Spur format tracer can trace Spur format images to Spur. Those will load on a Spur VM. I have (locally, or maybe I also pushed it) code to also trace V3 images to Spur, and those won't load on Spur VMs, but they do load on RSqueak, which was one of my use cases. Marcel Taeumel and I were discussing where to go with this and that it might be useful to have support through the SystemTracing package for cross-tracing images between different formats. Imagine that you are working on a 64-bit Sista-enabled VM on your x86 machine and you want to move to (maybe) and older 32-bit ARM system without a Sista VM or to SqueakJS which doesn't support Spur (yet): We'd like the "Save As.." dialog to offer the choice of word size and format as well, and use the SystemTracing package to convert between the formats. This might also be useful to convert the Etoys images into the newer format without losing the in-image content and then using RSqueak or something to do the necessary adjustments to get it to load on the Spur VMs. I will get back to this soon, I hope, but it will be a couple more weeks before I have time again. Is that alright to leave it be until then? Best, Tim David T. Lewis wrote > Hi Tim, > > The latest version of your system tracer for Spur (on squeaksource) is > in SystemTracing-tfel.41. The SystemTracerSpur class would benefit from > a class comment to explain with it can (and cannot) do. Would you mind > adding a comment to clarify? > > My understanding is that SystemTracerSpur traces a 32-bit V3 image to > 32-bit Spur, although it is not clear if the traced image can then be > run under a Spur VM (I suspect not, but I am not sure). We also have > 64-bit Spur images available, and these will require tracing support > either with SystemTracer, or using the VMMaker tracing that Eliot has > already provided. So I think that this might get confusing soon, and > a class comment will help to explain it. > > Thanks! > > Dave > > On Fri, Feb 26, 2016 at 07:59:04AM -0800, timfelgentreff wrote: >> >> I've updated the SystemTracer package to trace a Spur-format image. >> >> This works as far as I can tell, producing a header that looks just like >> the >> header produced by the VM and the objects written also look good. I can >> also >> open the image in RSqueak, but not on Spur. It crashes immediately and >> produces a Smalltalk backtrace that looks like it never manages to return >> from the image-saving method (but the names in the Stack-trace all look >> ok, >> leading me to believe that enough objects got written ok to figure out >> classes, method names, find the right Process to run and so forth). >> >> Curiously, the old SystemTracer2 class that writes Cog-format images also >> produces images that cannot be opened by Cog VMs, only Interpreter VMs. >> So I >> assume there are other assumptions that maybe the JIT makes when starting >> up. >> >> So my question is, what assumptions could there be, and where could I >> start >> looking. >> >> Cheers, >> Tim >> >> (If you're wondering why I'm using the Smalltalk-level tracing at all - >> in >> our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code >> fast >> enough that we no longer have to rely on C code from plugins or optional >> primitives, we're trying to see how far we can push this, and e.g. write >> the >> image from within itself, too.) >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224.html >> Sent from the Squeak VM mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224p4899020.html Sent from the Squeak VM mailing list archive at Nabble.com. From estebanlm at gmail.com Fri Jun 3 13:25:24 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Fri Jun 3 13:25:26 2016 Subject: [Vm-dev] Migration to github status? Message-ID: <7D19D997-3EBD-4A60-A89C-0F548BB7A6D4@gmail.com> Hi, Last week (with help of Clement) I put online the 64bits image generation for Pharo. Our CI now is producing regularly 64bits for both: - Pharo 5: https://ci.inria.fr/pharo/view/5.0/job/Pharo-5.0-Update-Step-3.1-64bits/ - Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.1-64bits Now? I would like to start testing it, and for that I need to build also PharoVM 64bits? I do not wan to reproduce all the work already done for running 64bits in current so I?m urging you to complete the migration, so I can start to merge my changes into the master, instead the opposite :) cheers, Esteban -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/4182da4e/attachment.htm From btc at openinworld.com Fri Jun 3 13:45:17 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 3 13:45:39 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: Is their some method I can call in the Image to cause the simulator to break into a debugger? I want to do this right before the end block bracket, so I can trace the termination of a forked block without needing to trace over the block's statements. cheers -ben On Tue, May 31, 2016 at 1:27 AM, tim Rowledge wrote: > > >> On 30-05-2016, at 10:09 AM, Ben Coman wrote: >> >> >> On Mon, May 30, 2016 at 11:35 PM, Cl?ment Bera wrote: >>> >>> I did a post out of this thread: >>> >>> https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/ >> >> Nice article Clement, thanks. >> One thing though, I can't think what the "dis" means in genAndDis: ? > > Ooh, ooh - I can answer that one! "generate and disassemble? as in generate the code and then disassemble it and display the nicely formatted string result so you can see where it all went horribly wrong. > > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > The less time planning, the more time programming. > > From lewis at mail.msen.com Fri Jun 3 15:14:55 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 3 15:14:57 2016 Subject: [Vm-dev] Re: Need a good comment for SystemTracerSpur (was: Tracing a Spur Image from Smalltalk) In-Reply-To: <1464957515946-4899020.post@n4.nabble.com> References: <1456502344939-4881224.post@n4.nabble.com> <20160602041249.GA80138@shell.msen.com> <1464957515946-4899020.post@n4.nabble.com> Message-ID: <26571.136.1.1.107.1464966895.squirrel@webmail.msen.com> Tim, Sure, of course it is ok to update it a few weeks from now. Thanks for the follow up! Dave > > Hi David, > > sorry for dropping this and not having time to put more work into it. > You're > right, this will get confusing. > > Right now the Spur format tracer can trace Spur format images to Spur. > Those > will load on a Spur VM. I have (locally, or maybe I also pushed it) code > to > also trace V3 images to Spur, and those won't load on Spur VMs, but they > do > load on RSqueak, which was one of my use cases. > > Marcel Taeumel and I were discussing where to go with this and that it > might > be useful to have support through the SystemTracing package for > cross-tracing images between different formats. Imagine that you are > working > on a 64-bit Sista-enabled VM on your x86 machine and you want to move to > (maybe) and older 32-bit ARM system without a Sista VM or to SqueakJS > which > doesn't support Spur (yet): We'd like the "Save As.." dialog to offer the > choice of word size and format as well, and use the SystemTracing package > to > convert between the formats. This might also be useful to convert the > Etoys > images into the newer format without losing the in-image content and then > using RSqueak or something to do the necessary adjustments to get it to > load > on the Spur VMs. > > I will get back to this soon, I hope, but it will be a couple more weeks > before I have time again. Is that alright to leave it be until then? > > Best, > Tim > > > David T. Lewis wrote >> Hi Tim, >> >> The latest version of your system tracer for Spur (on squeaksource) is >> in SystemTracing-tfel.41. The SystemTracerSpur class would benefit from >> a class comment to explain with it can (and cannot) do. Would you mind >> adding a comment to clarify? >> >> My understanding is that SystemTracerSpur traces a 32-bit V3 image to >> 32-bit Spur, although it is not clear if the traced image can then be >> run under a Spur VM (I suspect not, but I am not sure). We also have >> 64-bit Spur images available, and these will require tracing support >> either with SystemTracer, or using the VMMaker tracing that Eliot has >> already provided. So I think that this might get confusing soon, and >> a class comment will help to explain it. >> >> Thanks! >> >> Dave >> >> On Fri, Feb 26, 2016 at 07:59:04AM -0800, timfelgentreff wrote: >>> >>> I've updated the SystemTracer package to trace a Spur-format image. >>> >>> This works as far as I can tell, producing a header that looks just >>> like >>> the >>> header produced by the VM and the objects written also look good. I can >>> also >>> open the image in RSqueak, but not on Spur. It crashes immediately and >>> produces a Smalltalk backtrace that looks like it never manages to >>> return >>> from the image-saving method (but the names in the Stack-trace all look >>> ok, >>> leading me to believe that enough objects got written ok to figure out >>> classes, method names, find the right Process to run and so forth). >>> >>> Curiously, the old SystemTracer2 class that writes Cog-format images >>> also >>> produces images that cannot be opened by Cog VMs, only Interpreter VMs. >>> So I >>> assume there are other assumptions that maybe the JIT makes when >>> starting >>> up. >>> >>> So my question is, what assumptions could there be, and where could I >>> start >>> looking. >>> >>> Cheers, >>> Tim >>> >>> (If you're wondering why I'm using the Smalltalk-level tracing at all - >>> in >>> our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code >>> fast >>> enough that we no longer have to rely on C code from plugins or >>> optional >>> primitives, we're trying to see how far we can push this, and e.g. >>> write >>> the >>> image from within itself, too.) >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224.html >>> Sent from the Squeak VM mailing list archive at Nabble.com. > > > > > > -- > View this message in context: > http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224p4899020.html > Sent from the Squeak VM mailing list archive at Nabble.com. > From bera.clement at gmail.com Fri Jun 3 15:34:18 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Fri Jun 3 15:34:40 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) In-Reply-To: References: Message-ID: Hi Ben, On Fri, Jun 3, 2016 at 2:30 PM, Ben Coman wrote: > > On Fri, Jun 3, 2016 at 6:33 PM, Ben Coman wrote: > > > where OwnedLock>>experiment1 is... > > | result | > > result := OrderedCollection new: 20. > > result myAdd: 0. > > btw, OrderedCollection>>myAdd: > is direct copy of OrderderedCollection>>add: > just so [set break selector...] can distinguish these from every send > of add: in the image. > > > > The current VM produces a result of... > > OrderedCollection(0 11 12 21 22 13 14 24 8 9) > > > > but I'm hoping to get something like... > > OrderedCollection(0 11 12 21 22 14 23 24 8 9) > > > After loading my 'ownedlock-reader.image' with an unchaged VM, > then adding these two lines to transferTo: > > > objectMemory > > storeInteger: SuspendedPrimitiveFailCodeIndex > > ofObject: oldProc > > withValue: primFailCode. > > primFailCode := objectMemory > > fetchInteger: SuspendedPrimitiveFailCodeIndex > > ofObject: newProc. > > then executing... OwnedLock new experiment1 ! > I get an AssertionFailure in... > > Spur32BitMMLESimulator>>fetchPointer: fieldIndex ofObject: objOop > self assert: (self isForwarded: objOop) not. > self assert: (fieldIndex >= 0 and: [fieldIndex < (self > numSlotsOfAny: objOop) > or: [fieldIndex = 0 "forwarders and free objs"]]). > ^super fetchPointer: fieldIndex ofObject: objOop > > where... > objOop ==> > 16r2D2490: a(n) OwnedLock > 16r41A280 nil 16r41A280 nil 16r41A280 nil > > fieldIndex ==> 3 > > self numSlotsOfAny: objOop ==> 3 > > > One thing I'm curious about is why the " < " and not a " <= " ? > super fetchPointer: fieldIndex ofObject: objOop > successfully returns... 16r41A280: a(n) UndefinedObject > Can you print the class definition of OwnedLock ? Maybe I am wrong but it looks like it's because it's 0-based so the fieldIndex can be between 0 and 2 if numSlots is 3. That would imply a bytecode compiler bug if that object is fixed-sized. When you try: objectMemory storePointer: 3 ofObject: objOop withValue: objOop And then print objOop with printOop, is the 3rd field edited ? If not, what if you put 2 as 1st argument ? > > btw, here is the call stack... > -16r106C [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock > -16r104C BlockClosure>on:do: 16r2D29C8: a(n) BlockClosure > -16r1024 [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock > -16r1008 [] in BlockClosure>newProcess 16r2D27E8: a(n) BlockClosure > > and the ext head frame... > -16r106C [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock > -16r1064/3559: rcvr/clsr: 16r2D29C8 a BlockClosure > -16r1068/3558:cllr ip/ctxt: 16rA3F922=10746146 > -16r106C/3557: saved fp: -16r104C=-4172 > -16r1070/3556: method: 16r81EF10 a CompiledMethod > -16r1074/3555: flags: 16r1010001=16842753 numArgs: 0 > hasContext: true isBlock: true > -16r1078/3554: context: 16r2D29F8=2959864 > -16r107C/3553: receiver: 16r2D2490 an OwnedLock > -16r1080/3552: temp/stck: 16r2D24A8 an OrderedCollection > -16r1084/3551: temp/stck: 16r2D2490 an OwnedLock > > and the int head frame... > -16r108C OwnedLock(Process)>suspend 16r2D2490: a(n) OwnedLock > -16r1084/3551: rcvr/clsr: 16r2D2490 an OwnedLock > -16r1088/3550:cllr ip/ctxt: 16r81EFBB=8515515 > -16r108C/3549: saved fp: -16r106C=-4204 > -16r1090/3548: method: 16r10DF5B0 a CompiledMethod > -16r1094/3547: flags: 16r1=1 numArgs: 0 hasContext: > false isBlock: false > -16r1098/3546: context: 16r41A280=4301440 > -16r109C/3545: receiver: 16r2D2490 an OwnedLock > -16r10A0/3544: temp/stck: 16r41A280 nil > > > What is the difference between ext and int head frames? > Err... That's an interpreter optimization. I am not sure I remember correctly. I think internal stack frame may have an incorrect pc / stack pointer / frame pointer as the value may be in the interpreter and not on stack. External stack frame have always the correct value. Basically if the frame is machine code frame, it is always external. If the frame is an interpreted frame, it is internal if it's the active stack frame. Or something like that. Eliot can you explain again ? I'm pretty sure I am confused. > One thing I find curious here is "OwnedLock(Process)>suspend". Does > this indicate that #suspend was sent to an OwnedLock and looked up the > hierarchy to find the method in Process? > But OwnedLock doesn't inherit from Process, it inherits from LinkedList. > > Well then the external stack frame was correct and not the internal one. I always look at machine code frame and they are always external, so I forgot :-(. > cheers -ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/971225ec/attachment.htm From bera.clement at gmail.com Fri Jun 3 15:50:23 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Fri Jun 3 15:50:44 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: Well you can call a method with a specific selector name and use the [break selector] feature in the simulator. Alternatively you call a specific primitive and put a halt in it in the simulator. On Fri, Jun 3, 2016 at 3:45 PM, Ben Coman wrote: > > Is their some method I can call in the Image to cause the simulator to > break into a debugger? I want to do this right before the end block > bracket, so I can trace the termination of a forked block without > needing to trace over the block's statements. > > cheers -ben > > On Tue, May 31, 2016 at 1:27 AM, tim Rowledge wrote: > > > > > >> On 30-05-2016, at 10:09 AM, Ben Coman wrote: > >> > >> > >> On Mon, May 30, 2016 at 11:35 PM, Cl?ment Bera > wrote: > >>> > >>> I did a post out of this thread: > >>> > >>> https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/ > >> > >> Nice article Clement, thanks. > >> One thing though, I can't think what the "dis" means in genAndDis: ? > > > > Ooh, ooh - I can answer that one! "generate and disassemble? as in > generate the code and then disassemble it and display the nicely formatted > string result so you can see where it all went horribly wrong. > > > > > > tim > > -- > > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > > The less time planning, the more time programming. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160603/06148601/attachment.htm From btc at openinworld.com Sat Jun 4 02:10:10 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 4 02:10:34 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) In-Reply-To: References: Message-ID: On Fri, Jun 3, 2016 at 8:30 PM, Ben Coman wrote: > On Fri, Jun 3, 2016 at 6:33 PM, Ben Coman wrote: > >> where OwnedLock>>experiment1 is... >> | result | >> result := OrderedCollection new: 20. >> result myAdd: 0. > > btw, OrderedCollection>>myAdd: > is direct copy of OrderderedCollection>>add: > just so [set break selector...] can distinguish these from every send > of add: in the image. > > >> The current VM produces a result of... >> OrderedCollection(0 11 12 21 22 13 14 24 8 9) >> >> but I'm hoping to get something like... >> OrderedCollection(0 11 12 21 22 14 23 24 8 9) > > > After loading my 'ownedlock-reader.image' with an unchanged VM, > then adding these two lines to transferTo: > >> objectMemory >> storeInteger: SuspendedPrimitiveFailCodeIndex >> ofObject: oldProc >> withValue: primFailCode. >> primFailCode := objectMemory >> fetchInteger: SuspendedPrimitiveFailCodeIndex >> ofObject: newProc. > > then executing... OwnedLock new experiment1 ! > I get an AssertionFailure in... > > Spur32BitMMLESimulator>>fetchPointer: fieldIndex ofObject: objOop > self assert: (self isForwarded: objOop) not. > self assert: (fieldIndex >= 0 and: [fieldIndex < (self > numSlotsOfAny: objOop) > or: [fieldIndex = 0 "forwarders and free objs"]]). > ^super fetchPointer: fieldIndex ofObject: objOop > > where... > objOop ==> > 16r2D2490: a(n) OwnedLock > 16r41A280 nil 16r41A280 nil 16r41A280 nil > > fieldIndex ==> 3 > > self numSlotsOfAny: objOop ==> 3 > > > One thing I'm curious about is why the " < " and not a " <= " ? > super fetchPointer: fieldIndex ofObject: objOop > successfully returns... 16r41A280: a(n) UndefinedObject > > > btw, here is the call stack... > -16r106C [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock > -16r104C BlockClosure>on:do: 16r2D29C8: a(n) BlockClosure > -16r1024 [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock > -16r1008 [] in BlockClosure>newProcess 16r2D27E8: a(n) BlockClosure btw2, I am guessing that the lack of a Compiler in the call stack means we are within one of the forked blocks. > > and the ext head frame... > -16r106C [] in OwnedLock>experiment1 16r2D2490: a(n) OwnedLock > -16r1064/3559: rcvr/clsr: 16r2D29C8 a BlockClosure > -16r1068/3558:cllr ip/ctxt: 16rA3F922=10746146 > -16r106C/3557: saved fp: -16r104C=-4172 > -16r1070/3556: method: 16r81EF10 a CompiledMethod > -16r1074/3555: flags: 16r1010001=16842753 numArgs: 0 > hasContext: true isBlock: true > -16r1078/3554: context: 16r2D29F8=2959864 > -16r107C/3553: receiver: 16r2D2490 an OwnedLock > -16r1080/3552: temp/stck: 16r2D24A8 an OrderedCollection > -16r1084/3551: temp/stck: 16r2D2490 an OwnedLock > > and the int head frame... > -16r108C OwnedLock(Process)>suspend 16r2D2490: a(n) OwnedLock > -16r1084/3551: rcvr/clsr: 16r2D2490 an OwnedLock > -16r1088/3550:cllr ip/ctxt: 16r81EFBB=8515515 > -16r108C/3549: saved fp: -16r106C=-4204 > -16r1090/3548: method: 16r10DF5B0 a CompiledMethod > -16r1094/3547: flags: 16r1=1 numArgs: 0 hasContext: > false isBlock: false > -16r1098/3546: context: 16r41A280=4301440 > -16r109C/3545: receiver: 16r2D2490 an OwnedLock > -16r10A0/3544: temp/stck: 16r41A280 nil > > > What is the difference between ext and int head frames? > > One thing I find curious here is "OwnedLock(Process)>suspend". Does > this indicate that #suspend was sent to an OwnedLock and looked up the > hierarchy to find the method in Process? > But OwnedLock doesn't inherit from Process, it inherits from LinkedList. > > cheers -ben TLDR; Reporting all the following helped me focus on the details, but most turned out irrelevant. I've left it for background info, but you may as well skip down to my Ahahhh.. moment. And the question I'm stuck on is right at the bottom an fairly isolated from everything else. At the assertion failure, if I [print oop...] the Array inside the Ordered Collection it produces... 16r285008: a(n) Array 16r1 =0 (16r0) 16r17 =11 (16rB) 16r19 =12 (16rC) 16r2B =21 (16r15) 16r2D =22 (16r16) 16r1D =14 (16rE) 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil which is somewhat positive, showing that now experimentSuccessAndSleep did not error(13) i.e. OrderedCollection(0 11 12 21 22 14) Also, it seems it got to the end of the first forked block, and considering the later bytecode trace, maybe the problem is with terminating that forked block. Is line "145 7D returnTopFromBlock (2506913)" below where this starts to happen? With [break on selector...] > myAdd: I can successfully five times. Turning on [print sends] and [print bytecode each bytecode] then proceding the sixth time produces... 2506895 myAdd: 21 70 pushReceiverBytecode (2506897) 22 10 pushTemporaryVariableBytecode (2506898) 23 E0 sendLiteralSelector1ArgBytecode (2506899) OrderedCollection>addLast: 2506898 addLast: 25 00 pushReceiverVariableBytecode (2506900) 26 C2 bytecodePrimSize (2506901) 27 02 pushReceiverVariableBytecode (2506902) 28 B6 bytecodePrimEqual (2506903) 33 00 pushReceiverVariableBytecode (2506904) 34 02 pushReceiverVariableBytecode (2506905) 35 76 pushConstantOneBytecode (2506906) 36 B0 bytecodePrimAdd (2506907) 37 81 extendedStoreBytecode (2506908) 39 10 pushTemporaryVariableBytecode (2506909) 40 C1 bytecodePrimAtPut (2506910) 41 7C returnTopFromMethod (2506911) 24 7C returnTopFromMethod (2506912) 145 7D returnTopFromBlock (2506913) "localReturnValue := self internalStackTop." "self commonCallerReturn" " self setMethod: (self frameMethod: localFP)." " self fetchNextBytecode" " self internalStackTopPut: localReturnValue (=14)" "I am unable to [print call stack] at this point ==> invalid frame pointer Is this normal at this point?" 55 87 popStackBytecode (2506914) "Still unable to [print call stack] at this point ==> invalid frame pointer 56 45 pushLiteralVariableBytecode (2506915) 57 D4 sendLiteralSelector0ArgsBytecode (2506916) "rcvr = ProcessorScheduler:" ProcessorScheduler>activeProcess 2506915 activeProcess 21 01 pushReceiverVariableBytecode (2506917) --> Process 22 D0 sendLiteralSelector0ArgsBytecode (2506918) --> effectiveProcess Process>effectiveProcess 2506917 effectiveProcess 21 05 pushReceiverVariableBytecode (2506919) 22 88 duplicateTopBytecode (2506920) 23 73 pushConstantNilBytecode (2506921) 24 C6 bytecodePrimIdentical (2506922) 26 87 popStackBytecode (2506923) 27 70 pushReceiverBytecode (2506924) 28 7C returnTopFromMethod (2506925) 23 7C returnTopFromMethod (2506926) 58 D3 sendLiteralSelector0ArgsBytecode (2506927) --> #suspend "messageSelector = #suspend" "rcvr = 16r24B748: a(n) Process 16r41A280 nil 16r41A280 nil 16r91 =72 (16r48) "priority" 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r1 =0 (16r0) "suspendedPrimitiveFailCode, newly introduced" Process>suspend 2506926 suspend "commonSendOrdinary" " internalExecuteNewMethod" " slowPrimitiveResponse" " dispatchFunctionPointer: " " primitiveSuspend" " process := self stackTop. " process = self activeProcess ifTrue: " [self pop: 1 thenPush: objectMemory nilObject. " ^self transferTo: self wakeHighestPriority]. In transferTo:, newProc is.... 16r24B9B8: a(n) Process 16r41A280 nil 16r24BAD8 a MethodContext 16r8F =71 (16r47) 16r459620 a LinkedList 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r41A280 nil 16r55 =42 (16r2A) Ahahhhh.... priority 71, that is the following forked process... [result myAdd: 21. [result myAdd: 22. self experimentFailAndWakeOther] on: Error do: [result myAdd: 23]. result myAdd: 24] forkAt: 71. and its suspendedPrimitiveFailCode ==> 42 as set by primitiveExperimentFailAndWakeOther And indeed, tracing through transferTo:, primFailCode := 42. So in the simulated image had executed experimentFailAndWakeOther at priority 71 which woke up experimentSuccessAndSleep at priority 72, transfering execution to "myAdd: 14", and when that block finished, execution transferred back experimentFailAndWakeOther with its saved primFailCode. Now #slowPrimitiveResponse returned to internalExecuteNewMethod with succeeded := false "correct per experiment" and dropped through #internalExecuteNewMethod to #internalActivateNewMethod. which does... methodHeader := objectMemory methodHeaderOf: newMethod. where newMethod is... 16r10DF5B0: a(n) CompiledMethod nbytes 48 16rA0009 =327684 (16r50004) 16r5B0278 #remove:ifAbsent: 16r5C8700 #ifNil: 16r14B5030 an AdditionalMethodState 16r9D2A78 a ClassBinding #Process -> 16r0183C860 and not the expected #experimentFailAndWakeOther So /newMethod/ also needed to be saved across the context switch. In the simulated image I added another ivar for this to Process for this, and these lines into #transferTo: objectMemory storePointer: SuspendedNewMethodIndex ofObject: oldProc withValue: newMethod. newMethod := objectMemory fetchPointer: SuspendedNewMethodIndex ofObject: newProc. Now an assert failed in #checkForAndFollowForwardedPrimitiveState self assert: (self saneFunctionPointerForFailureOfPrimIndex: primIndex)]. but we have correctly restored newMethod = 16rC0DA18: a(n) CompiledMethod nbytes 34 16r20009 =65540 (16r10004) 16r1790AB0 #iAmMethodExperimentFailAndWakeOther 16r5C6630 #primitiveFail 16r147A3B8 an AdditionalMethodState 16r17D1090 a ClassBinding #OwnedLock -> 16r01116370 and correctly restored primIndex = 561. but #saneFunctionPointerForFailureOfPrimIndex: uses a a stale primitiveFunctionPointer which needs to be saved across the context switch. --------------- Now I am a little confused about primitiveFunctionPointer. By name I would expect a pointer and to use #storePointer:toObject:withValue , but actually I find... primitiveFunctionPointer ==> #primitiveSuspend (which btw is stale) self functionPointerFor: primIndex inClass: objectMemory nilObject ==> #primitiveExperimentFailAndWakeOther (which is correct) So what store method should I use for primitiveFunctionPointer ? cheers -ben From btc at openinworld.com Sat Jun 4 02:17:50 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 4 02:18:13 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: > On Fri, Jun 3, 2016 at 3:45 PM, Ben Coman wrote: >> >> >> Is their some method I can call in the Image to cause the simulator to >> break into a debugger? I want to do this right before the end block >> bracket, so I can trace the termination of a forked block without >> needing to trace over the block's statements. >> >> cheers -ben On Fri, Jun 3, 2016 at 11:50 PM, Cl?ment Bera wrote: > > Well you can call a method with a specific selector name and use the [break selector] feature in the simulator. Alternatively you call a specific primitive and put a halt in it in the simulator. cool, thanks. cheers -ben From btc at openinworld.com Sat Jun 4 04:07:45 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 4 04:08:07 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy) In-Reply-To: References: Message-ID: On Sat, Jun 4, 2016 at 10:10 AM, Ben Coman wrote: > > Now an assert failed in #checkForAndFollowForwardedPrimitiveState > self assert: (self saneFunctionPointerForFailureOfPrimIndex: primIndex)]. > > but we have correctly restored newMethod = > 16rC0DA18: a(n) CompiledMethod nbytes 34 > 16r20009 =65540 (16r10004) > 16r1790AB0 #iAmMethodExperimentFailAndWakeOther > 16r5C6630 #primitiveFail 16r147A3B8 an AdditionalMethodState > 16r17D1090 a ClassBinding #OwnedLock -> 16r01116370 > > and correctly restored primIndex = 561. > but #saneFunctionPointerForFailureOfPrimIndex: > uses a a stale primitiveFunctionPointer which needs to be saved across > the context switch. > > --------------- > Now I am a little confused about primitiveFunctionPointer. By name I > would expect a pointer and to use #storePointer:toObject:withValue , > but actually I find... > primitiveFunctionPointer > ==> #primitiveSuspend (which btw is stale) > self functionPointerFor: primIndex inClass: objectMemory nilObject > ==> #primitiveExperimentFailAndWakeOther (which is correct) > > So what store method should I use for primitiveFunctionPointer ? > > cheers -ben As a quick check, under the assumption that a newly opened image doesn't have any forwarders for a primitive to fail on, and that the "reader" image probably hasn't done any becomes, I just commented the call to #maybeRetryFailureDueToForwarding out of #slowPrimitiveResponse. Thus running... OwnedLock new experiment1. ! produces... OrderedCollection(0 11 12 21 22 14 23 24 8 9) which is exactly what I was hoping for. So having *mostly* produced a technical proof of concept (for StackVM), the meta-question is whether a change like this worth pursuing? Apart from my own need for the OwnedLock primitiveWaitAcquire, I have cluelessly wondered if there might be any benefit for multi-threading or callback patterns, now or in the future. Also, are there any obvious/known difficulties to be expected doing this with JIT side? cheers -ben P.S. I could never imagine getting so far in a few days without the Simulator. It is **really** cool to be bale to load an Image on an unmodified VM, then switch in some new VM code while the Image is running. From btc at openinworld.com Sat Jun 4 16:46:48 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 4 16:47:13 2016 Subject: [Vm-dev] ./buildspurtrunkvmmakerimage.sh error ? Message-ID: Can someone check if ./buildspurtrunkvmmakerimage.sh runs okay. I'm think it ran okay a week ago, but just now in trunk50.image it produces a Syntax Error... SystemWindow class Message Message patter expected -> 'growing' stamp: 'ul' 6/2/2016 14:37' I'm on Debian Jessie 32-bit. cheers -ben From leves at caesar.elte.hu Sun Jun 5 01:30:00 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sun Jun 5 01:30:04 2016 Subject: [Vm-dev] DSAPrims broken on 64-bit VM (3684) In-Reply-To: References: Message-ID: I finally checked what actually had changed in the plugin code and I found that it was unrelated to inlining. The only change was the declaration of two constants as U instead of ULL[1]. So, I decided to add the correct type declarations and recompiled the plugin, which seems to work for me; the image-side tests pass. Unfortunately, I don't have access to the Cryptography repository, so I uploaded the changes to my place[2]. Levente [1] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/branches/Cog/src/plugins/DSAPrims/DSAPrims.c?r1=3672&r2=3689 [2] http://leves.web.elte.hu/squeak/CryptographyPlugins-ul.11.mcz From btc at openinworld.com Sun Jun 5 03:10:25 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 5 03:10:48 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-tfel.1863.mcz In-Reply-To: <573efac3.a6ec420a.21595.5cffSMTPIN_ADDED_MISSING@mx.google.com> References: <573efac3.a6ec420a.21595.5cffSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hi Tim, I just ran ./buildspurtrunkvmmakerimage.sh(**1) and I'm bumping into a halt introduced in 1863... Is it required :) ? I see the other halt was previously uncommented. Is that the usual state? btw, Are you able to define a general sort of problem that you find halts useful at this location? **1 Excluding ./updatespurimage.sh which had a problem I noted in another thread. cheers -ben On Fri, May 20, 2016 at 7:52 PM, wrote: > > Tim Felgentreff uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-tfel.1863.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-tfel.1863 > Author: tfel > Time: 20 May 2016, 1:52:06.566311 pm > UUID: 8e524803-55af-ec4b-aa97-9403376a9b13 > Ancestors: VMMaker.oscog-tfel.1862, VMMaker.oscog-eem.1861 > > Fix Integer>>signedIntFromLong, this should really return a 32-bit signed integer, regardless of the platform's integer size. > > Item was changed: > ----- Method: StackInterpreterSimulator>>primitiveExecuteMethodArgsArray (in category 'control primitives') ----- > primitiveExecuteMethodArgsArray > + self halt: thisContext selector. > + "(objectMemory isOopCompiledMethod: self stackTop) ifFalse: > + [self halt]." > - "self halt: thisContext selector." > - (objectMemory isOopCompiledMethod: self stackTop) ifFalse: > - [self halt]. > ^super primitiveExecuteMethodArgsArray! From btc at openinworld.com Sun Jun 5 03:25:04 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 5 03:25:26 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-tfel.1863.mcz In-Reply-To: References: <573efac3.a6ec420a.21595.5cffSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Sun, Jun 5, 2016 at 11:10 AM, Ben Coman wrote: > Hi Tim, > > I just ran ./buildspurtrunkvmmakerimage.sh(**1) and I'm bumping into a > halt introduced in 1863... > Is it required :) ? > > I see the other halt was previously uncommented. Is that the usual state? > > btw, Are you able to define a general sort of problem that you find > halts useful at this location? > > > **1 Excluding ./updatespurimage.sh which had a problem I noted in > another thread. I see however that the in-Image version is "eem 5/19/2016". Also since I just started trying the CogVMSimulator, I am bumping into the same in CogVMSimulator>>primitiveExecuteMethodArgsArray self halt: thisContext selector. ^ super primitiveExecuteMethodArgsArray but that version "eem 9/30/2013" has been there a while, so I guess it is useful permanently enabled?? Maybe a comment to that effect would be useful to newcomers. cheers -ben > On Fri, May 20, 2016 at 7:52 PM, wrote: >> >> Tim Felgentreff uploaded a new version of VMMaker to project VM Maker: >> http://source.squeak.org/VMMaker/VMMaker.oscog-tfel.1863.mcz >> >> ==================== Summary ==================== >> >> Name: VMMaker.oscog-tfel.1863 >> Author: tfel >> Time: 20 May 2016, 1:52:06.566311 pm >> UUID: 8e524803-55af-ec4b-aa97-9403376a9b13 >> Ancestors: VMMaker.oscog-tfel.1862, VMMaker.oscog-eem.1861 >> >> Fix Integer>>signedIntFromLong, this should really return a 32-bit signed integer, regardless of the platform's integer size. >> > >> Item was changed: >> ----- Method: StackInterpreterSimulator>>primitiveExecuteMethodArgsArray (in category 'control primitives') ----- >> primitiveExecuteMethodArgsArray >> + self halt: thisContext selector. >> + "(objectMemory isOopCompiledMethod: self stackTop) ifFalse: >> + [self halt]." >> - "self halt: thisContext selector." >> - (objectMemory isOopCompiledMethod: self stackTop) ifFalse: >> - [self halt]. >> ^super primitiveExecuteMethodArgsArray! From lewis at mail.msen.com Sun Jun 5 16:55:07 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Sun Jun 5 16:55:10 2016 Subject: [Vm-dev] DSAPrims broken on 64-bit VM (3684) In-Reply-To: References: Message-ID: <20160605165507.GA6041@shell.msen.com> Ron or Robert, Could one of you please add Levente (squeaksource user 'UL') as developer in the Cryptography repository? This is needed so that Levente can update the plugin. Thanks! Dave On Sun, Jun 05, 2016 at 03:30:00AM +0200, Levente Uzonyi wrote: > > I finally checked what actually had changed in the plugin code and I found > that it was unrelated to inlining. The only change was the declaration of > two constants as U instead of ULL[1]. > So, I decided to add the correct type declarations and recompiled the > plugin, which seems to work for me; the image-side tests pass. > Unfortunately, I don't have access to the Cryptography repository, so I > uploaded the changes to my place[2]. > > Levente > > [1] > http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/branches/Cog/src/plugins/DSAPrims/DSAPrims.c?r1=3672&r2=3689 > [2] http://leves.web.elte.hu/squeak/CryptographyPlugins-ul.11.mcz From robert.w.withers at gmail.com Sun Jun 5 18:05:06 2016 From: robert.w.withers at gmail.com (Robert Withers) Date: Sun Jun 5 18:05:10 2016 Subject: [Vm-dev] DSAPrims broken on 64-bit VM (3684) In-Reply-To: <20160605165507.GA6041@shell.msen.com> References: <20160605165507.GA6041@shell.msen.com> Message-ID: <575469D2.3070503@gmail.com> Alright, I've added him as dev. Levente, you should be able save your work, now. Rob On 06/05/2016 12:55 PM, David T. Lewis wrote: > Ron or Robert, > > Could one of you please add Levente (squeaksource user 'UL') as developer > in the Cryptography repository? This is needed so that Levente can update > the plugin. > > Thanks! > > Dave > > On Sun, Jun 05, 2016 at 03:30:00AM +0200, Levente Uzonyi wrote: >> I finally checked what actually had changed in the plugin code and I found >> that it was unrelated to inlining. The only change was the declaration of >> two constants as U instead of ULL[1]. >> So, I decided to add the correct type declarations and recompiled the >> plugin, which seems to work for me; the image-side tests pass. >> Unfortunately, I don't have access to the Cryptography repository, so I >> uploaded the changes to my place[2]. >> >> Levente >> >> [1] >> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/branches/Cog/src/plugins/DSAPrims/DSAPrims.c?r1=3672&r2=3689 >> [2] http://leves.web.elte.hu/squeak/CryptographyPlugins-ul.11.mcz From leves at caesar.elte.hu Sun Jun 5 18:09:37 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sun Jun 5 18:09:47 2016 Subject: [Vm-dev] DSAPrims broken on 64-bit VM (3684) In-Reply-To: <575469D2.3070503@gmail.com> References: <20160605165507.GA6041@shell.msen.com> <575469D2.3070503@gmail.com> Message-ID: Thanks Rob and Dave! I've uploaded the file to the repository. Levente On Sun, 5 Jun 2016, Robert Withers wrote: > Alright, I've added him as dev. Levente, you should be able save your work, > now. > > Rob > > On 06/05/2016 12:55 PM, David T. Lewis wrote: >> Ron or Robert, >> >> Could one of you please add Levente (squeaksource user 'UL') as developer >> in the Cryptography repository? This is needed so that Levente can update >> the plugin. >> >> Thanks! >> >> Dave >> >> On Sun, Jun 05, 2016 at 03:30:00AM +0200, Levente Uzonyi wrote: >>> I finally checked what actually had changed in the plugin code and I found >>> that it was unrelated to inlining. The only change was the declaration of >>> two constants as U instead of ULL[1]. >>> So, I decided to add the correct type declarations and recompiled the >>> plugin, which seems to work for me; the image-side tests pass. >>> Unfortunately, I don't have access to the Cryptography repository, so I >>> uploaded the changes to my place[2]. >>> >>> Levente >>> >>> [1] >>> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/branches/Cog/src/plugins/DSAPrims/DSAPrims.c?r1=3672&r2=3689 >>> [2] http://leves.web.elte.hu/squeak/CryptographyPlugins-ul.11.mcz > > From robert.w.withers at gmail.com Sun Jun 5 18:14:50 2016 From: robert.w.withers at gmail.com (Robert Withers) Date: Sun Jun 5 18:14:55 2016 Subject: [Vm-dev] DSAPrims broken on 64-bit VM (3684) In-Reply-To: References: <20160605165507.GA6041@shell.msen.com> <575469D2.3070503@gmail.com> Message-ID: <57546C1A.7030105@gmail.com> Thanks for looking after crypto, Levente! I wish I could tell you you'll be getting your CryptoClubCard in the mail... Best, Rob On 06/05/2016 02:09 PM, Levente Uzonyi wrote: > Thanks Rob and Dave! I've uploaded the file to the repository. > > Levente > > On Sun, 5 Jun 2016, Robert Withers wrote: > >> Alright, I've added him as dev. Levente, you should be able save your >> work, now. >> >> Rob >> >> On 06/05/2016 12:55 PM, David T. Lewis wrote: >>> Ron or Robert, >>> >>> Could one of you please add Levente (squeaksource user 'UL') as >>> developer >>> in the Cryptography repository? This is needed so that Levente can >>> update >>> the plugin. >>> >>> Thanks! >>> >>> Dave >>> >>> On Sun, Jun 05, 2016 at 03:30:00AM +0200, Levente Uzonyi wrote: >>>> I finally checked what actually had changed in the plugin code and >>>> I found >>>> that it was unrelated to inlining. The only change was the >>>> declaration of >>>> two constants as U instead of ULL[1]. >>>> So, I decided to add the correct type declarations and recompiled the >>>> plugin, which seems to work for me; the image-side tests pass. >>>> Unfortunately, I don't have access to the Cryptography repository, >>>> so I >>>> uploaded the changes to my place[2]. >>>> >>>> Levente >>>> >>>> [1] >>>> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/branches/Cog/src/plugins/DSAPrims/DSAPrims.c?r1=3672&r2=3689 >>>> [2] http://leves.web.elte.hu/squeak/CryptographyPlugins-ul.11.mcz >> >> From commits at source.squeak.org Sun Jun 5 20:57:48 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Jun 5 20:57:50 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.124.mcz Message-ID: Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.124.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.124 Author: tty Time: 5 June 2016, 4:03:32.199266 pm UUID: c48a30ca-d0c8-40a9-a4a3-9a99358540a3 Ancestors: CMakeVMMakerSqueak-tty.123 Start decoupling from pharo code. Add class for testing CMakeTemplates. =============== Diff against CMakeVMMakerSqueak-tty.123 =============== Item was added: + Object subclass: #CMakeGeneratorForSqueak + instanceVariableNames: 'output' + classVariableNames: '' + poolDictionaries: '' + category: 'CMakeVMMakerSqueak'! + + !CMakeGeneratorForSqueak commentStamp: '' prior: 0! + a base class for generating cmake files. + Mainly provides a helper methods of cmake commands api.! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addDefinitions: (in category 'cmake commands') ----- + addDefinitions: aString + ^ self cmd: 'add_definitions' params: aString! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addDependency: (in category 'cmake commands') ----- + addDependency: aName + + self cmd: 'list' + params: 'APPEND ', self moduleName , '_dependencies ' , aName. + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addExternalLibraries: (in category 'cmake commands') ----- + addExternalLibraries: libs + + libs do: [:each | self addExternalLibrary: each ]! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addExternalLibrary: (in category 'cmake commands') ----- + addExternalLibrary: aLibrary + self cmd: 'list' + params: 'APPEND LINKLIBS ' , aLibrary . + + " self cmd: 'target_link_libraries' + params: self moduleName , ' ' , aLibrary. + " + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addFrameworks: (in category 'cmake commands') ----- + addFrameworks: aCollection + "for mac only " + aCollection + do: [:each | + self cmd: 'find_library' params: each , '_FMWK ', each. + self addExternalLibrary: '${', each , '_FMWK}' ]! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addProperty:value: (in category 'cmake commands') ----- + addProperty: propertyString value: valueString + self puts: 'set_target_properties(' , self moduleName , ' PROPERTIES ' , propertyString , ' "' , valueString, '")' + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addSource: (in category 'sources management') ----- + addSource: aFileName + + ^ self addSources: { aFileName }! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addSources: (in category 'sources management') ----- + addSources: aFileNames + + ^ self addSources: aFileNames prefixed: ''! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addSources:prefixed: (in category 'sources management') ----- + addSources: aFileNames prefixed: aPrefix + + | names | + names := aFileNames inject: '' into: [:res :each | res , ' "' , aPrefix, each, '"' ]. + + self puts: 'list(APPEND sources ', names , ')'! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addSubdirectory: (in category 'cmake commands') ----- + addSubdirectory: aDir + + ^ self cmd: 'add_subdirectory' qparams: aDir. + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>addXCodeProperty:value: (in category 'cmake commands') ----- + addXCodeProperty: propertyString value: valueString + self + addProperty: 'XCODE_ATTRIBUTE_' , propertyString + value: valueString + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>captureOutputDuring: (in category 'code generation') ----- + captureOutputDuring: aBlock + | old result | + + old := output. + output := String new writeStream. + + aBlock value. + + result := output. + output := old. + + ^ result contents! Item was added: + ----- Method: CMakeGeneratorForSqueak>>cmd:params: (in category 'cmake commands') ----- + cmd: cmdName params: aString + + output nextPutAll: cmdName; + nextPut: $(; + nextPutAll: aString; + nextPut: $); + cr + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>cmd:qparams: (in category 'cmake commands') ----- + cmd: cmdName qparams: aString + "quoted params" + output nextPutAll: cmdName; + nextPutAll: '("'; + nextPutAll: aString; + nextPutAll: '")'; + cr + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>generate (in category 'code generation') ----- + generate + self subclassResponsibility.! Item was added: + ----- Method: CMakeGeneratorForSqueak>>include: (in category 'cmake commands') ----- + include: aFileName + ^ self cmd: 'include' params: aFileName! Item was added: + ----- Method: CMakeGeneratorForSqueak>>includeDirectories: (in category 'cmake commands') ----- + includeDirectories: aString + ^ self cmd: 'include_directories' params: aString! Item was added: + ----- Method: CMakeGeneratorForSqueak>>linkDirectories: (in category 'cmake commands') ----- + linkDirectories: aString + ^ self cmd: 'link_directories' params: aString! Item was added: + ----- Method: CMakeGeneratorForSqueak>>message: (in category 'cmake commands') ----- + message: aString + + self cmd: 'message' qparams: aString.! Item was added: + ----- Method: CMakeGeneratorForSqueak>>moduleName (in category 'accessing') ----- + moduleName + self subclassResponsibility! Item was added: + ----- Method: CMakeGeneratorForSqueak>>output (in category 'accessing') ----- + output + ^ output! Item was added: + ----- Method: CMakeGeneratorForSqueak>>output: (in category 'accessing') ----- + output: aStream + + output := aStream! Item was added: + ----- Method: CMakeGeneratorForSqueak>>outputFileName (in category 'accessing') ----- + outputFileName + ^ 'CMakeLists.txt'! Item was added: + ----- Method: CMakeGeneratorForSqueak>>printHeader (in category 'as yet unclassified') ----- + printHeader + + self puts: '# This is automatically generated file using ', self configurationName, ' on ', + Date current asString, ' ' , Time current asString; + puts: 'cmake_minimum_required(VERSION 2.6.2)'! Item was added: + ----- Method: CMakeGeneratorForSqueak>>project: (in category 'cmake commands') ----- + project: aProjectName + self cmd: 'project' qparams: aProjectName + ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>puts: (in category 'as yet unclassified') ----- + puts: aString + output nextPutAll: aString; cr! Item was added: + ----- Method: CMakeGeneratorForSqueak>>set:to: (in category 'cmake commands') ----- + set: variableName to: aValueString + + self cmd: 'set' params: variableName , ' ' , aValueString! Item was added: + ----- Method: CMakeGeneratorForSqueak>>set:toString: (in category 'cmake commands') ----- + set: variableName toString: aValueString + + ^ self set: variableName to: '"', (aValueString copyReplaceAll: '"' with: '\"'), '"'! Item was added: + ----- Method: CMakeGeneratorForSqueak>>setTargetProperties: (in category 'cmake commands') ----- + setTargetProperties: properties + self cmd: 'set_target_properties' params: self moduleName, ' PROPERTIES ', properties ! Item was added: + ----- Method: CMakeGeneratorForSqueak>>setTargetProperty:to: (in category 'cmake commands') ----- + setTargetProperty: propertyString to: aString + self + cmd: 'set_target_properties' + params: (String streamContents: [ :stream | + stream + nextPutAll: self moduleName; + nextPutAll: ' PROPERTIES '; + nextPutAll: propertyString; + space; + nextPutAll: aString ])! Item was added: + ----- Method: CMakeGeneratorForSqueak>>setTargetProperty:toAll: (in category 'cmake commands') ----- + setTargetProperty: propertyString toAll: aCollection + ^self + setTargetProperty: propertyString + to: (String streamContents: [ :stream | + aCollection + do: [ :each | stream nextPutAll: each ] + separatedBy: [ stream nextPut: $, ] ])! Item was added: + ----- Method: CMakeGeneratorForSqueak>>setTargetProperty:toString: (in category 'cmake commands') ----- + setTargetProperty: propertyString toString: aString + self + cmd: 'set_target_properties' + params: (String streamContents: [ :stream | + stream + nextPutAll: self moduleName; + nextPutAll: ' PROPERTIES '; + nextPutAll: propertyString; + space; + nextPut: $"; + nextPutAll: (aString copyReplaceAll: '"' with: '\"'); + nextPut: $" + ])! Item was changed: + CMakeGeneratorForSqueak subclass: #CMakePluginGeneratorForSqueak - CMakeGenerator subclass: #CMakePluginGeneratorForSqueak instanceVariableNames: 'plugin vmGen internal extraRules doNotGenerate externalDependencies configDotCMake templates' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak'! !CMakePluginGeneratorForSqueak commentStamp: 'tty 12/8/2014 11:28' prior: 0! A CMakePluginGeneratorForSqueak overides some CMakeVMPluginGenerator methods for squeak compatibility. I also add Dictionary for storing a plugins config.cmake file ! Item was added: + ----- Method: CMakePluginVm>>initialize (in category 'as yet unclassified') ----- + initialize + "initialize to nonsense values to aid in debugging." + config := 'a config'. + definitions := 'vm plugin compiler definitions'. + module := ' vm plugin module'. + sources := 'vm plugin sources'. + includedirectories:= 'vm plugin include directories'. + self content:' Customize a CMakePluginVm(', config, ' ' , ' ' , definitions, ' ' , ' ' , module , ' ' ,self sources, ' ' , includedirectories,')'! Item was changed: ----- Method: CMakeSqConfigH>>initialize (in category 'initialize-release') ----- initialize - " - IF (NOT DEFINED __sq_config_h) - - rest of config.cmake here + " See class comment" + + content:='should not get here. writestream is used instead of content. this is a hack for tests to pass.'. - ENDIF (NOT DEFINED __sq_config_h)" templates := OrderedCollection new. output := String new writeStream. self puts: 'IF (NOT DEFINED __sq_config_h) SET(__sq_config_h 1) CONFIG_DEFINE(__sq_config_h) '. ! Item was changed: + CMakeGeneratorForSqueak subclass: #CMakeTemplate - CMakeGenerator subclass: #CMakeTemplate instanceVariableNames: 'content' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak-CMakeTemplates'! !CMakeTemplate commentStamp: 'tty 12/8/2014 11:08' prior: 0! A CMakeTemplate is a wrapper for CMake commands, variables and definitions. Generators output my contents into their files. N.B. The motivations for this approach are: 1. I found the Pharo methods in CMakeGenerator 's (cmake commands protocol) difficult to parse and debug. 2, As I developed it bacame apparent that the key to making this project work is to "THINK IN CMake". 3. I find the Seaside approach of using Components to generate a web-page is a useful idiom for generating CMake files. 4. Using wrappers for the CMake commands eases re-use and consistency that radically sped up development. 5. It is easy to add new templates. Just find the CMake construct you want, subclass me, and model it such that its output generates the correct CMake "thing" cmake --help-commands cmake --help-command cmake --help-command-list cmake --help-commands cmake --help-module cmake --help-module-list cmake --help-modules cmake --help-policy cmake --help-policy-list cmake --help-policies cmake --help-property cmake --help-property-list cmake --help-properties cmake --help-variable var cmake --help-variable-list cmake --help-variables If you need a custom version of my subclasses, just set 'content: your custom content here' on the appropriate subclass (or on me) ! Item was changed: + CMakeGeneratorForSqueak subclass: #CMakeVMGeneratorForSqueak - CMakeGenerator subclass: #CMakeVMGeneratorForSqueak instanceVariableNames: 'internalPlugins externalPlugins config' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak'! !CMakeVMGeneratorForSqueak commentStamp: 'tty 5/16/2014 15:52' prior: 0! A CMakeVMGeneratorForSqueak overides some CMakeVMGenerator methos for squeak compatibility. ! Item was added: + TestCase subclass: #CMakeVMMakerSqueakCMakeTemplatesTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'CMakeVMMakerSqueak-Tests'! Item was added: + ----- Method: CMakeVMMakerSqueakCMakeTemplatesTest>>testCMakeTemplateContent (in category 'as yet unclassified') ----- + testCMakeTemplateContent + "a template encapsulates CMake content and should have default content on instantiation" + CMakeTemplate + subclassesDo:[:c | |template| + template := c new. + template initialize. + " template content inspect." + self assert: ((template content) isString)] + + ! Item was changed: ----- Method: SqueakCMThirdpartyLibrary>>generateFor: (in category 'as yet unclassified') ----- generateFor: aVMGenerator | libDir stream contents | self flag:'tty'. "This l must be transformed to generateByTemplateFor: and the output converted to CMakeTemplates" self break. vmGen := aVMGenerator. + gen := CMakeGeneratorForSqueak new - gen := CMakeGenerator new output: (String new writeStream). libDir := (aVMGenerator thirdpartyDir / self canonicalName) assureExistence. stream := String new writeStream. self generate. stream nextPutAll: (vmGen config fixLineEndsOf: gen output contents). contents := stream contents. (self isFile: (libDir / gen outputFileName) fullName hasContents: contents) ifFalse: [ "contents changed, update the file. Because fucking cmake will force rebuild everything if we change its modification date without changing its contents" (FileStream forceNewFileNamed: (libDir / gen outputFileName) pathName) nextPutAll: contents; close. ]. vmGen addSubdirectory: vmGen thirdpartyDirName , '/' , self canonicalName. self defineGlobalTargets. ! From btc at openinworld.com Mon Jun 6 02:19:07 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 6 02:19:30 2016 Subject: [Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire [HOLD] Message-ID: On Sat, Jun 4, 2016 at 12:07 PM, Ben Coman wrote: > > So having *mostly* produced a technical proof of concept (for > StackVM), the meta-question is whether a change like this worth > pursuing? Apart from my own need for the OwnedLock > primitiveWaitAcquire, I have cluelessly wondered if there might be any > benefit for multi-threading or callback patterns, now or in the > future. > > Also, are there any obvious/known difficulties to be expected doing > this with JIT side? I'll hold back from those questions for now. I'm trying an alternative approach that doesn't involve changing the cross-suspension primitiveFail semantics. cheers -ben From btc at openinworld.com Mon Jun 6 11:44:26 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 6 11:44:48 2016 Subject: [Vm-dev] #resume:preemptedYieldingIf: not fair? Message-ID: At the bottom of InterpreterPrimitives>>primitiveExitCriticalSection is the comment "Note that resume: isn't fair; it won't suspend the active process." but #resume:preemptedYieldingIf: has the following newPriority <= activePriority ifTrue: [self putToSleep: aProcess yieldingIf: true. ^false]. self putToSleep: activeProc yieldingIf: yieldImplicitly. where that that last line seems contrary to the primitiveExitCriticalSection comment. Could someone clarify this? cheers -ben From commits at squeakvm.org Mon Jun 6 16:47:46 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Mon Jun 6 16:47:36 2016 Subject: [Vm-dev] [commit][3737] Revise ARM fp offset from SP - FP is set to point to the saved return address which is 32 vbits beyond the prior SP , thus always +4 bytes offset from the SP alignment Message-ID: Revision: 3737 Author: rowledge Date: 2016-06-06 09:47:45 -0700 (Mon, 06 Jun 2016) Log Message: ----------- Revise ARM fp offset from SP - FP is set to point to the saved return address which is 32 vbits beyond the prior SP, thus always +4 bytes offset from the SP alignment Modified Paths: -------------- branches/Cog/platforms/Cross/vm/sqCogStackAlignment.h Modified: branches/Cog/platforms/Cross/vm/sqCogStackAlignment.h =================================================================== --- branches/Cog/platforms/Cross/vm/sqCogStackAlignment.h 2016-06-02 01:08:20 UTC (rev 3736) +++ branches/Cog/platforms/Cross/vm/sqCogStackAlignment.h 2016-06-06 16:47:45 UTC (rev 3737) @@ -27,7 +27,7 @@ * require 8-byte aligned addresses to access doubles in memory. */ # define STACK_ALIGN_BYTES 8 -# define STACK_FP_ALIGNMENT 0 +# define STACK_FP_ALIGNMENT 4 #endif #if defined(x86_64) || defined(__amd64) || defined(__x86_64) || defined(__amd64__) || defined(__x86_64__) || defined(_M_AMD64) || defined(_M_X64) From commits at source.squeak.org Mon Jun 6 19:40:21 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Jun 6 19:40:23 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1880.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1880.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1880 Author: eem Time: 6 June 2016, 12:38:04.937574 pm UUID: 1d6ad311-63fd-456b-bc35-aaaf1d9f1829 Ancestors: VMMaker.oscog-eem.1879 Minor cleanups prior to checking in primitive retry on allocation failure. In 1880 the first electric streetlight is installed in Wabash, Indiana. =============== Diff against VMMaker.oscog-eem.1879 =============== Item was changed: ----- Method: InterpreterPrimitives>>failed (in category 'primitive support') ----- failed + "In C, non-zero is true, so avoid computation by simply answering primFailCode in the C version." ^self cCode: [primFailCode] inSmalltalk: [primFailCode ~= 0]! Item was changed: ----- Method: InterpreterPrimitives>>primitiveIncrementalGC (in category 'memory space primitives') ----- primitiveIncrementalGC "Do a quick, incremental garbage collection and return the number of bytes immediately available. (Note: more space may be made available by doing a full garbage collection." + objectMemory hasSpurMemoryManagerAPI + ifTrue: [objectMemory scavengingGC] + ifFalse: [objectMemory incrementalGC]. - objectMemory incrementalGC. self pop: 1 thenPushInteger: (objectMemory bytesLeft: false)! Item was changed: CogClass subclass: #SpurMemoryManager (excessive size, no diff calculated) Item was changed: ----- Method: StackInterpreterPrimitives>>primitiveIncrementalGC (in category 'memory space primitives') ----- primitiveIncrementalGC "Do a quick, incremental garbage collection and return the number of bytes immediately available. (Note: more space may be made available by doing a full garbage collection." self externalWriteBackHeadFramePointers. + super primitiveIncrementalGC! - objectMemory hasSpurMemoryManagerAPI - ifTrue: [objectMemory scavengingGC] - ifFalse: [objectMemory incrementalGC]. - self pop: 1 thenPushInteger: (objectMemory bytesLeft: false)! From commits at source.squeak.org Mon Jun 6 19:57:16 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Jun 6 19:57:18 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1881.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1881.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1881 Author: eem Time: 6 June 2016, 12:55:12.14917 pm UUID: c51b1764-ddf8-49fc-92bd-d587b3d65101 Ancestors: VMMaker.oscog-eem.1880 On Spur, handle external primitive failures answering PrimErrNoMemory by doing a scavenge and retrying and then on subsequent PrimErrNoMemory failure a full GC and then retrying. Rename maybeRetryFailureDueToForwarding to maybeRetryPrimitiveOnFailure. In the Cogit, change the retry mechanism so that the primitive call is made in the run-time, instead of the run-time answering whether the primitive should be retried and returning to machine code that then retries. In the simulator, go through the contortions to map[ back whatever primitiveFunctionPointer is to that which dispatchFunctionPointer: accepts. Discussion: First, this mechanism applies only to external (plugin) primitives. Spur's core primtives are written in the expectation that image-level primitive failure code will deal with the failure and retry. This corresponds to the VisualWorks style and allows the image to implement GC policy (e.g. to favour reclamation over growth). So with the current Spur code, heavily influenced by the author's experience with VisualWorks, it would be inapproprate to retry corte primitives on being out-of-memory. The pathology is that attempts at very large allocations which will inevitably fail will cause a GC in the VM, very possibly followed by a GC from the image level primitive failure code. Whereas leaving it to the image, the image code may be intellkigent enough to spot an allocation too large to ever succeed and avoid the GC altogether. I'm not sure if I like this auto-retry or not. Perhaps it is a good idea and the image-level primitive failure code should be changed; there would certainly be fewer image-level methods. But that means fewer hooks for the image to implement GC policy. retryPrimitiveOnFailure which manages the retry isn't exactly simple (mapping back the primitiveFunctionPointer to something dispatchFunctionPointer: can manage isn't simple either, but that's simulation only, and so its complications carry much less weight). =============== Diff against VMMaker.oscog-eem.1880 =============== Item was changed: ----- Method: CoInterpreter>>ceActivateFailingPrimitiveMethod: (in category 'enilopmarts') ----- ceActivateFailingPrimitiveMethod: aPrimitiveMethod "An external call or FFI primitive has failed. Build the frame and activate as appropriate. Enter either the interpreter or machine code depending on whether aPrimitiveMethod has been or is still cogged. Note that we could always interpret but want the efficiency of executing machine code if it is available." | methodHeader result | self assert: primFailCode ~= 0. self assert: newMethod = aPrimitiveMethod. + "If we're on Spur, retry the primitive, if appropriate, + returning if successful after retry." + objectMemory hasSpurMemoryManagerAPI ifTrue: + [self retryPrimitiveOnFailure. - "If we're on Spur, check for forwarders and retry, - returning if successful the second time around." - (objectMemory hasSpurMemoryManagerAPI - and: [self checkForAndFollowForwardedPrimitiveState]) ifTrue: - [self initPrimCall. - self cCode: [self dispatchFunctionPointer: primitiveFunctionPointer] - inSmalltalk: - [| evaluable | - evaluable := primitiveFunctionPointer isInteger - ifTrue: [cogit simulatedTrampolines at: primitiveFunctionPointer] - ifFalse: [primitiveFunctionPointer]. - evaluable isMessageSend - ifTrue: [self assert: evaluable receiver == self] - ifFalse: [self assert: evaluable isBlock]. - evaluable value]. self successful ifTrue: [result := self stackTop. self stackTopPut: instructionPointer. self push: result. cogit ceEnterCogCodePopReceiverReg]]. methodHeader := self rawHeaderOf: aPrimitiveMethod. (self isCogMethodReference: methodHeader) ifTrue: [self activateCoggedNewMethod: false] ifFalse: [self activateNewMethod]! Item was added: + ----- Method: CoInterpreter>>ceCheckAndMaybeRetryPrimitive: (in category 'primitive support') ----- + ceCheckAndMaybeRetryPrimitive: primIndex + "Log failure and then retry if there's an accessorDepth or failure due to no memory." + + | retried | + cogit recordPrimTrace ifTrue: + [self fastLogPrim: TracePrimitiveFailure]. + retried := self retryPrimitiveOnFailure. + (retried and: [cogit recordPrimTrace]) ifTrue: + [self fastLogPrim: TracePrimitiveRetry]! Item was removed: - ----- Method: CoInterpreter>>ceCheckForAndFollowForwardedPrimitiveState (in category 'cog jit support') ----- - ceCheckForAndFollowForwardedPrimitiveState - "In Spur a primitive may fail due to encountering a forwarder. - On failure check the accessorDepth for the primitive and - if non-negative scan the args to the depth, following any - forwarders. Answer if any are found so the prim can be retried." - - - ^self cCode: [self checkForAndFollowForwardedPrimitiveState] - inSmalltalk: [(self checkForAndFollowForwardedPrimitiveState) - ifTrue: [1] - ifFalse: [0]]! Item was added: + ----- Method: CoInterpreter>>primNumberExternalCall (in category 'compiled methods') ----- + primNumberExternalCall + "Answer if the method is an external primtiive call (prim 117)." + + + ^PrimNumberExternalCall! Item was removed: - ----- Method: CogObjectRepresentation>>maybeCompileRetry:onPrimitiveFail: (in category 'primitive generators') ----- - maybeCompileRetry: retryInst onPrimitiveFail: primIndex - - "Object representations with lazy forwarding will want to check for - forwarding pointers on primitive failure and retry the primitive if found. - By default do nothing."! Item was added: + ----- Method: CogObjectRepresentation>>maybeCompileRetryOnPrimitiveFail: (in category 'primitive generators') ----- + maybeCompileRetryOnPrimitiveFail: primIndex + "Object representations with lazy forwarding will want to check for + forwarding pointers on primitive failure and retry the primitive if found. + By default do nothing." + ! Item was removed: - ----- Method: CogObjectRepresentationForSpur>>maybeCompileRetry:onPrimitiveFail: (in category 'primitive generators') ----- - maybeCompileRetry: retryInst onPrimitiveFail: primIndex - - "If primIndex has an accessorDepth, check for primitive failure and call - ceCheckForAndFollowForwardedPrimitiveState if so If ceCheck.... answers - true, retry the primitive." - | jmp | - - (coInterpreter accessorDepthForPrimitiveIndex: primIndex) < 0 ifTrue: - [^0]. - cogit MoveAw: coInterpreter primFailCodeAddress R: TempReg. - cogit CmpCq: 0 R: TempReg. - jmp := cogit JumpZero: 0. - cogit - compileCallFor: #ceCheckForAndFollowForwardedPrimitiveState - numArgs: 0 - arg: nil - arg: nil - arg: nil - arg: nil - resultReg: TempReg - regsToSave: cogit emptyRegisterMask. - cogit CmpCq: 0 R: TempReg. - cogit JumpNonZero: retryInst. - jmp jmpTarget: cogit Label. - ^0! Item was added: + ----- Method: CogObjectRepresentationForSpur>>maybeCompileRetryOnPrimitiveFail: (in category 'primitive generators') ----- + maybeCompileRetryOnPrimitiveFail: primIndex + + "If primIndex has an accessorDepth and fails, or it is external and fails with PrimErrNoMemory, + call ceCheckAndMaybeRetryPrimitive if so If ceCheck.... answers true, retry the primitive." + | jmp | + + (coInterpreter accessorDepthForPrimitiveIndex: primIndex) >= 0 + ifTrue: + [jmp := cogit + MoveAw: coInterpreter primFailCodeAddress R: TempReg; + CmpCq: 0 R: TempReg; + JumpZero: 0] + ifFalse: + [coInterpreter primNumberExternalCall ~= primIndex ifTrue: + [^0]. + jmp := cogit + MoveAw: coInterpreter primFailCodeAddress R: TempReg; + CmpCq: PrimErrNoMemory R: TempReg; + JumpNonZero: 0]. + cogit + compileCallFor: #ceCheckAndMaybeRetryPrimitive: + numArgs: 1 + arg: (cogit trampolineArgConstant: primIndex) + arg: nil + arg: nil + arg: nil + resultReg: TempReg + regsToSave: cogit emptyRegisterMask. + jmp jmpTarget: cogit Label. + ^0! Item was added: + ----- Method: CogVMSimulator>>mappedPluginEntries (in category 'plugin support') ----- + mappedPluginEntries + ^mappedPluginEntries! Item was added: + ----- Method: CogVMSimulator>>maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable (in category 'primitive support') ----- + maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable + "In the real VM primitiveFunctionPointer is either an index (for quick primitives) + or a proper function pointer to a primitive. In the simulator it may be a small + index (corresponding to a quick primitive index), a symbol (corresponding to + a function pointer) or an index into the externalPrimitiveTable, or an invalid + address that references an evaluable in the simulatedTrampolines dictionary + of the Cogit. The simulator expects dispatchFunctionPointer to be called with + primitiveFunctionPointer being a symbol only for internal primitives. External + primitives must have their funciton pointer mapped back to an index. This + method does the mapping back from fake addresses." + + (primitiveFunctionPointer isInteger + and: [self isExternalPrimitiveCall: newMethod]) ifTrue: "External prims must be evaluated by the right plugin..." + [(cogit simulatedTrampolines at: primitiveFunctionPointer ifAbsent: nil) ifNotNil: + [:evaluable| | pfp index externalIndex | + "primitiveFunctionPointer := pfp" + "(1 to: self mappedPluginEntries size) select: [:index| (self mappedPluginEntries at: index) third == evaluable]" + pfp := primitiveFunctionPointer. + index := self mappedPluginEntries findFirst: [:entry| entry third == evaluable]. + self assert: index ~= 0. + externalIndex := 1000 + (externalPrimitiveTable object + indexOf: index + ifAbsent: [self error: 'entry not found']). + self assert: ((self pluginEntryFor: externalIndex) notNil + and: [(self pluginEntryFor: externalIndex) third == evaluable]). + primitiveFunctionPointer := externalIndex. + ^self]]. + ^super maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable! Item was added: + ----- Method: CurrentImageCoInterpreterFacadeForSpurObjectRepresentation>>ceCheckAndMaybeRetryPrimitive: (in category 'accessing') ----- + ceCheckAndMaybeRetryPrimitive: primIndex + ^coInterpreter ceCheckAndMaybeRetryPrimitive: primIndex! Item was removed: - ----- Method: CurrentImageCoInterpreterFacadeForSpurObjectRepresentation>>ceCheckForAndFollowForwardedPrimitiveState (in category 'accessing') ----- - ceCheckForAndFollowForwardedPrimitiveState - ^coInterpreter ceCheckForAndFollowForwardedPrimitiveState! Item was changed: ----- Method: SimpleStackBasedCogit>>compileInterpreterPrimitive: (in category 'primitive generators') ----- compileInterpreterPrimitive: primitiveRoutine "Compile a call to an interpreter primitive. Call the C routine with the usual stack-switching dance, test the primFailCode and then either return on success or continue to the method body." + | flags jmp jmpSamplePrim continuePostSamplePrim jmpSampleNonPrim continuePostSampleNonPrim | - | flags jmp jmpSamplePrim retry continuePostSamplePrim jmpSampleNonPrim continuePostSampleNonPrim | - - + "Save processor fp, sp and return pc in the interpreter's frame stack and instruction pointers" self genExternalizePointersForPrimitiveCall. "Switch to the C stack." self genLoadCStackPointersForPrimCall. flags := coInterpreter primitivePropertyFlags: primitiveIndex. (flags anyMask: PrimCallDoNotJIT) ifTrue: [^ShouldNotJIT]. (flags anyMask: PrimCallCollectsProfileSamples) ifTrue: ["Test nextProfileTick for being non-zero and call checkProfileTick if so" objectMemory wordSize = 4 ifTrue: [self MoveAw: coInterpreter nextProfileTickAddress R: TempReg. self MoveAw: coInterpreter nextProfileTickAddress + objectMemory wordSize R: ClassReg. self OrR: TempReg R: ClassReg] ifFalse: [self MoveAw: coInterpreter nextProfileTickAddress R: TempReg. self CmpCq: 0 R: TempReg]. "If set, jump to record sample call." jmpSampleNonPrim := self JumpNonZero: 0. continuePostSampleNonPrim := self Label]. "Old full prim trace is in VMMaker-eem.550 and prior" self recordPrimTrace ifTrue: [self genFastPrimTraceUsing: ClassReg and: SendNumArgsReg]. "Clear the primFailCode and set argumentCount" + self MoveCq: 0 R: TempReg. - retry := self MoveCq: 0 R: TempReg. self MoveR: TempReg Aw: coInterpreter primFailCodeAddress. methodOrBlockNumArgs ~= 0 ifTrue: [self MoveCq: methodOrBlockNumArgs R: TempReg]. self MoveR: TempReg Aw: coInterpreter argumentCountAddress. "If required, set primitiveFunctionPointer and newMethod" (flags anyMask: PrimCallNeedsPrimitiveFunction) ifTrue: [self MoveCw: primitiveRoutine asInteger R: TempReg. primSetFunctionLabel := self MoveR: TempReg Aw: coInterpreter primitiveFunctionPointerAddress]. (flags anyMask: PrimCallNeedsNewMethod+PrimCallMayCallBack) ifTrue: ["The ceActivateFailingPrimitiveMethod: machinery can't handle framelessness." (flags anyMask: PrimCallMayCallBack) ifTrue: [needsFrame := true]. methodLabel addDependent: (self annotateAbsolutePCRef: (self MoveCw: methodLabel asInteger R: ClassReg)). self MoveMw: (self offset: CogMethod of: #methodObject) r: ClassReg R: TempReg. self MoveR: TempReg Aw: coInterpreter newMethodAddress]. "Invoke the primitive" self PrefetchAw: coInterpreter primFailCodeAddress. (flags anyMask: PrimCallMayCallBack) ifTrue: "Sideways call the C primitive routine so that we return through cePrimReturnEnterCogCode." ["On Spur ceActivateFailingPrimitiveMethod: would like to retry if forwarders are found. So insist on PrimCallNeedsPrimitiveFunction being set too." self assert: (flags anyMask: PrimCallNeedsPrimitiveFunction). backEnd genSubstituteReturnAddress: ((flags anyMask: PrimCallCollectsProfileSamples) ifTrue: [cePrimReturnEnterCogCodeProfiling] ifFalse: [cePrimReturnEnterCogCode]). primInvokeInstruction := self JumpFullRT: primitiveRoutine asInteger. jmp := jmpSamplePrim := continuePostSamplePrim := nil] ifFalse: ["Call the C primitive routine." primInvokeInstruction := self CallFullRT: primitiveRoutine asInteger. (flags anyMask: PrimCallCollectsProfileSamples) ifTrue: [self assert: (flags anyMask: PrimCallNeedsNewMethod). "Test nextProfileTick for being non-zero and call checkProfileTick if so" objectMemory wordSize = 4 ifTrue: [self MoveAw: coInterpreter nextProfileTickAddress R: TempReg. self MoveAw: coInterpreter nextProfileTickAddress + objectMemory wordSize R: ClassReg. self OrR: TempReg R: ClassReg] ifFalse: [self MoveAw: coInterpreter nextProfileTickAddress R: TempReg. self CmpCq: 0 R: TempReg]. "If set, jump to record sample call." jmpSamplePrim := self JumpNonZero: 0. continuePostSamplePrim := self Label]. + objectRepresentation maybeCompileRetryOnPrimitiveFail: primitiveIndex. - objectRepresentation maybeCompileRetry: retry onPrimitiveFail: primitiveIndex. self maybeCompileAllocFillerCheck. "Switch back to the Smalltalk stack. Stack better be in either of these two states: success: stackPointer -> result (was receiver) arg1 ... argN return pc failure: receiver arg1 ... stackPointer -> argN return pc In either case we can push the instructionPointer or load it into the LinkRegister to reestablish the return pc" self MoveAw: coInterpreter instructionPointerAddress R: (backEnd hasLinkRegister ifTrue: [LinkReg] ifFalse: [ClassReg]). backEnd genLoadStackPointers. "Test primitive failure" self MoveAw: coInterpreter primFailCodeAddress R: TempReg. backEnd hasLinkRegister ifFalse: [self PushR: ClassReg]. "Restore return pc on CISCs" self flag: 'ask concrete code gen if move sets condition codes?'. self CmpCq: 0 R: TempReg. jmp := self JumpNonZero: 0. "Fetch result from stack" self MoveMw: (backEnd hasLinkRegister ifTrue: [0] ifFalse: [objectMemory wordSize]) r: SPReg R: ReceiverResultReg. self RetN: objectMemory wordSize]. "return to caller, popping receiver" (flags anyMask: PrimCallCollectsProfileSamples) ifTrue: ["The sample is collected by cePrimReturnEnterCogCode for external calls" jmpSamplePrim ifNotNil: ["Call ceCheckProfileTick: to record sample and then continue." jmpSamplePrim jmpTarget: self Label. self assert: (flags anyMask: PrimCallNeedsNewMethod). self CallFullRT: (self cCode: [#ceCheckProfileTick asUnsignedLong] inSmalltalk: [self simulatedTrampolineFor: #ceCheckProfileTick]). "reenter the post-primitive call flow" self Jump: continuePostSamplePrim]. "Null newMethod and call ceCheckProfileTick: to record sample and then continue. ceCheckProfileTick will map null/0 to coInterpreter nilObject" jmpSampleNonPrim jmpTarget: self Label. self MoveCq: 0 R: TempReg. self MoveR: TempReg Aw: coInterpreter newMethodAddress. self CallFullRT: (self cCode: [#ceCheckProfileTick asUnsignedLong] inSmalltalk: [self simulatedTrampolineFor: #ceCheckProfileTick]). "reenter the post-primitive call flow" self Jump: continuePostSampleNonPrim]. jmp ifNotNil: ["Jump to restore of receiver reg and proceed to frame build for failure." jmp jmpTarget: self Label. "Restore receiver reg from stack. If on RISCs ret pc is in LinkReg, if on CISCs ret pc is on stack." self MoveMw: objectMemory wordSize * (methodOrBlockNumArgs + (backEnd hasLinkRegister ifTrue: [0] ifFalse: [1])) r: SPReg R: ReceiverResultReg]. ^0! Item was changed: CogClass subclass: #SpurMemoryManager (excessive size, no diff calculated) Item was added: + ----- Method: StackInterpreter>>maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable (in category 'primitive support') ----- + maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable + "In the real VM primitiveFunctionPointer is either an index (for quick primitives) + or a proper function pointer to a primitive. In the simulator it may be a small + index (corresponding to a quick primitive index), a symbol (corresponding to + a function pointer) or an index into the externalPrimitiveTable, or an invalid + address that references an evaluable in the simulatedTrampolines dictionary + of the Cogit. The simulator expects dispatchFunctionPointer to be called with + primitiveFunctionPointer being a symbol only for internal primitives. External + primitives must have their funciton pointer mapped back to an index. This + method does the reverse mapping." + + (self isExternalPrimitiveCall: newMethod) ifTrue: "External prims must be evaluated by the right plugin..." + [| pfp index externalIndex | + pfp := primitiveFunctionPointer. + index := self mappedPluginEntries findFirst: [:entry| entry second == primitiveFunctionPointer]. + self assert: index ~= 0. + externalIndex := 1000 + (externalPrimitiveTable object + indexOf: index + ifAbsent: [self error: 'entry not found']). + self assert: ((self pluginEntryFor: externalIndex) notNil + and: [(self pluginEntryFor: externalIndex) second == primitiveFunctionPointer]). + primitiveFunctionPointer := externalIndex]! Item was removed: - ----- Method: StackInterpreter>>maybeRetryFailureDueToForwarding (in category 'primitive support') ----- - maybeRetryFailureDueToForwarding - "In Spur a primitive may fail due to encountering a forwarder. On failure, check - the accessorDepth for the primitive and if non-negative scan the args to the - depth, following any forwarders. Retry the primitive if any are found." - - (objectMemory hasSpurMemoryManagerAPI - and: [self failed - and: [self checkForAndFollowForwardedPrimitiveState]]) ifTrue: - [self initPrimCall. - self dispatchFunctionPointer: primitiveFunctionPointer]! Item was added: + ----- Method: StackInterpreter>>maybeRetryPrimitiveOnFailure (in category 'primitive support') ----- + maybeRetryPrimitiveOnFailure + "In Spur two cases of pirmitive failure are handled specially. A primitive may fail due to validation + encountering a forwarder. On failure, check the accessorDepth for the primitive and if non-negative + scan the args to the depth, following any forwarders. Retry the primitive if any are found. Hence + lazily and transparently following forwarders on primtiive failue. Additionally a prmitive might fail + due to an allocation failing. Retry if primitives have failed with PrimErrNoMemory after running + first the scavenger and then on a subsequent failure, the global mark-sweep collector. Hence lazily + and transparently GC on memory exhaustion." + + (objectMemory hasSpurMemoryManagerAPI and: [self failed]) ifTrue: + [self retryPrimitiveOnFailure]! Item was added: + ----- Method: StackInterpreter>>retryPrimitiveOnFailure (in category 'primitive support') ----- + retryPrimitiveOnFailure + "In Spur two cases of pirmitive failure are handled specially. A primitive may fail due to validation + encountering a forwarder. On failure, check the accessorDepth for the primitive and if non-negative + scan the args to the depth, following any forwarders. Retry the primitive if any are found. Hence + lazily and transparently following forwarders on primtiive failure. Additionally a prmitive might fail + due to an allocation failing. Retry if external primitives have failed with PrimErrNoMemory after running + first the scavenger and then on a subsequent failure, the global mark-sweep collector. Hence lazily + and transparently GC on memory exhaustion." + + | gcDone followDone canRetry retry retried | + gcDone := 0. + followDone := canRetry := retried := false. + [retry := false. + primFailCode = PrimErrNoMemory + ifTrue: + [(gcDone := gcDone + 1) = 1 ifTrue: + [canRetry := self isExternalPrimitiveCall: newMethod]. + canRetry ifTrue: + [gcDone = 1 ifTrue: + [objectMemory scavengingGC]. + gcDone = 2 ifTrue: + [objectMemory fullGC]. + retry := gcDone <= 2]] + ifFalse: + [followDone ifFalse: + [followDone := true. + retry := self checkForAndFollowForwardedPrimitiveState]]. + retry] whileTrue: + [self assert: primFailCode ~= 0. + retried := true. + self initPrimCall. + self cCode: [] inSmalltalk: + [self maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable]. + self dispatchFunctionPointer: primitiveFunctionPointer]. + ^retried! Item was changed: ----- Method: StackInterpreter>>slowPrimitiveResponse (in category 'primitive support') ----- slowPrimitiveResponse "Invoke a normal (non-quick) primitive. Called under the assumption that primFunctionPointer has been preloaded." | nArgs savedFramePointer savedStackPointer | self assert: (objectMemory isOopForwarded: (self stackValue: argumentCount)) not. self assert: objectMemory remapBufferCount = 0. FailImbalancedPrimitives ifTrue: [nArgs := argumentCount. savedStackPointer := stackPointer. savedFramePointer := framePointer]. self initPrimCall. self dispatchFunctionPointer: primitiveFunctionPointer. self assert: (self maybeLeakCheckExternalPrimCall: newMethod). + self maybeRetryPrimitiveOnFailure. - self maybeRetryFailureDueToForwarding. self maybeFailForLastObjectOverwrite. (FailImbalancedPrimitives and: [self successful and: [framePointer = savedFramePointer and: [(self isMachineCodeFrame: framePointer) not]]]) ifTrue:"Don't fail if primitive has done something radical, e.g. perform:" [stackPointer ~= (savedStackPointer + (nArgs * objectMemory wordSize)) ifTrue: [self flag: 'Would be nice to make this a message send of e.g. unbalancedPrimitive to the current process or context'. "This is necessary but insufficient; the result may still have been written to the stack. At least we'll know something is wrong." stackPointer := savedStackPointer. self failUnbalancedPrimitive]]. "If we are profiling, take accurate primitive measures" nextProfileTick > 0 ifTrue: [self checkProfileTick: newMethod]. ^self successful! Item was changed: ----- Method: StackInterpreterPrimitives>>primitiveDoNamedPrimitiveWithArgs (in category 'plugin primitives') ----- primitiveDoNamedPrimitiveWithArgs "Simulate an primitiveExternalCall invocation (e.g. for the Debugger). Do not cache anything. e.g. ContextPart>>tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments" | argumentArray arraySize methodArg methodHeader moduleName functionName moduleLength functionLength spec addr primRcvr isArray | argumentArray := self stackTop. methodArg := self stackValue: 2. ((objectMemory isArray: argumentArray) and: [objectMemory isOopCompiledMethod: methodArg]) ifFalse: [^self primitiveFailFor: -2]. "invalid args" arraySize := objectMemory numSlotsOf: argumentArray. (self roomToPushNArgs: arraySize) ifFalse: [^self primitiveFailFor: -2]. "invalid args" methodHeader := objectMemory methodHeaderOf: methodArg. (objectMemory literalCountOfMethodHeader: methodHeader) > 2 ifFalse: [^self primitiveFailFor: -3]. "invalid methodArg state" spec := objectMemory fetchPointer: 1 "first literal" ofObject: methodArg. isArray := self isInstanceOfClassArray: spec. (isArray and: [(objectMemory numSlotsOf: spec) = 4 and: [(self primitiveIndexOfMethod: methodArg header: methodHeader) = PrimNumberExternalCall]]) ifFalse: [^self primitiveFailFor: -3]. "invalid methodArg state" (self argumentCountOfMethodHeader: methodHeader) = arraySize ifFalse: [^self primitiveFailFor: -2]. "invalid args (Array args wrong size)" "The function has not been loaded yet. Fetch module and function name." moduleName := objectMemory fetchPointer: 0 ofObject: spec. moduleName = objectMemory nilObject ifTrue: [moduleLength := 0] ifFalse: [self success: (objectMemory isBytes: moduleName). moduleLength := objectMemory lengthOf: moduleName. self cCode: '' inSmalltalk: [ (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: (self stringOf: moduleName)) "??" ifTrue: [moduleLength := 0 "Cause all of these to fail"]]]. functionName := objectMemory fetchPointer: 1 ofObject: spec. self success: (objectMemory isBytes: functionName). functionLength := objectMemory lengthOf: functionName. self successful ifFalse: [^self primitiveFailFor: -3]. "invalid methodArg state" addr := self ioLoadExternalFunction: functionName + objectMemory baseHeaderSize OfLength: functionLength FromModule: moduleName + objectMemory baseHeaderSize OfLength: moduleLength. addr = 0 ifTrue: [^self primitiveFailFor: -1]. "could not find function; answer generic failure (see below)" "Cannot fail this primitive from now on. Can only fail the external primitive." tempOop := objectMemory eeInstantiateClassIndex: ClassArrayCompactIndex format: objectMemory arrayFormat numSlots: (objectMemory hasSpurMemoryManagerAPI ifTrue: [5] ifFalse: [4]). objectMemory storePointerUnchecked: 0 ofObject: tempOop withValue: (argumentArray := self popStack); storePointerUnchecked: 1 ofObject: tempOop withValue: (primRcvr := self popStack); storePointerUnchecked: 2 ofObject: tempOop withValue: self popStack; "the method" storePointerUnchecked: 3 ofObject: tempOop withValue: self popStack. "the context receiver" self push: primRcvr. "replace context receiver with actual receiver" argumentCount := arraySize. 1 to: arraySize do: [:index| self push: (objectMemory fetchPointer: index - 1 ofObject: argumentArray)]. objectMemory hasSpurMemoryManagerAPI ifTrue: [objectMemory storePointerUnchecked: 4 ofObject: tempOop withValue: newMethod. newMethod := methodArg. self callExternalPrimitive: addr. "On Spur, sets primitiveFunctionPointer" + self maybeRetryPrimitiveOnFailure. - self maybeRetryFailureDueToForwarding. newMethod := objectMemory fetchPointer: 4 ofObject: tempOop] ifFalse: [self callExternalPrimitive: addr]. self successful ifFalse: "If primitive failed, then restore state for failure code" [self pop: arraySize + 1. self push: (objectMemory fetchPointer: 3 ofObject: tempOop). self push: (objectMemory fetchPointer: 2 ofObject: tempOop). self push: (objectMemory fetchPointer: 1 ofObject: tempOop). self push: (objectMemory fetchPointer: 0 ofObject: tempOop). argumentCount := 3. "Must reset primitiveFunctionPointer for checkForAndFollowForwardedPrimitiveState" objectMemory hasSpurMemoryManagerAPI ifTrue: [primitiveFunctionPointer := #primitiveDoNamedPrimitiveWithArgs]. "Hack. A nil prim error code (primErrorCode = 1) is interpreted by the image as meaning this primitive is not implemented. So to pass back nil as an error code we use -1 to indicate generic failure." primFailCode = 1 ifTrue: [primFailCode := -1]]! Item was changed: ----- Method: StackInterpreterPrimitives>>primitiveExternalCall (in category 'plugin primitives') ----- primitiveExternalCall "Call an external primitive. External primitive methods first literals are an array of * The module name (String | Symbol) * The function name (String | Symbol) * The session ID (SmallInteger) [OBSOLETE], or in Spur, the accessorDepth (Integer) * The function index (Integer) in the externalPrimitiveTable For fast interpreter dispatch in subsequent invocations the primitiveFunctionPointer in the method cache is rewritten, either to the function itself, or to zero if the external function is not found. This allows for fast responses as long as the method stays in the cache. The cache rewrite relies on lastMethodCacheProbeWrite which is set in addNewMethodToCache:. Now that the VM flushes function addresses from its tables, the session ID is obsolete, but it is kept for backward compatibility. Also, a failed lookup is reported specially. If a method has been looked up and not been found, the function address is stored as -1 (i.e., the SmallInteger -1 to distinguish from 16rFFFFFFFF which may be returned from lookup), and the primitive fails with PrimErrNotFound." | lit addr moduleName functionName moduleLength functionLength accessorDepth index | "Check for it being a method for primitiveDoPrimitiveWithArgs. Fetch the first literal of the method; check its an Array of length 4. Look at the function index in case it has been loaded before" ((objectMemory isOopCompiledMethod: newMethod) and: [(objectMemory literalCountOf: newMethod) > 0 and: [lit := self literal: 0 ofMethod: newMethod. (objectMemory isArray: lit) and: [(objectMemory numSlotsOf: lit) = 4 and: [index := objectMemory fetchPointer: 3 ofObject: lit. objectMemory isIntegerObject: index]]]]) ifFalse: [^self primitiveFailFor: PrimErrBadMethod]. index := objectMemory integerValueOf: index. "Check if we have already looked up the function and failed." index < 0 ifTrue: ["Function address was not found in this session, Void the primitive function." self rewriteMethodCacheEntryForExternalPrimitiveToFunction: 0. ^self primitiveFailFor: PrimErrNotFound]. "Try to call the function directly" (index > 0 and: [index <= MaxExternalPrimitiveTableSize]) ifTrue: [addr := externalPrimitiveTable at: index - 1. addr ~= 0 ifTrue: [self rewriteMethodCacheEntryForExternalPrimitiveToFunction: (self cCode: 'addr' inSmalltalk: [1000 + index]). self callExternalPrimitive: addr. "On Spur, sets primitiveFunctionPointer" + self maybeRetryPrimitiveOnFailure. - self maybeRetryFailureDueToForwarding. ^nil]. "if we get here, then an index to the external prim was kept on the ST side although the underlying prim table was already flushed" ^self primitiveFailFor: PrimErrNamedInternal]. "Clean up session id and external primitive index" objectMemory storePointerUnchecked: 2 ofObject: lit withValue: ConstZero. objectMemory storePointerUnchecked: 3 ofObject: lit withValue: ConstZero. "The function has not been loaded yet. Fetch module and function name." moduleName := objectMemory fetchPointer: 0 ofObject: lit. moduleName = objectMemory nilObject ifTrue: [moduleLength := 0] ifFalse: [(objectMemory isBytes: moduleName) ifFalse: [self primitiveFailFor: PrimErrBadMethod]. moduleLength := objectMemory lengthOf: moduleName]. functionName := objectMemory fetchPointer: 1 ofObject: lit. (objectMemory isBytes: functionName) ifFalse: [self primitiveFailFor: PrimErrBadMethod]. functionLength := objectMemory lengthOf: functionName. "Spur needs to know the primitive's accessorDepth which is stored in the third slot of the first literal." objectMemory hasSpurMemoryManagerAPI ifTrue: [addr := self ioLoadExternalFunction: functionName + objectMemory baseHeaderSize OfLength: functionLength FromModule: moduleName + objectMemory baseHeaderSize OfLength: moduleLength AccessorDepthInto: (self addressOf: accessorDepth put: [:val| accessorDepth := val]). addr = 0 ifTrue: [index := -1] ifFalse: "add the function to the external primitive table" [index := self addToExternalPrimitiveTable: addr. objectMemory storePointerUnchecked: 2 ofObject: lit withValue: (objectMemory integerObjectOf: accessorDepth)]] ifFalse: [addr := self ioLoadExternalFunction: functionName + objectMemory baseHeaderSize OfLength: functionLength FromModule: moduleName + objectMemory baseHeaderSize OfLength: moduleLength. addr = 0 ifTrue: [index := -1] ifFalse: "add the function to the external primitive table" [index := self addToExternalPrimitiveTable: addr]]. "Store the index (or -1 if failure) back in the literal" objectMemory storePointerUnchecked: 3 ofObject: lit withValue: (objectMemory integerObjectOf: index). "If the function has been successfully loaded cache and call it" index >= 0 ifTrue: [self rewriteMethodCacheEntryForExternalPrimitiveToFunction: (self cCode: [addr] inSmalltalk: [1000 + index]). self callExternalPrimitive: addr. + self maybeRetryPrimitiveOnFailure] - self maybeRetryFailureDueToForwarding] ifFalse: "Otherwise void the primitive function and fail" [self rewriteMethodCacheEntryForExternalPrimitiveToFunction: 0. self assert: (objectMemory fetchPointer: 2 ofObject: lit) = ConstZero. self primitiveFailFor: PrimErrNotFound]! Item was added: + ----- Method: StackInterpreterSimulator>>mappedPluginEntries (in category 'plugin support') ----- + mappedPluginEntries + ^mappedPluginEntries! From btc at openinworld.com Tue Jun 7 00:30:56 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 7 00:31:18 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1881.mcz In-Reply-To: <5755d5a2.0302430a.a7a4a.22deSMTPIN_ADDED_MISSING@mx.google.com> References: <5755d5a2.0302430a.a7a4a.22deSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Tue, Jun 7, 2016 at 3:56 AM, wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1881.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.1881 > Author: eem > Time: 6 June 2016, 12:55:12.14917 pm > UUID: c51b1764-ddf8-49fc-92bd-d587b3d65101 > Ancestors: VMMaker.oscog-eem.1880 > > On Spur, handle external primitive failures answering PrimErrNoMemory by doing a scavenge and retrying and then on subsequent PrimErrNoMemory failure a full GC and then retrying. Rename maybeRetryFailureDueToForwarding to maybeRetryPrimitiveOnFailure. > > In the Cogit, change the retry mechanism so that the primitive call is made in the run-time, instead of the run-time answering whether the primitive should be retried and returning to machine code that then retries. > > In the simulator, go through the contortions to map[ back whatever primitiveFunctionPointer is to that which dispatchFunctionPointer: accepts. > > Discussion: > First, this mechanism applies only to external (plugin) primitives. Spur's core primtives are written in the expectation that image-level primitive failure code will deal with the failure and retry. This corresponds to the VisualWorks style and allows the image to implement GC policy (e.g. to favour reclamation over growth). So with the current Spur code, heavily influenced by the author's experience with VisualWorks, it would be inapproprate to retry corte primitives on being out-of-memory. The pathology is that attempts at very large allocations which will inevitably fail will cause a GC in the VM, very possibly followed by a GC from the image level primitive failure code. Whereas leaving it to the image, the image code may be intellkigent enough to spot an allocation too large to ever succeed and avoid the GC altogether. > > I'm not sure if I like this auto-retry or not. Perhaps it is a good idea and the image-level primitive failure code should be changed; there would certainly be fewer image-level methods. But that means fewer hooks for the image to implement GC policy. retryPrimitiveOnFailure which manages the retry isn't exactly simple (mapping back the primitiveFunctionPointer to something dispatchFunctionPointer: can manage isn't simple either, but that's simulation only, and so its complications carry much less weight). Is there something that can be called from the image side primitive failure code? Like... self primitiveRetry. At the moment I only guess that retrying from the primitive failure code requires an explicit call to the primitive again, but that sort of recursion would seem to grow the stack unnecessarily. > + maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable > + "In the real VM primitiveFunctionPointer is either an index (for quick primitives) > + or a proper function pointer to a primitive. In the simulator it may be a small > + index (corresponding to a quick primitive index), a symbol (corresponding to > + a function pointer) or an index into the externalPrimitiveTable, or an invalid > + address that references an evaluable in the simulatedTrampolines dictionary > + of the Cogit. The simulator expects dispatchFunctionPointer to be called with > + primitiveFunctionPointer being a symbol only for internal primitives. External > + primitives must have their funciton pointer mapped back to an index. This > + method does the mapping back from fake addresses." Thanks for that description. It nicely answers my question in another mail thread. As a newbie it was easy to assume that what the simulator sees is *exactly* what happens in-real-life, or perhaps a matter of knowing there may be simulator shortcuts but not knowing what they are. cheers -ben From commits at source.squeak.org Tue Jun 7 01:08:24 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Jun 7 01:08:24 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1882.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1882.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1882 Author: eem Time: 6 June 2016, 6:06:00.077553 pm UUID: 103fa521-565d-4a73-8a04-b2d3276217c8 Ancestors: VMMaker.oscog-eem.1881 ceCheckAndMaybeRetryPrimitive: must be marked In 1882 the "Elektromote", the world's first trolleybus started in Berlin. =============== Diff against VMMaker.oscog-eem.1881 =============== Item was changed: ----- Method: CoInterpreter>>ceCheckAndMaybeRetryPrimitive: (in category 'primitive support') ----- ceCheckAndMaybeRetryPrimitive: primIndex "Log failure and then retry if there's an accessorDepth or failure due to no memory." + | retried | cogit recordPrimTrace ifTrue: [self fastLogPrim: TracePrimitiveFailure]. retried := self retryPrimitiveOnFailure. (retried and: [cogit recordPrimTrace]) ifTrue: [self fastLogPrim: TracePrimitiveRetry]! From lewis at mail.msen.com Tue Jun 7 01:34:37 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Jun 7 01:34:39 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1881.mcz In-Reply-To: <201606061957.u56JvHtN000217@shell.msen.com> References: <201606061957.u56JvHtN000217@shell.msen.com> Message-ID: <20160607013437.GA69355@shell.msen.com> On Mon, Jun 06, 2016 at 07:56:19PM +0000, commits@source.squeak.org wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1881.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.1881 > Author: eem > Time: 6 June 2016, 12:55:12.14917 pm > UUID: c51b1764-ddf8-49fc-92bd-d587b3d65101 > Ancestors: VMMaker.oscog-eem.1880 > > On Spur, handle external primitive failures answering PrimErrNoMemory by doing a scavenge and retrying and then on subsequent PrimErrNoMemory failure a full GC and then retrying. Rename maybeRetryFailureDueToForwarding to maybeRetryPrimitiveOnFailure. > > In the Cogit, change the retry mechanism so that the primitive call is made in the run-time, instead of the run-time answering whether the primitive should be retried and returning to machine code that then retries. > > In the simulator, go through the contortions to map[ back whatever primitiveFunctionPointer is to that which dispatchFunctionPointer: accepts. > > Discussion: > First, this mechanism applies only to external (plugin) primitives. Spur's core primtives are written in the expectation that image-level primitive failure code will deal with the failure and retry. This corresponds to the VisualWorks style and allows the image to implement GC policy (e.g. to favour reclamation over growth). So with the current Spur code, heavily influenced by the author's experience with VisualWorks, it would be inapproprate to retry corte primitives on being out-of-memory. The pathology is that attempts at very large allocations which will inevitably fail will cause a GC in the VM, very possibly followed by a GC from the image level primitive failure code. Whereas leaving it to the image, the image code may be intellkigent enough to spot an allocation too large to ever succeed and avoid the GC altogether. > > I'm not sure if I like this auto-retry or not. Perhaps it is a good idea and the image-level primitive failure code should be changed; there would certainly be fewer image-level methods. But that means fewer hooks for the image to implement GC policy. retryPrimitiveOnFailure which manages the retry isn't exactly simple (mapping back the primitiveFunctionPointer to something dispatchFunctionPointer: can manage isn't simple either, but that's simulation only, and so its complications carry much less weight). > I do not have enough experience with the different strategies to provide a useful critique, but with respect to retrying for plugin primitives, I think that it does make sense to do that. Most allocations in plugin primitives are small in size, usually for allocating relatively small strings and arrays. The probability of needing a retry in one of these primitives is low, and the probability of the retry being successful is high. Having this be automatic seems like a good thing to do. In addition, some plugin primitives involve interaction with external libraries and resources, such that a primitive may not be easily restartable if it fails part way through its processing. For these primitives, we would want to attempt to handle any needed memory allocations within the primitive, without going back to the image to ask for help. It does feel a bit inconsistent to have the policies for plugin primitives and VM primitives be different, but given that the goal is to enable GC policy control from the image, it makes sense. Most primitive calls that result in a need for CG will be VM primitives (not plugin primitives) and if they can uniformly assume that the image is going to take responsibility for reacting to low space conditions, then it should be possible to put the control for this into the image and leave it out of the VM primitives. Dave From commits at source.squeak.org Tue Jun 7 02:23:40 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Jun 7 02:23:40 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1883.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1883.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1883 Author: eem Time: 6 June 2016, 7:21:31.312947 pm UUID: a87f979f-7e5b-44d1-804d-fc8403bde06d Ancestors: VMMaker.oscog-eem.1882 Slang: Fix a bad bug in type inferrence as exemplified by primitiveTimesTwoPower and its arg temporary. A variable cannot be typed in the current pass if it is first assigned the result of an as-yet-to-be-typed send. If it is assigned the result of a subsequent send then the first assignment will be ignored, possibly leading to a badly inferred type. For example in primitiveTimesTwoPower arg is assigned a few times: arg := self stackTop. ... arg := objectMemory integerValueOf: arg. ... arg := twiceMaxExponent negated ... arg := twiceMaxExponent and the type of twiceMaxExponent is #int. If arg's type is inferred from twiceMaxExponent because stackTop & integerValueOf: are as yet untyped, then it will be inferred to be #int. Whereas it should be defined as #sqInt from both stackTop & integerValueOf:, since merging #int & #sqInt yields #sqInt. Eliminate a stale var:type:. In 1883 the Adventures of Pinocchio by Carlo Collodi is first published complete in book form in Italy, Robert Louis Stevenson's children's pirate adventure novel Treasure Island is first published in book format, in London, and .oxygen is liquefied for the very first time. =============== Diff against VMMaker.oscog-eem.1882 =============== Item was changed: ----- Method: CCodeGenerator>>returnTypeOrNilForSend:in: (in category 'type inference') ----- returnTypeOrNilForSend: sendNode in: aTMethod "Answer the return type for a send. Sends of known but as-yet-untyped methods answer nil." | sel | (self anyMethodNamed: (sel := sendNode selector)) ifNotNil: [:m| + ^m returnType ifNotNil: [:type| self baseTypeForType: type]]. - ^m returnType ifNotNil: [:type| ^self baseTypeForType: type]]. ^self returnTypeForSend: sendNode in: aTMethod! Item was changed: ----- Method: CogObjectRepresentationForSpur>>maybeCompileRetryOnPrimitiveFail: (in category 'primitive generators') ----- maybeCompileRetryOnPrimitiveFail: primIndex - "If primIndex has an accessorDepth and fails, or it is external and fails with PrimErrNoMemory, call ceCheckAndMaybeRetryPrimitive if so If ceCheck.... answers true, retry the primitive." | jmp | (coInterpreter accessorDepthForPrimitiveIndex: primIndex) >= 0 ifTrue: [jmp := cogit MoveAw: coInterpreter primFailCodeAddress R: TempReg; CmpCq: 0 R: TempReg; JumpZero: 0] ifFalse: [coInterpreter primNumberExternalCall ~= primIndex ifTrue: [^0]. jmp := cogit MoveAw: coInterpreter primFailCodeAddress R: TempReg; CmpCq: PrimErrNoMemory R: TempReg; JumpNonZero: 0]. cogit compileCallFor: #ceCheckAndMaybeRetryPrimitive: numArgs: 1 arg: (cogit trampolineArgConstant: primIndex) arg: nil arg: nil arg: nil resultReg: TempReg regsToSave: cogit emptyRegisterMask. jmp jmpTarget: cogit Label. ^0! Item was changed: ----- Method: StackInterpreter>>retryPrimitiveOnFailure (in category 'primitive support') ----- retryPrimitiveOnFailure + "In Spur two cases of primitive failure are handled specially. A primitive may fail due to validation - "In Spur two cases of pirmitive failure are handled specially. A primitive may fail due to validation encountering a forwarder. On failure, check the accessorDepth for the primitive and if non-negative scan the args to the depth, following any forwarders. Retry the primitive if any are found. Hence lazily and transparently following forwarders on primtiive failure. Additionally a prmitive might fail due to an allocation failing. Retry if external primitives have failed with PrimErrNoMemory after running first the scavenger and then on a subsequent failure, the global mark-sweep collector. Hence lazily and transparently GC on memory exhaustion." + - | gcDone followDone canRetry retry retried | gcDone := 0. followDone := canRetry := retried := false. [retry := false. primFailCode = PrimErrNoMemory ifTrue: [(gcDone := gcDone + 1) = 1 ifTrue: [canRetry := self isExternalPrimitiveCall: newMethod]. canRetry ifTrue: [gcDone = 1 ifTrue: [objectMemory scavengingGC]. gcDone = 2 ifTrue: [objectMemory fullGC]. retry := gcDone <= 2]] ifFalse: [followDone ifFalse: [followDone := true. retry := self checkForAndFollowForwardedPrimitiveState]]. retry] whileTrue: [self assert: primFailCode ~= 0. retried := true. self initPrimCall. self cCode: [] inSmalltalk: [self maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable]. self dispatchFunctionPointer: primitiveFunctionPointer]. ^retried! Item was changed: ----- Method: TMethod>>addTypesFor:to:in: (in category 'type inference') ----- addTypesFor: node to: typeSet in: aCodeGen "Add the value types for the node to typeSet. Answer if any type was derived from an as-yet-untyped method, which allows us to abort inferReturnTypeFromReturnsIn: if the return type depends on a yet-to-be-typed method." | expr | expr := node. [expr isAssignment or: [expr isStmtList]] whileTrue: [expr isAssignment ifTrue: [expr := expr variable]. expr isStmtList ifTrue: [expr := expr statements last]]. expr isSend ifTrue: [(#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) includes: expr selector) ifTrue: [^expr args inject: false into: [:asYetUntyped :block| asYetUntyped | (self addTypesFor: block to: typeSet in: aCodeGen)]]. + (aCodeGen returnTypeOrNilForSend: expr in: self) - (expr typeOrNilFrom: aCodeGen in: self) ifNil: [^(aCodeGen methodNamed: expr selector) notNil and: [expr selector ~~ selector]] ifNotNil: [:type | typeSet add: type. ^false].]. expr isVariable ifTrue: [(aCodeGen typeOfVariable: expr name) ifNotNil: [:type| typeSet add: type] ifNil: [typeSet add: (expr name = 'self' ifTrue: [#void] ifFalse: [#sqInt])]]. expr isConstant ifTrue: [(expr typeOrNilFrom: aCodeGen in: self) ifNotNil: [:type | typeSet add: type]].. ^false! Item was changed: ----- Method: TMethod>>inferTypesForImplicitlyTypedVariablesIn: (in category 'type inference') ----- inferTypesForImplicitlyTypedVariablesIn: aCodeGen "infer types for untyped variables from assignments and arithmetic uses. For debugging answer a Dictionary from var to the nodes that determined types This for debugging: (self copy inferTypesForImplicitlyTypedVariablesIn: aCodeGen)" + | alreadyExplicitlyTypedOrNotToBeTyped effectiveNodes | - | alreadyExplicitlyTyped effectiveNodes | aCodeGen maybeBreakForTestToInline: selector in: self. + alreadyExplicitlyTypedOrNotToBeTyped := declarations keys asSet. - alreadyExplicitlyTyped := declarations keys asSet. effectiveNodes := Dictionary new. "this for debugging" parseTree nodesDo: [:node| | type var | "If there is something of the form i >= 0, then i should be signed, not unsigned." (node isSend and: [(locals includes: (var := node receiver variableNameOrNil)) + and: [(alreadyExplicitlyTypedOrNotToBeTyped includes: var) not "don't be fooled by inferred unsigned types" - and: [(alreadyExplicitlyTyped includes: var) not "don't be fooled by inferred unsigned types" and: [(#(<= < >= >) includes: node selector) and: [node args first isConstant and: [node args first value = 0 and: [(type := self typeFor: var in: aCodeGen) notNil and: [type first == $u]]]]]]]) ifTrue: [self declarationAt: var put: (aCodeGen signedTypeForIntegralType: type), ' ', var. effectiveNodes at: var put: { declarations at: var. node }]. "if an assignment to an untyped local of a known type, set the local's type to that type. Only observe known sends (methods in the current set) and typed local variables." (node isAssignment and: [(locals includes: (var := node variable name)) + and: [(alreadyExplicitlyTypedOrNotToBeTyped includes: var) not]]) ifTrue: "don't be fooled by previously inferred types" + [type := node expression isSend - and: [(alreadyExplicitlyTyped includes: var) not "don't be fooled by previously inferred types" - and: [(type := node expression isSend ifTrue: [aCodeGen returnTypeOrNilForSend: node expression in: self] + ifFalse: [self typeFor: node expression in: aCodeGen]. + type "If untyped, then cannot type the variable yet. A subsequent assignment may assign a subtype of what this type ends up being" + ifNil: [alreadyExplicitlyTypedOrNotToBeTyped add: var] + ifNotNil: "Merge simple types; complex types must be defined by the programmer." + [(aCodeGen isSimpleType: type) ifTrue: + [aCodeGen mergeTypeOf: var in: declarations with: type method: self. + effectiveNodes at: var put: { declarations at: var. node }, (effectiveNodes at: var ifAbsent: [#()])]]]]. - ifFalse: [self typeFor: node expression in: aCodeGen]) notNil - and: [aCodeGen isSimpleType: type]]]]) ifTrue: - [aCodeGen mergeTypeOf: var in: declarations with: type method: self. - effectiveNodes at: var put: { declarations at: var. node }, (effectiveNodes at: var ifAbsent: [#()])]]. ^effectiveNodes! Item was changed: ----- Method: TSendNode>>typeOrNilFrom:in: (in category 'type inference') ----- typeOrNilFrom: aCodeGenerator in: aTMethod + ^aCodeGenerator returnTypeOrNilForSend: self in: aTMethod! - ^aCodeGenerator returnTypeForSend: self in: aTMethod! From commits at squeakvm.org Tue Jun 7 03:03:11 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Tue Jun 7 03:03:01 2016 Subject: [Vm-dev] [commit][3738] CogVM source as per VMMaker.oscog-eem.1883 Message-ID: Revision: 3738 Author: eliot Date: 2016-06-06 20:03:08 -0700 (Mon, 06 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1883 On Spur, handle external primitive failures answering PrimErrNoMemory by doing a scavenge and retrying and then on subsequent PrimErrNoMemory failure a full GC and then retrying. Rename maybeRetryFailureDueToForwarding to maybeRetryPrimitiveOnFailure. In the Cogit, change the retry mechanism so that the primitive call is made in the run-time, instead of the run-time answering whether the primitive should be retried and returning to machine code that then retries. Discussion: First, this mechanism applies only to external (plugin) primitives. Spur's core primtives are written in the expectation that image-level primitive failure code will deal with the failure and retry. This corresponds to the VisualWorks style and allows the image to implement GC policy (e.g. to favour reclamation over growth). So with the current Spur code, heavily influenced by the author's experience with VisualWorks, it would be inapproprate to retry core primitives on being out-of-memory. The pathology is that attempts at very large allocations which will inevitably fail will cause a GC in the VM, very possibly followed by a GC from the image level primitive failure code. Whereas leaving it to the image, the image code may be intellkigent enough to spot an allocation too large to ever succeed and avoid the GC altogether. I'm not sure if I like this auto-retry or not. Perhaps it is a good idea and the image-level primitive failure code should be changed; there would certainly be fewer image-level methods. But that means fewer hooks for the image to implement GC policy. retryPrimitiveOnFailure which manages the retry isn't exactly simple. Slang: Fix a bad bug in type inferrence as exemplified by primitiveTimesTwoPower and its arg temporary. A variable cannot be typed in the current pass if it is first assigned the result of an as-yet-to-be-typed send. If it is assigned the result of a subsequent send then the first assignment will be ignored, possibly leading to a badly inferred type. For example in primitiveTimesTwoPower arg is assigned a few times: arg := self stackTop. ... arg := objectMemory integerValueOf: arg. ... arg := twiceMaxExponent negated ... arg := twiceMaxExponent and the type of twiceMaxExponent is #int. If arg's type is inferred from twiceMaxExponent because stackTop & integerValueOf: are as yet untyped, then it will be inferred to be #int. Whereas it should be defined as #sqInt from both stackTop & integerValueOf:, since merging #int & #sqInt yields #sqInt. Modified Paths: -------------- branches/Cog/nsspur64src/vm/cogit.h branches/Cog/nsspur64src/vm/cogitX64.c branches/Cog/nsspur64src/vm/cointerp.c branches/Cog/nsspur64src/vm/cointerp.h branches/Cog/nsspur64src/vm/gcc3x-cointerp.c branches/Cog/nsspursrc/vm/cogit.h branches/Cog/nsspursrc/vm/cogitARMv5.c branches/Cog/nsspursrc/vm/cogitIA32.c branches/Cog/nsspursrc/vm/cogitMIPSEL.c branches/Cog/nsspursrc/vm/cointerp.c branches/Cog/nsspursrc/vm/cointerp.h branches/Cog/nsspursrc/vm/gcc3x-cointerp.c branches/Cog/nsspurstack64src/vm/gcc3x-interp.c branches/Cog/nsspurstack64src/vm/interp.c branches/Cog/nsspurstacksrc/vm/gcc3x-interp.c branches/Cog/nsspurstacksrc/vm/interp.c branches/Cog/spur64src/vm/cogit.h branches/Cog/spur64src/vm/cogitX64.c branches/Cog/spur64src/vm/cointerp.c branches/Cog/spur64src/vm/cointerp.h branches/Cog/spur64src/vm/gcc3x-cointerp.c branches/Cog/spursistasrc/vm/cogit.h branches/Cog/spursistasrc/vm/cogitARMv5.c branches/Cog/spursistasrc/vm/cogitIA32.c branches/Cog/spursistasrc/vm/cogitMIPSEL.c branches/Cog/spursistasrc/vm/cointerp.c branches/Cog/spursistasrc/vm/cointerp.h branches/Cog/spursistasrc/vm/gcc3x-cointerp.c branches/Cog/spursrc/vm/cogit.h branches/Cog/spursrc/vm/cogitARMv5.c branches/Cog/spursrc/vm/cogitIA32.c branches/Cog/spursrc/vm/cogitMIPSEL.c branches/Cog/spursrc/vm/cointerp.c branches/Cog/spursrc/vm/cointerp.h branches/Cog/spursrc/vm/gcc3x-cointerp.c branches/Cog/spurstack64src/vm/gcc3x-interp.c branches/Cog/spurstack64src/vm/interp.c branches/Cog/spurstacksrc/vm/gcc3x-interp.c branches/Cog/spurstacksrc/vm/interp.c branches/Cog/src/plugins/B2DPlugin/B2DPlugin.c branches/Cog/src/plugins/GeniePlugin/GeniePlugin.c branches/Cog/src/plugins/JPEGReaderPlugin/JPEGReaderPlugin.c branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c branches/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c branches/Cog/src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c branches/Cog/src/plugins/ZipPlugin/ZipPlugin.c branches/Cog/src/vm/cogit.h branches/Cog/src/vm/cogitARMv5.c branches/Cog/src/vm/cogitIA32.c branches/Cog/src/vm/cogitMIPSEL.c branches/Cog/src/vm/cointerp.c branches/Cog/src/vm/cointerp.h branches/Cog/src/vm/cointerpmt.c branches/Cog/src/vm/cointerpmt.h branches/Cog/src/vm/gcc3x-cointerp.c branches/Cog/src/vm/gcc3x-cointerpmt.c branches/Cog/stacksrc/vm/gcc3x-interp.c branches/Cog/stacksrc/vm/interp.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Modified: branches/Cog/nsspur64src/vm/cogit.h =================================================================== --- branches/Cog/nsspur64src/vm/cogit.h 2016-06-06 16:47:45 UTC (rev 3737) +++ branches/Cog/nsspur64src/vm/cogit.h 2016-06-07 03:03:08 UTC (rev 3738) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f + CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d */ Modified: branches/Cog/nsspur64src/vm/cogitX64.c =================================================================== --- branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-06 16:47:45 UTC (rev 3737) +++ branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-07 03:03:08 UTC (rev 3738) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f + CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d from - StackToRegisterMappingCogit VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f + StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1877 uuid: 638b0433-98fd-4fdf-8b75-588d6c09081f " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -441,7 +441,7 @@ static usqInt NoDbgRegParms inlineCacheTagAt(AbstractInstruction * self_in_inlineCacheTagAt, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms isPCDependent(AbstractInstruction * self_in_isPCDependent); static usqInt NoDbgRegParms literal32BeforeFollowingAddress(AbstractInstruction * self_in_literal32BeforeFollowingAddress, sqInt followingAddress); -static sqInt NoDbgRegParms literalBeforeFollowingAddress(AbstractInstruction * self_in_literalBeforeFollowingAddress, sqInt followingAddress); +static void NoDbgRegParms literalBeforeFollowingAddress(AbstractInstruction * self_in_literalBeforeFollowingAddress, sqInt followingAddress); static sqInt NoDbgRegParms loadLiteralByteSize(AbstractInstruction * self_in_loadLiteralByteSize); static usqInt NoDbgRegParms sizePCDependentInstructionAt(AbstractInstruction * self_in_sizePCDependentInstructionAt, sqInt eventualAbsoluteAddress); static AbstractInstruction * NoDbgRegParms storeLiteralbeforeFollowingAddress(AbstractInstruction * self_in_storeLiteralbeforeFollowingAddress, sqInt literal, sqInt followingAddress); @@ -602,7 +602,7 @@ static AbstractInstruction * NoDbgRegParms gMoveCwR(sqInt wordConstant, sqInt reg); static AbstractInstruction * NoDbgRegParms gMoveRMwr(sqInt sourceReg, sqInt offset, sqInt baseReg); static AbstractInstruction * NoDbgRegParms gMoveRR(sqInt reg1, sqInt reg2); -static sqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); +static usqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); static sqInt NoDbgRegParms mapForperformUntilarg(CogMethod *cogMethod, sqInt (*functionSymbol)(sqInt annotation, char *mcpc, sqInt arg), sqInt arg); static sqInt NoDbgRegParms mapObjectReferencesInClosedPIC(CogMethod *cPIC); static void mapObjectReferencesInGeneratedRuntime(void); @@ -878,7 +878,7 @@ static void NoDbgRegParms markAndTraceLiteralinat(sqInt literal, CogMethod *cogMethod, sqInt *address); static void NoDbgRegParms markAndTraceUpdatedLiteralin(sqInt objOop, CogMethod *cogMethodOrNil); static void NoDbgRegParms markIfIRC(usqInt maybeIRCs); -static sqInt NoDbgRegParms maybeCompileRetryonPrimitiveFail(AbstractInstruction *retryInst, sqInt primIndex); +static sqInt NoDbgRegParms maybeCompileRetryOnPrimitiveFail(sqInt primIndex); static sqInt numCharacterBits(void); extern sqInt numRegArgs(void); static sqInt NoDbgRegParms remapObject(sqInt objOop); @@ -892,7 +892,7 @@ static SimStackEntry * NoDbgRegParms storeToReg(SimStackEntry * self_in_storeToReg, sqInt reg); static sqInt NoDbgRegParms isMergeFixup(BytecodeFixup * self_in_isMergeFixup); static sqInt NoDbgRegParms availableRegisterOrNoneFor(AbstractInstruction * self_in_availableRegisterOrNoneFor, sqInt liveRegsMask); -static sqInt NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress); +static void NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms callInstructionByteSize(AbstractInstruction * self_in_callInstructionByteSize); static sqInt NoDbgRegParms callTargetFromReturnAddress(AbstractInstruction * self_in_callTargetFromReturnAddress, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms cmpC32RTempByteSize(AbstractInstruction * self_in_cmpC32RTempByteSize); @@ -939,7 +939,7 @@ static usqInt NoDbgRegParms machineCodeAt(AbstractInstruction * self_in_machineCodeAt, sqInt anOffset); static sqInt NoDbgRegParms machineCodeBytes(AbstractInstruction * self_in_machineCodeBytes); static sqInt NoDbgRegParms modRMRO(AbstractInstruction * self_in_modRMRO, sqInt mod, sqInt regMode, sqInt regOpcode); -static sqInt NoDbgRegParms nsSendCacheAt(AbstractInstruction * self_in_nsSendCacheAt, char *callSiteReturnAddress); +static void NoDbgRegParms nsSendCacheAt(AbstractInstruction * self_in_nsSendCacheAt, char *callSiteReturnAddress); static sqInt NoDbgRegParms numIntRegArgs(AbstractInstruction * self_in_numIntRegArgs); static AbstractInstruction * NoDbgRegParms padIfPossibleWithStopsFromto(AbstractInstruction * self_in_padIfPossibleWithStopsFromto, sqInt startAddr, sqInt endAddr); static AbstractInstruction * NoDbgRegParms relocateCallBeforeReturnPCby(AbstractInstruction * self_in_relocateCallBeforeReturnPCby, sqInt retpc, sqInt delta); @@ -2360,7 +2360,7 @@ least 16rC0. */ /* CogInLineLiteralsX64Compiler>>#literalBeforeFollowingAddress: */ -static sqInt NoDbgRegParms +static void NoDbgRegParms literalBeforeFollowingAddress(AbstractInstruction * self_in_literalBeforeFollowingAddress, sqInt followingAddress) { sqInt base; @@ -2374,7 +2374,8 @@ ? 9 : 10) : 11)); - return unalignedLongAt(base); + unalignedLongAt(base); + return; } /* CogInLineLiteralsX64Compiler>>#loadLiteralByteSize */ @@ -2798,12 +2799,12 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - usqInt endbcpc; + sqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; sqInt latestContinuation; - sqInt map; + usqInt map; sqInt mapByte; usqInt mcpc1; sqInt nExts; @@ -4407,12 +4408,11 @@ AbstractInstruction *anInstruction7; sqInt callTarget; const int cStackAlignment = STACK_ALIGN_BYTES; - usqInt delta; - usqInt numRegsPushed; - sqInt quickConstant; + sqInt delta; + sqInt numRegsPushed; usqInt regMaskCopy; sqInt regsToSave; - usqInt wordsPushedModAlignment; + sqInt wordsPushedModAlignment; regsToSave = (resultRegOrNone == NoReg ? regMask @@ -4433,9 +4433,7 @@ if (wordsPushedModAlignment != 0) { delta = (cStackAlignment / BytesPerWord) - wordsPushedModAlignment; /* begin SubCq:R: */ - quickConstant = delta * BytesPerWord; - /* begin gen:quickConstant:operand: */ - anInstruction = genoperandoperand(SubCqR, quickConstant, SPReg); + anInstruction = genoperandoperand(SubCqR, delta * BytesPerWord, SPReg); } l1: /* end genAlignCStackSavingRegisters:numArgs:wordAlignment: */; } @@ -5362,9 +5360,9 @@ followForwardedLiteralsIn(CogMethod *cogMethod) { sqInt annotation; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; assert((((cogMethod->cmType)) != CMMethod) @@ -7177,10 +7175,10 @@ /* Answer the address of the null byte at the end of the method map. */ /* Cogit>>#mapEndFor: */ -static sqInt NoDbgRegParms +static usqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod) { - sqInt end; + usqInt end; end = ((((usqInt)cogMethod)) + ((cogMethod->blockSize))) - 1; while ((byteAt(end)) != MapEnd) { @@ -7198,9 +7196,9 @@ mapForperformUntilarg(CogMethod *cogMethod, sqInt (*functionSymbol)(sqInt annotation, char *mcpc, sqInt arg), sqInt arg) { sqInt annotation; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; mcpc = (0 @@ -7305,9 +7303,9 @@ sqInt freedPIC; sqInt hasYoungObj; sqInt hasYoungObjPtr; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt remappedMethod; sqInt result; sqInt val; @@ -7423,9 +7421,9 @@ { sqInt annotation; CogMethod *cogMethod; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; codeModified = 0; @@ -7503,9 +7501,9 @@ CogMethod *cogMethod; sqInt hasYoungObj; sqInt hasYoungObjPtr; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; usqInt pointer; sqInt result; sqInt val; @@ -7623,12 +7621,12 @@ sqInt annotation; sqInt annotation1; CogMethod *cogMethod; - sqInt map; - sqInt map1; + usqInt map; + usqInt map1; sqInt mapByte; sqInt mapByte1; - sqInt mcpc; - sqInt mcpc1; + usqInt mcpc; + usqInt mcpc1; sqInt result; sqInt result1; sqInt val; @@ -7783,9 +7781,9 @@ markAndTraceOrFreeCogMethodfirstVisit(CogMethod *cogMethod, sqInt firstVisit) { sqInt annotation; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; sqInt val; @@ -8111,9 +8109,9 @@ { sqInt annotation; CogMethod *cogMethod; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; assert((((aCogMethod->cmType)) == CMMethod) @@ -8239,12 +8237,12 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - usqInt endbcpc; + sqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; sqInt latestContinuation; - sqInt map; + usqInt map; sqInt mapByte; usqInt mcpc; sqInt nExts; @@ -8868,9 +8866,9 @@ { sqInt annotation; sqLong callDelta; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqLong refDelta; sqInt result; @@ -9442,9 +9440,9 @@ { sqInt annotation; CogMethod *cogMethod; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; if (!(methodZoneBase)) { @@ -9885,9 +9883,9 @@ sqInt annotation; CogMethod *cogMethod; sqInt freedPIC; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; if (!(methodZoneBase)) { @@ -9962,9 +9960,9 @@ { sqInt annotation; CogMethod *cogMethod; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt mustScanAndUnlink; sqInt result; @@ -10061,9 +10059,9 @@ { sqInt annotation; CogMethod *cogMethod; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; if (!(methodZoneBase)) { @@ -10130,9 +10128,9 @@ sqInt annotation; CogMethod *cogMethod; sqInt freedPIC; - sqInt map; + usqInt map; sqInt mapByte; - sqInt mcpc; + usqInt mcpc; sqInt result; CogMethod *targetMethod; @@ -16545,36 +16543,47 @@ } -/* If primIndex has an accessorDepth, check for primitive failure and call - ceCheckForAndFollowForwardedPrimitiveState if so If ceCheck.... answers - true, retry the primitive. */ +/* If primIndex has an accessorDepth and fails, or it is external and fails + with PrimErrNoMemory, + call ceCheckAndMaybeRetryPrimitive if so If ceCheck.... answers true, + retry the primitive. */ - /* CogObjectRepresentationForSpur>>#maybeCompileRetry:onPrimitiveFail: */ + /* CogObjectRepresentationForSpur>>#maybeCompileRetryOnPrimitiveFail: */ static sqInt NoDbgRegParms -maybeCompileRetryonPrimitiveFail(AbstractInstruction *retryInst, sqInt primIndex) +maybeCompileRetryOnPrimitiveFail(sqInt primIndex) { sqInt address; + sqInt address1; AbstractInstruction *anInstruction; AbstractInstruction *anInstruction1; AbstractInstruction *anInstruction2; + AbstractInstruction *anInstruction3; AbstractInstruction *jmp; - if ((accessorDepthForPrimitiveIndex(primIndex)) < 0) { - return 0; + if ((accessorDepthForPrimitiveIndex(primIndex)) >= 0) { + /* begin MoveAw:R: */ + address = primFailCodeAddress(); + /* begin gen:literal:operand: */ + anInstruction = genoperandoperand(MoveAwR, address, TempReg); + /* begin CmpCq:R: */ + anInstruction1 = genoperandoperand(CmpCqR, 0, TempReg); + /* begin JumpZero: */ + jmp = genConditionalBranchoperand(JumpZero, ((sqInt)0)); } - /* begin MoveAw:R: */ - address = primFailCodeAddress(); - /* begin gen:literal:operand: */ - anInstruction = genoperandoperand(MoveAwR, address, TempReg); - /* begin CmpCq:R: */ - anInstruction1 = genoperandoperand(CmpCqR, 0, TempReg); - /* begin JumpZero: */ - jmp = genConditionalBranchoperand(JumpZero, ((sqInt)0)); - compileCallFornumArgsargargargargresultRegregsToSave(ceCheckForAndFollowForwardedPrimitiveState, 0, null, null, null, null, TempReg, 0); - /* begin CmpCq:R: */ - anInstruction2 = genoperandoperand(CmpCqR, 0, TempReg); - /* begin JumpNonZero: */ - genConditionalBranchoperand(JumpNonZero, ((sqInt)retryInst)); + else { + if ((primNumberExternalCall()) != primIndex) { + return 0; + } + /* begin MoveAw:R: */ + address1 = primFailCodeAddress(); + /* begin gen:literal:operand: */ + anInstruction2 = genoperandoperand(MoveAwR, address1, TempReg); + /* begin CmpCq:R: */ + anInstruction3 = genoperandoperand(CmpCqR, PrimErrNoMemory, TempReg); + /* begin JumpNonZero: */ + jmp = genConditionalBranchoperand(JumpNonZero, ((sqInt)0)); + } + compileCallFornumArgsargargargargresultRegregsToSave(ceCheckAndMaybeRetryPrimitive, 1, trampolineArgConstant(primIndex), null, null, null, TempReg, 0); jmpTarget(jmp, gLabel()); return 0; } @@ -16898,10 +16907,12 @@ */ /* CogX64Compiler>>#callFullTargetFromReturnAddress: */ -static sqInt NoDbgRegParms +static void NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress) { - return unalignedLongAt((callSiteReturnAddress - 2) - 8); + /* begin sixtyFourBitLiteralBefore: */ + unalignedLongAt((callSiteReturnAddress - 2) - 8); + return; } /* CogX64Compiler>>#callInstructionByteSize */ @@ -20947,10 +20958,11 @@ self, super, outer, or implicit receiver send. */ /* CogX64Compiler>>#nsSendCacheAt: */ -static sqInt NoDbgRegParms +static void NoDbgRegParms nsSendCacheAt(AbstractInstruction * self_in_nsSendCacheAt, char *callSiteReturnAddress) { - return literalBeforeFollowingAddress(self_in_nsSendCacheAt, (((usqInt)callSiteReturnAddress)) - 5); + literalBeforeFollowingAddress(self_in_nsSendCacheAt, (((usqInt)callSiteReturnAddress)) - 5); + return; } /* CogX64Compiler>>#numIntRegArgs */ @@ -21471,7 +21483,6 @@ sqInt offset2; sqInt reg; sqInt retpc; - AbstractInstruction *retry; /* Save processor fp, sp and return pc in the interpreter's frame stack and instruction pointers */ @@ -21501,7 +21512,6 @@ } /* begin MoveCq:R: */ anInstruction21 = genoperandoperand(MoveCqR, 0, TempReg); - retry = anInstruction21; /* begin MoveR:Aw: */ address11 = primFailCodeAddress(); /* begin gen:operand:literal: */ @@ -21585,7 +21595,7 @@ /* begin Label */ continuePostSamplePrim = genoperandoperand(Label, (labelCounter += 1), bytecodePC); } - maybeCompileRetryonPrimitiveFail(retry, primitiveIndex); + maybeCompileRetryOnPrimitiveFail(primitiveIndex); maybeCompileAllocFillerCheck(); /* begin MoveAw:R: */ address8 = instructionPointerAddress(); @@ -23159,13 +23169,13 @@ CogBlockMethod *cogMethod1; BytecodeDescriptor *descriptor; sqInt distance; - usqInt endbcpc; + sqInt endbcpc; sqInt errCode; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; sqInt latestContinuation; - sqInt map; + usqInt map; sqInt mapByte; usqInt mcpc; sqInt nExts; Modified: branches/Cog/nsspur64src/vm/cointerp.c =================================================================== --- branches/Cog/nsspur64src/vm/cointerp.c 2016-06-06 16:47:45 UTC (rev 3737) +++ branches/Cog/nsspur64src/vm/cointerp.c 2016-06-07 03:03:08 UTC (rev 3738) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d from - CoInterpreter VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e + CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1876 uuid: 28e91d90-4197-436d-9702-7c7dae02e85e " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -447,7 +447,7 @@ extern sqInt ceCannotAssignTowithIndexvalueToAssign(sqInt immutableObject, sqInt index, sqInt valueToAssign); #endif /* IMMUTABILITY */ extern sqInt ceCannotResume(void); -extern sqInt ceCheckForAndFollowForwardedPrimitiveState(void); +extern void ceCheckAndMaybeRetryPrimitive(sqInt primIndex); extern void ceCheckForInterrupts(void); extern void ceCheckProfileTick(void); extern sqInt ceContextinstVar(sqInt maybeContext, sqInt slotIndex); @@ -471,7 +471,6 @@ extern void ceTraceStoreOfinto(sqInt aValue, sqInt anObject); extern void checkAssertsEnabledInCoInterpreter(void); static sqInt NoDbgRegParms checkCodeIntegrity(sqInt gcModes); -static sqInt checkForAndFollowForwardedPrimitiveState(void); static sqInt checkLogIntegrity(void); static sqInt NoDbgRegParms checkOkayFields(sqInt oop); static sqInt checkStackIntegrity(void); @@ -1254,7 +1253,7 @@ extern void tenuringIncrementalGC(void); static sqInt NoDbgRegParms topOfObjStack(sqInt objStack); extern sqInt topRemappableOop(void); -static usqInt totalFreeListBytes(void); +static sqInt totalFreeListBytes(void); extern sqInt trueObject(void); static void NoDbgRegParms unlinkSolitaryFreeTreeNode(sqInt freeTreeNode); extern sqInt unpinObject(sqInt objOop); @@ -1517,6 +1516,7 @@ extern sqInt readableFormat(sqInt imageVersion); EXPORT(sqInt) reestablishContextPriorToCallback(sqInt callbackContext); static sqInt NoDbgRegParms removeFirstLinkOfList(sqInt aList); +static sqInt retryPrimitiveOnFailure(void); EXPORT(sqInt) returnAsThroughCallbackContext(sqInt returnTypeOop, VMCallbackContext *vmCallbackContext, sqInt callbackMethodContext); static sqInt NoDbgRegParms reverseDisplayFromto(sqInt startIndex, sqInt endIndex); static sqInt NoDbgRegParms safeMethodClassOf(sqInt methodPointer); @@ -1651,10 +1651,10 @@ _iss sqInt classTableFirstPage; _iss sqInt traceLogIndex; _iss sqInt * freeLists; +_iss unsigned char primTraceLogIndex; _iss usqInt scavengeThreshold; _iss char * stackLimit; _iss sqInt lkupClass; -_iss unsigned char primTraceLogIndex; _iss sqInt rememberedSetSize; _iss sqInt * rememberedSet; _iss sqInt localAbsentReceiverOrZero; @@ -2452,7 +2452,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1876"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1883"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -2486,6 +2486,7 @@ compilationBreakpointFor(sel); \ } \ } while (0) +#define primNumberExternalCall() 117 #define primTraceLogIndex(aValue) (GIV(primTraceLogIndex) = (aValue)) #define setDesiredCogCodeSize(dccs) (desiredCogCodeSize = (dccs)) #define pageIndexForstackBasePlus1bytesPerPage(pointer,stkBasePlus1,pageByteSize) (((char *)(pointer) - (stkBasePlus1)) / (pageByteSize)) @@ -5959,12 +5960,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -6074,11 +6072,11 @@ table = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (((long)PrimErrTableIndex) << (shiftForWord()))); if (GIV(primFailCode) <= (numSlotsOf(table))) { errorCode = longAt((table + BaseHeaderSize) + (((long)(GIV(primFailCode) - 1)) << (shiftForWord()))); - goto l446; + goto l442; } } errorCode = ((GIV(primFailCode) << 3) | 1); - l446: /* end getErrorObjectFromPrimFailCode */; + l442: /* end getErrorObjectFromPrimFailCode */; longAtPointerput(localSP, errorCode); } GIV(primFailCode) = 0; @@ -12929,25 +12927,25 @@ if (localPrimIndex >= 264) { /* begin internalStackTopPut: */ longAtPointerput(localSP, longAt(((longAtPointer(localSP)) + BaseHeaderSize) + (((long)(localPrimIndex - 264)) << (shiftForWord())))); - goto l463; + goto l474; } if (localPrimIndex == 256) { - goto l463; + goto l474; } if (localPrimIndex == 257) { longAtPointerput(localSP, GIV(trueObj)); - goto l463; + goto l474; } if (localPrimIndex == 258) { longAtPointerput(localSP, GIV(falseObj)); - goto l463; + goto l474; } if (localPrimIndex == 259) { longAtPointerput(localSP, GIV(nilObj)); - goto l463; + goto l474; } longAtPointerput(localSP, (((localPrimIndex - 261) << 3) | 1)); - l463: /* end internalQuickPrimitiveResponse */; + l474: /* end internalQuickPrimitiveResponse */; goto l464; } /* begin externalizeIPandSP */ @@ -12971,12 +12969,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -13086,11 +13081,11 @@ table = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (((long)PrimErrTableIndex) << (shiftForWord()))); if (GIV(primFailCode) <= (numSlotsOf(table))) { errorCode = longAt((table + BaseHeaderSize) + (((long)(GIV(primFailCode) - 1)) << (shiftForWord()))); - goto l475; + goto l469; } } errorCode = ((GIV(primFailCode) << 3) | 1); - l475: /* end getErrorObjectFromPrimFailCode */; + l469: /* end getErrorObjectFromPrimFailCode */; longAtPointerput(localSP, errorCode); } GIV(primFailCode) = 0; @@ -13292,25 +13287,25 @@ if (localPrimIndex >= 264) { /* begin internalStackTopPut: */ longAtPointerput(localSP, longAt(((longAtPointer(localSP)) + BaseHeaderSize) + (((long)(localPrimIndex - 264)) << (shiftForWord())))); - goto l480; + goto l486; } if (localPrimIndex == 256) { - goto l480; + goto l486; } if (localPrimIndex == 257) { longAtPointerput(localSP, GIV(trueObj)); - goto l480; + goto l486; } if (localPrimIndex == 258) { longAtPointerput(localSP, GIV(falseObj)); - goto l480; + goto l486; } if (localPrimIndex == 259) { longAtPointerput(localSP, GIV(nilObj)); - goto l480; + goto l486; } longAtPointerput(localSP, (((localPrimIndex - 261) << 3) | 1)); - l480: /* end internalQuickPrimitiveResponse */; + l486: /* end internalQuickPrimitiveResponse */; goto l481; } /* begin externalizeIPandSP */ @@ -13334,12 +13329,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -13449,11 +13441,11 @@ table = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (((long)PrimErrTableIndex) << (shiftForWord()))); if (GIV(primFailCode) <= (numSlotsOf(table))) { errorCode = longAt((table + BaseHeaderSize) + (((long)(GIV(primFailCode) - 1)) << (shiftForWord()))); - goto l487; + goto l484; } } errorCode = ((GIV(primFailCode) << 3) | 1); - l487: /* end getErrorObjectFromPrimFailCode */; + l484: /* end getErrorObjectFromPrimFailCode */; longAtPointerput(localSP, errorCode); } GIV(primFailCode) = 0; @@ -13761,25 +13753,25 @@ if (localPrimIndex >= 264) { /* begin internalStackTopPut: */ longAtPointerput(localSP, longAt(((longAtPointer(localSP)) + BaseHeaderSize) + (((long)(localPrimIndex - 264)) << (shiftForWord())))); - goto l374; + goto l380; } if (localPrimIndex == 256) { - goto l374; + goto l380; } if (localPrimIndex == 257) { longAtPointerput(localSP, GIV(trueObj)); - goto l374; + goto l380; } if (localPrimIndex == 258) { longAtPointerput(localSP, GIV(falseObj)); - goto l374; + goto l380; } if (localPrimIndex == 259) { longAtPointerput(localSP, GIV(nilObj)); - goto l374; + goto l380; } longAtPointerput(localSP, (((localPrimIndex - 261) << 3) | 1)); - l374: /* end internalQuickPrimitiveResponse */; + l380: /* end internalQuickPrimitiveResponse */; goto l382; } /* begin externalizeIPandSP */ @@ -13803,12 +13795,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -13918,11 +13907,11 @@ table = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (((long)PrimErrTableIndex) << (shiftForWord()))); if (GIV(primFailCode) <= (numSlotsOf(table))) { errorCode = longAt((table + BaseHeaderSize) + (((long)(GIV(primFailCode) - 1)) << (shiftForWord()))); - goto l381; + goto l378; } } errorCode = ((GIV(primFailCode) << 3) | 1); - l381: /* end getErrorObjectFromPrimFailCode */; + l378: /* end getErrorObjectFromPrimFailCode */; longAtPointerput(localSP, errorCode); } GIV(primFailCode) = 0; @@ -14232,25 +14221,25 @@ if (localPrimIndex >= 264) { /* begin internalStackTopPut: */ longAtPointerput(localSP, longAt(((longAtPointer(localSP)) + BaseHeaderSize) + (((long)(localPrimIndex - 264)) << (shiftForWord())))); - goto l399; + goto l405; } if (localPrimIndex == 256) { - goto l399; + goto l405; } if (localPrimIndex == 257) { longAtPointerput(localSP, GIV(trueObj)); - goto l399; + goto l405; } if (localPrimIndex == 258) { longAtPointerput(localSP, GIV(falseObj)); - goto l399; + goto l405; } if (localPrimIndex == 259) { longAtPointerput(localSP, GIV(nilObj)); - goto l399; + goto l405; } longAtPointerput(localSP, (((localPrimIndex - 261) << 3) | 1)); - l399: /* end internalQuickPrimitiveResponse */; + l405: /* end internalQuickPrimitiveResponse */; goto l407; } /* begin externalizeIPandSP */ @@ -14274,12 +14263,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -14389,11 +14375,11 @@ table = longAt((GIV(specialObjectsOop) + BaseHeaderSize) + (((long)PrimErrTableIndex) << (shiftForWord()))); if (GIV(primFailCode) <= (numSlotsOf(table))) { errorCode = longAt((table + BaseHeaderSize) + (((long)(GIV(primFailCode) - 1)) << (shiftForWord()))); - goto l406; + goto l403; } } errorCode = ((GIV(primFailCode) << 3) | 1); - l406: /* end getErrorObjectFromPrimFailCode */; + l403: /* end getErrorObjectFromPrimFailCode */; longAtPointerput(localSP, errorCode); } GIV(primFailCode) = 0; @@ -15477,19 +15463,16 @@ assert(GIV(primFailCode) != 0); assert(GIV(newMethod) == aPrimitiveMethod); - if (checkForAndFollowForwardedPrimitiveState()) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); - if (!GIV(primFailCode)) { - result = longAt(GIV(stackPointer)); - longAtPointerput(GIV(stackPointer), GIV(instructionPointer)); - /* begin push: */ - longAtput((sp = GIV(stackPointer) - BytesPerWord), result); - GIV(stackPointer) = sp; - ceEnterCogCodePopReceiverReg(); - } + retryPrimitiveOnFailure(); + if (!GIV(primFailCode)) { + result = longAt(GIV(stackPointer)); + longAtPointerput(GIV(stackPointer), GIV(instructionPointer)); + /* begin push: */ + longAtput((sp = GIV(stackPointer) - BytesPerWord), result); + GIV(stackPointer) = sp; + ceEnterCogCodePopReceiverReg(); } + methodHeader = longAt((aPrimitiveMethod + BaseHeaderSize) + (((long)HeaderIndex) << (shiftForWord()))); if (isCogMethodReference(methodHeader)) { activateCoggedNewMethod(0); @@ -15718,16 +15701,28 @@ } -/* In Spur a primitive may fail due to encountering a forwarder. - On failure check the accessorDepth for the primitive and - if non-negative scan the args to the depth, following any - forwarders. Answer if any are found so the prim can be retried. */ +/* Log failure and then retry if there's an accessorDepth or failure due to + no memory. + */ - /* CoInterpreter>>#ceCheckForAndFollowForwardedPrimitiveState */ -sqInt -ceCheckForAndFollowForwardedPrimitiveState(void) -{ - return checkForAndFollowForwardedPrimitiveState(); + /* CoInterpreter>>#ceCheckAndMaybeRetryPrimitive: */ +void +ceCheckAndMaybeRetryPrimitive(sqInt primIndex) +{ DECL_MAYBE_SQ_GLOBAL_STRUCT + sqInt retried; + + if (recordPrimTrace()) { + /* begin fastLogPrim: */ + GIV(primTraceLog)[GIV(primTraceLogIndex)] = TracePrimitiveFailure; + primTraceLogIndex(GIV(primTraceLogIndex) + 1); + } + retried = retryPrimitiveOnFailure(); + if (retried + && (recordPrimTrace())) { + /* begin fastLogPrim: */ + GIV(primTraceLog)[GIV(primTraceLogIndex)] = TracePrimitiveRetry; + primTraceLogIndex(GIV(primTraceLogIndex) + 1); + } } /* CoInterpreter>>#ceCheckForInterrupts */ @@ -17483,117 +17478,6 @@ } -/* In Spur a primitive may fail due to encountering a forwarder. On failure, - check the accessorDepth for the primitive and if non-negative scan the - args to the depth, following any forwarders. Answer if any are found so - the prim can be retried. The primitive index is derived from newMethod. - If the primitive is 118, then primitiveDoPrimitiveWithArgs sets newMethod - to a SmallInteger whose value is the primitive it is evaluating. */ -/* Override to log */ - - /* CoInterpreter>>#checkForAndFollowForwardedPrimitiveState */ -static sqInt -checkForAndFollowForwardedPrimitiveState(void) -{ DECL_MAYBE_SQ_GLOBAL_STRUCT - signed char accessorDepth; - sqInt firstBytecode; - sqInt found; - sqInt found1; - sqInt header; - sqInt index; - sqInt methodHeader; - sqInt oop; - sqInt primIndex; - sqInt referent; - sqInt scannedStackFrame; - - if (recordPrimTrace()) { - /* begin fastLogPrim: */ - GIV(primTraceLog)[GIV(primTraceLogIndex)] = TracePrimitiveFailure; - primTraceLogIndex(GIV(primTraceLogIndex) + 1); - } - assert(failed()); - found1 = (scannedStackFrame = 0); - if ((((GIV(newMethod)) & 7) == 1)) { - primIndex = (GIV(newMethod) >> 3); - } - else { - assert(GIV(argumentCount) == (argumentCountOf(GIV(newMethod)))); - /* begin primitiveIndexOfMethod:header: */ - assert(isCompiledMethod(GIV(newMethod))); - header = longAt((GIV(newMethod) + BaseHeaderSize) + (((long)HeaderIndex) << (shiftForWord()))); - if ((((header) & 7) == 1)) { - methodHeader = header; - } - else { - assert((((usqInt)header)) < GIV(newSpaceStart)); - assert((((((CogMethod *) header))->objectHeader)) == (nullHeaderForMachineCodeMethod())); - methodHeader = ((((CogMethod *) header))->methodHeader); - } - if (methodHeader & AlternateHeaderHasPrimFlag) { - firstBytecode = (GIV(newMethod) + ((LiteralStart + (((methodHeader >> 3)) & AlternateHeaderNumLiteralsMask)) * BytesPerOop)) + BaseHeaderSize; - primIndex = (byteAt(firstBytecode + 1)) + (((long)(byteAt(firstBytecode + 2))) << 8); - } - else { - primIndex = 0; - } - - } - - /* For the method-executing primitives, failure could have been in those primitives or the - primitives of the methods they execute. Find out which failed by seeing what is in effect. */ - accessorDepth = primitiveAccessorDepthTable[primIndex]; - if (((primIndex == PrimNumberExternalCall) - && (primitiveFunctionPointer != primitiveExternalCall)) - || ((primIndex == PrimNumberDoExternalCall) - && (primitiveFunctionPointer != primitiveDoNamedPrimitiveWithArgs))) { - accessorDepth = ((fetchPointerofObject(2, longAt((GIV(newMethod) + BaseHeaderSize) + (((long)(0 + LiteralStart)) << (shiftForWord()))))) >> 3); - } - else { - assert(saneFunctionPointerForFailureOfPrimIndex(primIndex)); - } - assert(((accessorDepth >= -1) && (accessorDepth <= 4))); - if (accessorDepth >= 0) { - for (index = 0; index <= GIV(argumentCount); index += 1) { - oop = longAt(GIV(stackPointer) + (index * BytesPerWord)); - if ((oop & (tagMask())) == 0) { - if (((longAt(oop)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))) == 0) { - assert(index < GIV(argumentCount)); - found1 = 1; - /* begin followForwarded: */ - assert(isUnambiguouslyForwarder(oop)); - referent = longAt((oop + BaseHeaderSize) + (0LL << (shiftForWord()))); - while (((referent & (tagMask())) == 0) - && (((longAt(referent)) & (classIndexMask())) == (isForwardedObjectClassIndexPun()))) { - referent = longAt((referent + BaseHeaderSize) + (0LL << (shiftForWord()))); - } - oop = referent; - longAtput(GIV(stackPointer) + (index * BytesPerWord), oop); - if (!scannedStackFrame) { - scannedStackFrame = 1; - followForwardedFrameContentsstackPointer(GIV(framePointer), GIV(stackPointer) + ((GIV(argumentCount) + 1) * BytesPerWord)); - } - } - if ((accessorDepth > 0) - && ((((oop & (tagMask())) == 0) - && (isAnyPointerFormat((((usqInt) (longAt(oop))) >> (formatShift())) & (formatMask())))) - && (followForwardedObjectFieldstoDepth(oop, accessorDepth)))) { - found1 = 1; - } - } - } - } - found = found1; - if (found - && (recordPrimTrace())) { - /* begin fastLogPrim: */ - GIV(primTraceLog)[GIV(primTraceLogIndex)] = TracePrimitiveRetry; - primTraceLogIndex(GIV(primTraceLogIndex) + 1); - } - return found; -} - - /* Check the log for leaks. The trace log is a circular buffer of pairs of entries. If there is an entry at traceLogIndex - 3 \\ TraceBufferSize it has entries. If @@ -19341,12 +19225,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -20327,8 +20208,8 @@ sqInt objToScan; sqInt objToScan1; sqInt remainder; - int scanLargeObject; - int scanLargeObject1; + sqInt scanLargeObject; + sqInt scanLargeObject1; sqInt selector; sqInt sp; sqInt sp1; @@ -20932,11 +20813,11 @@ sqInt oop; sqInt referent; sqInt referent1; - int scanLargeObject; - int scanLargeObject1; - int scanLargeObject2; - int scanLargeObject3; - int scanLargeObject4; + sqInt scanLargeObject; + sqInt scanLargeObject1; + sqInt scanLargeObject2; + sqInt scanLargeObject3; + sqInt scanLargeObject4; sqInt sp; sqInt sp1; sqInt sp2; @@ -22299,8 +22180,8 @@ sqInt objToScan1; sqInt oop; sqInt remainder; - int scanLargeObject; - int scanLargeObject1; + sqInt scanLargeObject; + sqInt scanLargeObject1; sqInt sp; sqInt sp1; @@ -25454,12 +25335,9 @@ GIV(primFailCode) = 0; dispatchFunctionPointer(primitiveFunctionPointer); assert(maybeLeakCheckExternalPrimCall(GIV(newMethod))); - /* begin maybeRetryFailureDueToForwarding */ - if (GIV(primFailCode) - && (checkForAndFollowForwardedPrimitiveState())) { - /* begin initPrimCall */ - GIV(primFailCode) = 0; - dispatchFunctionPointer(primitiveFunctionPointer); + /* begin maybeRetryPrimitiveOnFailure */ + if (GIV(primFailCode)) { + retryPrimitiveOnFailure(); } /* begin maybeFailForLastObjectOverwrite */ if (checkAllocFiller) { @@ -26839,7 +26717,7 @@ { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt alreadyCogged; CogMethod *cogMethod; - int flags; + sqInt flags; sqInt methodHeader; char *sp; @@ -40930,7 +40808,7 @@ sqInt oopRcvr; sqInt oopResult; usqLong result; - int resultIsNegative; + sqInt resultIsNegative; char *sp; oopArg = longAt(GIV(stackPointer) + (0 * BytesPerWord)); @@ -42732,7 +42610,7 @@ sqInt fmt; usqInt instBytes; sqInt instFormat; - usqInt newFormat; + sqInt newFormat; sqInt normalizedInstFormat; usqInt numBytes; usqInt numSlots; @@ -44368,7 +44246,7 @@ sqInt key; sqInt key1; sqInt listOffset; - usqInt oldCorpse; + sqInt oldCorpse; sqInt oldList; sqInt referent; sqInt referrer; @@ -47001,7 +46879,7 @@ sqInt referent3; sqInt referent4; sqInt referent5; - usqInt size; + sqInt size; sqInt sp; assert(GIV(becomeEffectsFlags) == 0); @@ -48602,9 +48480,9 @@ sqInt o; usqInt objOop; sqInt objOop1; - usqInt prevFree; + sqInt prevFree; sqInt prevObj; - usqInt prevPrevFree; + sqInt prevPrevFree; sqInt prevPrevObj; sqInt slotBytes; @@ -55297,7 +55175,7 @@ sqInt objOop; sqInt objOop1; sqInt objToScan; - int scanLargeObject; + sqInt scanLargeObject; sqInt sp; numStrongSlots = 0; @@ -55609,7 +55487,7 @@ sqInt numStrongSlots; sqInt objOop1; sqInt objToScan; - int scanLargeObject; + sqInt scanLargeObject; sqInt sp; numStrongSlots = 0; @@ -55895,7 +55773,7 @@ sqInt objToScan; sqInt oop; usqInt ptr; - int scanLargeObject; + sqInt scanLargeObject; sqInt sp; numStrongSlots = 0; @@ -56447,22 +56325,22 @@ sqInt referent2; sqInt referent3; sqInt referent4; - int scanLargeObject; - int scanLargeObject1; - int scanLargeObject10; - int scanLargeObject11; - int scanLargeObject12; - int scanLargeObject2; - int scanLargeObject21; - int scanLargeObject3; - int scanLargeObject31; - int scanLargeObject4; - int scanLargeObject41; - int scanLargeObject5; - int scanLargeObject6; - int scanLargeObject7; - int scanLargeObject8; - int scanLargeObject9; + sqInt scanLargeObject; + sqInt scanLargeObject1; + sqInt scanLargeObject10; + sqInt scanLargeObject11; + sqInt scanLargeObject12; + sqInt scanLargeObject2; + sqInt scanLargeObject21; + sqInt scanLargeObject3; + sqInt scanLargeObject31; + sqInt scanLargeObject4; + sqInt scanLargeObject41; + sqInt scanLargeObject5; + sqInt scanLargeObject6; + sqInt scanLargeObject7; + sqInt scanLargeObject8; + sqInt scanLargeObject9; usqInt sizeOfUnusedEden; sqInt sp; sqInt sp1; @@ -60715,9 +60593,9 @@ sqInt oop; sqInt oop1; sqInt p; - int scanLargeObject; - int scanLargeObject1; - int scanLargeObject2; + sqInt scanLargeObject; + sqInt scanLargeObject1; + sqInt scanLargeObject2; sqInt size; sqInt sp; sqInt sp1; @@ -61624,14 +61502,14 @@ sqInt obj2; sqInt obj21; sqInt pigBytes; - usqInt prevFree; - usqInt prevFreeChunk; - usqInt prevPrevFree; + sqInt prevFree; + sqInt prevFreeChunk; + sqInt prevPrevFree; sqInt prevPrevFreeChunk; sqInt slotBytes; sqInt slotBytes1; usqInt there; - usqInt thisFreeChunk; + sqInt thisFreeChunk; sqInt usedChunk; nextNext = 0; @@ -65450,7 +65328,7 @@ { DECL_MAYBE_SQ_GLOBAL_STRUCT usqInt freeChunk; usqInt nextFree; - usqInt prevFree; + sqInt prevFree; if (!((GIV(firstFreeChunk) > 0) && (GIV(lastFreeChunk) > GIV(firstFreeChunk)))) { @@ -66939,7 +66817,7 @@ mainly by checkFreeSpace. */ /* SpurMemoryManager>>#totalFreeListBytes */ -static usqInt +static sqInt totalFreeListBytes(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT usqInt bytesInChunk; @@ -66950,7 +66828,7 @@ sqInt listNode; sqInt nextNode; sqInt smallChild; - usqInt totalFreeBytes; + sqInt totalFreeBytes; sqInt treeNode; sqInt treeNode1; @@ -67618,7 +67496,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - sqInt address; + usqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -67681,7 +67559,7 @@ sqInt limit; sqInt newEndOfMemory; sqInt next; - sqInt node; + usqInt node; usqInt numSlots; usqInt numSlots1; SpurSegmentInfo *seg; @@ -67815,8 +67693,8 @@ usqLong bridgeSpan; sqInt bytesRead; usqInt newBase; - usqInt nextSegmentSize; - usqLong oldBase; + sqInt nextSegmentSize; + sqInt oldBase; SpurSegmentInfo *segInfo; sqInt totalBytesRead; @@ -68479,7 +68357,7 @@ sqInt objOop1; sqInt objOop11; sqInt objOop2; - int ok; + sqInt ok; sqInt oop; sqInt prevObj; sqInt prevObj1; @@ -68977,7 +68855,7 @@ { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt i; sqInt iLimiT; - int ok; + sqInt ok; sqInt oop; long oopOrZero; @@ -69012,7 +68890,7 @@ { DECL_MAYBE_SQ_GLOBAL_STRUCT char *callerFP; char *frameRcvrOffset; - int ok; + sqInt ok; sqInt oop; char *theFP; char *theSP; @@ -69070,7 +68948,7 @@ checkOkayStackZone(sqInt writeBack) { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt i; - int ok; + sqInt ok; StackPage *thePage; if (writeBack) { @@ -74765,11 +74643,9 @@ { DECL_MAYBE_SQ_GLOBAL_STRUCT sqInt closureOrNil; CogMethod *cogMethod; - sqInt fieldIndex; - sqInt fieldIndex2; sqInt frameNumArgs; sqInt frameNumArgs2; - usqInt i; + sqInt i; sqInt methodFieldOrObj; usqInt numArgs; sqInt numSlots; @@ -74850,7 +74726,6 @@ longAtput((theContext + BaseHeaderSize) + (((long)ReceiverIndex) << (shiftForWord())), rcvr); for (i = 1; i <= numArgs; i += 1) { /* begin storePointerUnchecked:ofObject:withValue: */ - fieldIndex = ReceiverIndex + i; valuePointer = ((((usqInt)(longAt(theFP + FoxMethod)))) < (startOfMemory()) ? ((i - 1) < ((frameNumArgs = ((mframeCogMethod(theFP))->cmNumArgs))) ? longAt((theFP + FoxCallerSavedIP) + ((frameNumArgs - (i - 1)) * BytesPerWord)) @@ -74859,13 +74734,12 @@ ? longAt((theFP + FoxCallerSavedIP) + ((frameNumArgs2 - (i - 1)) * BytesPerWord)) : longAt(((theFP + FoxIFReceiver) - BytesPerWord) + ((frameNumArgs2 - (i - 1)) * BytesPerWord)))); assert(!(isForwarded(theContext))); - longAtput((theContext + BaseHeaderSize) + (((long)fieldIndex) << (shiftForWord())), valuePointer); + longAtput((theContext + BaseHeaderSize) + (((long)(ReceiverIndex + i)) << (shiftForWord())), valuePointer); } for (i = (numArgs + 1); i <= numStack; i += 1) { /* begin storePointerUnchecked:ofObject:withValue: */ - fieldIndex2 = ReceiverIndex + i; assert(!(isForwarded(theContext))); - longAtput((theContext + BaseHeaderSize) + (((long)fieldIndex2) << (shiftForWord())), GIV(nilObj)); + longAtput((theContext + BaseHeaderSize) + (((long)(ReceiverIndex + i)) << (shiftForWord())), GIV(nilObj)); } assert(frameHasContext(theFP)); assert((frameOfMarriedContext(theContext)) == theFP); @@ -78598,6 +78472,161 @@ } +/* In Spur two cases of primitive failure are handled specially. A primitive + may fail due to validation + encountering a forwarder. On failure, check the accessorDepth for the + primitive and if non-negative + scan the args to the depth, following any forwarders. Retry the primitive + if any are found. Hence + lazily and transparently following forwarders on primtiive failure. + Additionally a prmitive might fail + due to an allocation failing. Retry if external primitives have failed + with PrimErrNoMemory after running + first the scavenger and then on a subsequent failure, the global + mark-sweep collector. Hence lazily + and transparently GC on memory exhaustion. */ + + /* StackInterpreter>>#retryPrimitiveOnFailure */ +static sqInt +retryPrimitiveOnFailure(void) +{ DECL_MAYBE_SQ_GLOBAL_STRUCT + signed char accessorDepth; + sqInt canRetry; + sqInt firstBytecode; + sqInt followDone; + sqInt found; + sqInt found1; + sqInt gcDone; + sqInt header; + sqInt index; + sqInt methodHeader; + sqInt oop; + sqInt primIndex; + sqInt referent; + sqInt retried; + sqInt retry; + sqInt scannedStackFrame; + + gcDone = 0; + followDone = (canRetry = (retried = 0)); + while (1) { + retry = 0; + if (GIV(primFailCode) == PrimErrNoMemory) { + if (((gcDone += 1)) == 1) { + canRetry = (primitiveIndexOfMethodheader(GIV(newMethod), methodHeaderOf(GIV(newMethod)))) == PrimNumberExternalCall; + } + if (canRetry) { + if (gcDone == 1) { + /* begin scavengingGC */ + scavengingGCTenuringIf(TenureByAge); + } + if (gcDone == 2) { + fullGC(); + } + retry = gcDone <= 2; + } + } + else { + if (!followDone) { + followDone = 1; + /* begin checkForAndFollowForwardedPrimitiveState */ + if (recordPrimTrace()) { + /* begin fastLogPrim: */ + GIV(primTraceLog)[GIV(primTraceLogIndex)] = TracePrimitiveFailure; + primTraceLogIndex(GIV(primTraceLogIndex) + 1); + } + assert(failed()); + found1 = (scannedStackFrame = 0); + if ((((GIV(newMethod)) & 7) == 1)) { + primIndex = (GIV(newMethod) >> 3); + } + else { + assert(GIV(argumentCount) == (argumentCountOf(GIV(newMethod)))); + /* begin primitiveIndexOfMethod:header: */ + assert(isCompiledMethod(GIV(newMethod))); + header = longAt((GIV(newMethod) + BaseHeaderSize) + (((long)HeaderIndex) << (shiftForWord()))); + if ((((header) & 7) == 1)) { + methodHeader = header; + } + else { + assert((((usqInt)header)) < GIV(newSpaceStart)); + assert((((((CogMethod *) header))->objectHeader)) == (nullHeaderForMachineCodeMethod())); + methodHeader = ((((CogMethod *) header))->methodHeader); + } + if (methodHeader & AlternateHeaderHasPrimFlag) { + firstBytecode = (GIV(newMethod) + ((LiteralStart + (((methodHeader >> 3)) & AlternateHeaderNumLiteralsMask)) * BytesPerOop)) + BaseHeaderSize; + primIndex = (byteAt(firstBytecode + 1)) + (((long)(byteAt(firstBytecode + 2))) << 8); + } + else { + primIndex = 0; + } + + } + + /* For the method-executing primitives, failure could have been in those primitives or the + primitives of the methods they execute. Find out which failed by seeing what is in effect. */ + accessorDepth = primitiveAccessorDepthTable[primIndex]; + if (((primIndex == PrimNumberExternalCall) + && (primitiveFunctionPointer != primitiveExternalCall)) + || ((primIndex == PrimNumberDoExternalCall) + && (primitiveFunctionPointer != primitiveDoNamedPrimitiveWithArgs))) { + accessorDepth = ((fetchPointerofObject(2, longAt((GIV(newMethod) + BaseHeaderSize) + (((long)(0 + LiteralStart)) << (shiftForWord()))))) >> 3); + } + else { + assert(saneFunctionPointerForFailureOfPrimIndex(primIndex)); + } + assert(((accessorDepth >= -1) && (accessorDepth <= 4))); + if (accessorDepth >= 0) { + for (index = 0; index <= GIV(argumentCount); index += 1) { + oop = longAt(GIV(stackPointer) + (index * BytesPerWord)); + if ((oop & (tagMask())) == 0) { + if (((longAt(oop)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))) == 0) { + assert(index < GIV(argumentCount)); + found1 = 1; + /* begin followForwarded: */ + assert(isUnambiguouslyForwarder(oop)); + referent = longAt((oop + BaseHeaderSize) + (0LL << (shiftForWord()))); + while (((referent & (tagMask())) == 0) @@ Diff output truncated at 50000 characters. @@ From btc at openinworld.com Tue Jun 7 10:14:27 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 7 10:14:54 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1882.mcz In-Reply-To: <57561e8b.d852620a.3a8f.ffffde48SMTPIN_ADDED_MISSING@mx.google.com> References: <57561e8b.d852620a.3a8f.ffffde48SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Tue, Jun 7, 2016 at 9:07 AM, wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1882.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.1882 > Author: eem > Time: 6 June 2016, 6:06:00.077553 pm > UUID: 103fa521-565d-4a73-8a04-b2d3276217c8 > Ancestors: VMMaker.oscog-eem.1881 > > ceCheckAndMaybeRetryPrimitive: must be marked What is the api? i.e. what is appplication / who is its user ? Is there some way to find/generate a full list of api methods? cheers -ben From bert at freudenbergs.de Tue Jun 7 11:05:08 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Tue Jun 7 11:05:11 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: > On 04.06.2016, at 04:17, Ben Coman wrote: > > >> On Fri, Jun 3, 2016 at 3:45 PM, Ben Coman wrote: >>> >>> >>> Is their some method I can call in the Image to cause the simulator to >>> break into a debugger? I want to do this right before the end block >>> bracket, so I can trace the termination of a forked block without >>> needing to trace over the block's statements. >>> >>> cheers -ben > > On Fri, Jun 3, 2016 at 11:50 PM, Cl?ment Bera wrote: >> >> Well you can call a method with a specific selector name and use the [break selector] feature in the simulator. Alternatively you call a specific primitive and put a halt in it in the simulator. > > cool, thanks. > cheers -ben Smalltalk exitToDebugger calls primitive 114 which runs primitiveExitToDebugger which maybe the simulator should handle differently ... - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4207 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/0a74e2ee/smime.bin From bera.clement at gmail.com Tue Jun 7 11:47:38 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Tue Jun 7 11:47:59 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1882.mcz In-Reply-To: References: <57561e8b.d852620a.3a8f.ffffde48SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: are methods that can be called from outside the C file they belongs to (typically, from the JIT to interpreter, the other way around, or from internal plugins) CompiledMethod allInstances select: [:each | each hasPragmaNamed: #api ] or something like that. On Tue, Jun 7, 2016 at 12:14 PM, Ben Coman wrote: > > On Tue, Jun 7, 2016 at 9:07 AM, wrote: > > > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1882.mcz > > > > ==================== Summary ==================== > > > > Name: VMMaker.oscog-eem.1882 > > Author: eem > > Time: 6 June 2016, 6:06:00.077553 pm > > UUID: 103fa521-565d-4a73-8a04-b2d3276217c8 > > Ancestors: VMMaker.oscog-eem.1881 > > > > ceCheckAndMaybeRetryPrimitive: must be marked > > What is the api? i.e. what is appplication / who is its user ? > Is there some way to find/generate a full list of api methods? > > cheers -ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/715443e4/attachment.htm From eliot.miranda at gmail.com Tue Jun 7 16:07:04 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 7 16:07:09 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1882.mcz In-Reply-To: References: <57561e8b.d852620a.3a8f.ffffde48SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hi Ben, > On Jun 7, 2016, at 3:14 AM, Ben Coman wrote: > > >> On Tue, Jun 7, 2016 at 9:07 AM, wrote: >> >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1882.mcz >> >> ==================== Summary ==================== >> >> Name: VMMaker.oscog-eem.1882 >> Author: eem >> Time: 6 June 2016, 6:06:00.077553 pm >> UUID: 103fa521-565d-4a73-8a04-b2d3276217c8 >> Ancestors: VMMaker.oscog-eem.1881 >> >> ceCheckAndMaybeRetryPrimitive: must be marked > > What is the api? The interface between the CoInterpreter and the Cogit. The original VMMaker produced the entire core VM in one file, interp.c. I wanted to separate the core VM from the JIT, so modified VMMaker.oscog to produce cointerp.c cogit.c cointerp.h cogit.h and cogmethod.h. The pragma marks methods that should be included in either cointerp.h or cogit.h. > i.e. what is appplication / who is its user ? The CoInterpreter needs to ask the Cogit to JIT methods (cog:selector:) and to flush caches, run GC passes over machine code, map machine code pcs to bytecode pcs etc. The Cogit needs to decode methods, find the addresses of important variables, find out information on primitives (does a primitive call back, does a primitive need newMethod setting) call run-time code to look up methods, etc. > Is there some way to find/generate a full list of api methods The lists are in *src/vm/{cointerp.h,cogit.h}. Also self systemNavigation browseAllSelect: [:m| (m pragmaAt: #api) notNil] (& maybe check for #api: too?) > > cheers -ben _,,,^..^,,,_ (phone) From eliot.miranda at gmail.com Tue Jun 7 16:09:36 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 7 16:09:42 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1882.mcz In-Reply-To: References: <57561e8b.d852620a.3a8f.ffffde48SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hi Cl?ment, > On Jun 7, 2016, at 4:47 AM, Cl?ment Bera wrote: > > are methods that can be called from outside the C file they belongs to (typically, from the JIT to interpreter, the other way around, or from internal plugins) That's a different API, the one defined by the class InterpreterProxy and platforms/Cross/vm/sqVirtualMachine.[ch] Alas it is not auto generated and so must be kept in sync manually. > > CompiledMethod allInstances select: [:each | each hasPragmaNamed: #api ] > > or something like that. > > > >> On Tue, Jun 7, 2016 at 12:14 PM, Ben Coman wrote: >> >> On Tue, Jun 7, 2016 at 9:07 AM, wrote: >> > >> > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1882.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: VMMaker.oscog-eem.1882 >> > Author: eem >> > Time: 6 June 2016, 6:06:00.077553 pm >> > UUID: 103fa521-565d-4a73-8a04-b2d3276217c8 >> > Ancestors: VMMaker.oscog-eem.1881 >> > >> > ceCheckAndMaybeRetryPrimitive: must be marked >> >> What is the api? i.e. what is appplication / who is its user ? >> Is there some way to find/generate a full list of api methods? >> >> cheers -ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/fc523d68/attachment-0001.htm From eliot.miranda at gmail.com Tue Jun 7 16:26:35 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 7 16:26:42 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1881.mcz In-Reply-To: References: <5755d5a2.0302430a.a7a4a.22deSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <06BF4389-7754-495B-A04A-15295D9518A7@gmail.com> Hi Ben, > On Jun 6, 2016, at 5:30 PM, Ben Coman wrote: > > >> On Tue, Jun 7, 2016 at 3:56 AM, wrote: >> >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1881.mcz >> >> ==================== Summary ==================== >> >> Name: VMMaker.oscog-eem.1881 >> Author: eem >> Time: 6 June 2016, 12:55:12.14917 pm >> UUID: c51b1764-ddf8-49fc-92bd-d587b3d65101 >> Ancestors: VMMaker.oscog-eem.1880 >> >> On Spur, handle external primitive failures answering PrimErrNoMemory by doing a scavenge and retrying and then on subsequent PrimErrNoMemory failure a full GC and then retrying. Rename maybeRetryFailureDueToForwarding to maybeRetryPrimitiveOnFailure. >> >> In the Cogit, change the retry mechanism so that the primitive call is made in the run-time, instead of the run-time answering whether the primitive should be retried and returning to machine code that then retries. >> >> In the simulator, go through the contortions to map[ back whatever primitiveFunctionPointer is to that which dispatchFunctionPointer: accepts. >> >> Discussion: >> First, this mechanism applies only to external (plugin) primitives. Spur's core primtives are written in the expectation that image-level primitive failure code will deal with the failure and retry. This corresponds to the VisualWorks style and allows the image to implement GC policy (e.g. to favour reclamation over growth). So with the current Spur code, heavily influenced by the author's experience with VisualWorks, it would be inapproprate to retry corte primitives on being out-of-memory. The pathology is that attempts at very large allocations which will inevitably fail will cause a GC in the VM, very possibly followed by a GC from the image level primitive failure code. Whereas leaving it to the image, the image code may be intellkigent enough to spot an allocation too large to ever succeed and avoid the GC altogether. >> >> I'm not sure if I like this auto-retry or not. Perhaps it is a good idea and the image-level primitive failure code should be changed; there would certainly be fewer image-level methods. But that means fewer hooks for the image to implement GC policy. retryPrimitiveOnFailure which manages the retry isn't exactly simple (mapping back the primitiveFunctionPointer to something dispatchFunctionPointer: can manage isn't simple either, but that's simulation only, and so its complications carry much less weight). > > > Is there something that can be called from the image side primitive > failure code? Like... > self primitiveRetry. The primitive itself. Look at the pattern in new handleFailingNew and handleFailingFailingNew for example. > > At the moment I only guess that retrying from the primitive failure > code requires an explicit call to the primitive again, but that sort > of recursion would seem to grow the stack unnecessarily. It was a sequence including a conditional (eg self doPrimitive. (self failed and: [self scanAndFixForwarders]) ifTrue: [self doPrimitive]. Now it's a loop, not recursion. The loop checks for failure due to memory exhaustion, or infers it may be due to forwarding. It guarantees to call the scan for forwarders, the scavenger and the full GC once only as appropriate after a specific initial primitive invocation has failed. Read #retryPrimitiveOnFailure. >> + maybeMapPrimitiveFunctionPointerBackToSomethingEvaluable >> + "In the real VM primitiveFunctionPointer is either an index (for quick primitives) >> + or a proper function pointer to a primitive. In the simulator it may be a small >> + index (corresponding to a quick primitive index), a symbol (corresponding to >> + a function pointer) or an index into the externalPrimitiveTable, or an invalid >> + address that references an evaluable in the simulatedTrampolines dictionary >> + of the Cogit. The simulator expects dispatchFunctionPointer to be called with >> + primitiveFunctionPointer being a symbol only for internal primitives. External >> + primitives must have their funciton pointer mapped back to an index. This >> + method does the mapping back from fake addresses." > > Thanks for that description. It nicely answers my question in another > mail thread. As a newbie it was easy to assume that what the > simulator sees is *exactly* what happens in-real-life, or perhaps a > matter of knowing there may be simulator shortcuts but not knowing > what they are. yes. The main source of these is in modeling C's modulo integer arithmetic with Smalltalk's infinite precision arithmetic. But there are other hacks. I've tried to reduce them as they're the source of infidelities which make the simulator less useful. In the Cogit simulator I use no shortcuts. Instead I use illegal addresses that cause exceptions that are caught to get at Smalltalk objects such as the CoInterpreter's instance variables. Hence machine code in the simulator is identical to machine code in the JIT apart from address. I believe this has been essential in making the JIT debuggable. > > cheers -ben From timfelgentreff at gmail.com Tue Jun 7 18:13:23 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Tue Jun 7 18:13:26 2016 Subject: [Vm-dev] Migration to github status? In-Reply-To: <7D19D997-3EBD-4A60-A89C-0F548BB7A6D4@gmail.com> References: <7D19D997-3EBD-4A60-A89C-0F548BB7A6D4@gmail.com> Message-ID: Fabio and I have finished integrating the changes to move to Github with a minimal patch against the current Cog branch. All scripts and build files have been migrated and we are building VMs for Newspeak, Squeak, and Pharo in the available flavor combinations (stack, cog, sista, spur, v3) on (what we think are) the most important platforms (linux, mac, windows) and the most used architectures (x86, x86_64, ARM). The patch ist currently on github.com/timfel/squeakvm and can be rebased onto the current SVN easily. I have currently disabled uploading the build artifacts. I was thinking maybe we could still use Eliot's webspace or else Bintray, but whatever the community thinks works best. As soon as everyone is happy with it the patch, we need to find a time when we switch the SVN to read-only and I rebase the patch one last time and then we go live on OpenSmalltalk/vm Best, Tim Am 03.06.2016 15:25 schrieb "Esteban Lorenzano" : > > Hi, > > Last week (with help of Clement) I put online the 64bits image generation > for Pharo. > Our CI now is producing regularly 64bits for both: > > - Pharo 5: > https://ci.inria.fr/pharo/view/5.0/job/Pharo-5.0-Update-Step-3.1-64bits/ > - Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.1-64bits > > Now? I would like to start testing it, and for that I need to build also > PharoVM 64bits? I do not wan to reproduce all the work already done for > running 64bits in current so I?m urging you to complete the migration, so > I can start to merge my changes into the master, instead the opposite :) > > cheers, > Esteban > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/08f94a20/attachment.htm From lists at fniephaus.com Tue Jun 7 20:42:23 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Tue Jun 7 20:42:36 2016 Subject: [Vm-dev] Errors in AQMEIO.cpp/AudioQueueObject.cpp on OS X 10.9.5 Message-ID: Hi all, There seems to be a problem with the SoundPlugin when starting a recent vm on OS X 10.9.5 (see [1] and [2]). Is it possible that this it is related to [3]? [0K2016-06-07 19:34:13.465 Pharo[531:507] 19:34:13.464 ERROR: [0xa116d1a8] AQMEIO.cpp:377: _FindIOUnit: error -66680 2016-06-07 19:34:13.467 Pharo[531:507] 19:34:13.467 ERROR: [0xa116d1a8] >aq> AudioQueueObject.cpp:1590: Prime: failed (-66680); will stop (5512/0 frames) 2016-06-07 19:34:13.469 Pharo[531:507] 19:34:13.469 ERROR: [0xa116d1a8] AQMEIO.cpp:377: _FindIOUnit: error -66680 2016-06-07 19:34:13.471 Pharo[531:507] 19:34:13.470 ERROR: [0xa116d1a8] >aq> AudioQueueObject.cpp:1590: Prime: failed (-66680); will stop (33075/0 frames) Best, Fabio [1] https://github.com/hpi-swa/smalltalkCI/issues/151 [2] https://travis-ci.org/Uko/QualityAssistant/jobs/135961674#L70 [3] http://stackoverflow.com/questions/31342042/avaudiorecorder-doesnt-record-on-os-x-mavericks/31447794 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/f731d05b/attachment.htm From commits at source.squeak.org Tue Jun 7 22:09:20 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Jun 7 22:09:21 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1884.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1884.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1884 Author: eem Time: 7 June 2016, 3:06:08.369636 pm UUID: 9ed14e3a-5903-474d-92c1-ecd78e7cb932 Ancestors: VMMaker.oscog-eem.1883 Fix multiple bytecode set selection in the Spur 64-bit VM, which must use signedIntFromLong64 to test for a negative header. In 1884 the Fabian Society is founded in London, Georges-Pierre Seurat paints Bathers at Asnières, and the eight-hour workday is first proclaimed by the Federation of Organized Trades and Labor Unions in the United States. This date, called May Day or Labour Day, becomes a holiday recognized in almost every industrialized country. =============== Diff against VMMaker.oscog-eem.1883 =============== Item was changed: ----- Method: Cogit>>blockCreationBytecodeSizeForHeader: (in category 'method map') ----- blockCreationBytecodeSizeForHeader: aMethodHeader ^self cppIf: MULTIPLEBYTECODESETS ifTrue: + [(objectMemory headerIndicatesAlternateBytecodeSet: aMethodHeader) - [(coInterpreter headerIndicatesAlternateBytecodeSet: aMethodHeader) ifTrue: [AltBlockCreationBytecodeSize] ifFalse: [BlockCreationBytecodeSize]] ifFalse: [BlockCreationBytecodeSize]! Item was changed: ----- Method: Cogit>>bytecodeSetOffsetForHeader: (in category 'initialization') ----- bytecodeSetOffsetForHeader: aMethodHeader ^self cppIf: MULTIPLEBYTECODESETS ifTrue: + [(objectMemory headerIndicatesAlternateBytecodeSet: aMethodHeader) - [(coInterpreter headerIndicatesAlternateBytecodeSet: aMethodHeader) ifTrue: [256] ifFalse: [0]] ifFalse: [0]! Item was removed: - ----- Method: NewCoObjectMemory>>headerIndicatesAlternateBytecodeSet: (in category 'simulation') ----- - headerIndicatesAlternateBytecodeSet: methodHeader - "this is here only for in-image compilation" - - "A negative header selects the alternate bytecode set." - ^methodHeader signedIntFromLong < 0! Item was changed: ----- Method: NewObjectMemory>>literalCountOfMethodHeader: (in category 'memory access') ----- + literalCountOfMethodHeader: methodHeader - literalCountOfMethodHeader: header + self assert: (self isIntegerObject: methodHeader). + ^(self headerIndicatesAlternateBytecodeSet: methodHeader) + ifTrue: [coInterpreter literalCountOfAlternateHeader: methodHeader] + ifFalse: [coInterpreter literalCountOfOriginalHeader: methodHeader]! - self assert: (self isIntegerObject: header). - ^(coInterpreter headerIndicatesAlternateBytecodeSet: header) - ifTrue: [coInterpreter literalCountOfAlternateHeader: header] - ifFalse: [coInterpreter literalCountOfOriginalHeader: header]! Item was added: + ----- Method: ObjectMemory>>headerIndicatesAlternateBytecodeSet: (in category 'method access') ----- + headerIndicatesAlternateBytecodeSet: methodHeader + "A negative header selects the alternate bytecode set." + + + ^methodHeader signedIntFromLong < 0! Item was added: + ----- Method: Spur32BitMemoryManager>>headerIndicatesAlternateBytecodeSet: (in category 'method access') ----- + headerIndicatesAlternateBytecodeSet: methodHeader + "A negative header selects the alternate bytecode set." + + + ^methodHeader signedIntFromLong < 0! Item was added: + ----- Method: Spur64BitMemoryManager>>headerIndicatesAlternateBytecodeSet: (in category 'method access') ----- + headerIndicatesAlternateBytecodeSet: methodHeader + "A negative header selects the alternate bytecode set." + + + ^methodHeader signedIntFromLong64 < 0! Item was added: + ----- Method: SpurMemoryManager>>headerIndicatesAlternateBytecodeSet: (in category 'method access') ----- + headerIndicatesAlternateBytecodeSet: methodHeader + "A negative header selects the alternate bytecode set." + + + self subclassResponsibility! Item was changed: ----- Method: StackInterpreter>>encoderClassForHeader: (in category 'simulation') ----- encoderClassForHeader: headerInteger + ^Smalltalk classNamed: ((objectMemory headerIndicatesAlternateBytecodeSet: headerInteger) - ^Smalltalk classNamed: ((self headerIndicatesAlternateBytecodeSet: headerInteger) ifTrue: [AltBytecodeEncoderClassName] ifFalse: [BytecodeEncoderClassName])! Item was changed: ----- Method: StackInterpreter>>longStoreBytecodeForHeader: (in category 'compiled methods') ----- longStoreBytecodeForHeader: methodHeader "Answer the relevant long store temp bytecode, which indicates it has a primitive error code." "234 11101010 i i i i i i i i Store Temporary Variable #iiiiiiii" "129 10000001 jjkkkkkk Store (Receiver Variable, Temporary Location, Illegal, Literal Variable) [jj] #kkkkkk" ^self cppIf: MULTIPLEBYTECODESETS + ifTrue: [(objectMemory headerIndicatesAlternateBytecodeSet: methodHeader) - ifTrue: [(self headerIndicatesAlternateBytecodeSet: methodHeader) ifTrue: [AltLongStoreBytecode] ifFalse: [LongStoreBytecode]] ifFalse: [LongStoreBytecode]! Item was changed: ----- Method: StackInterpreter>>methodHeaderHasPrimitive: (in category 'compiled methods') ----- methodHeaderHasPrimitive: methodHeader "Note: We now have 10 bits of primitive index, but they are in two places for temporary backward compatibility. The time to unpack is negligible, since the derived primitive function pointer is stored in the method cache." ^objectMemory hasSpurMemoryManagerAPI ifTrue: [self alternateHeaderHasPrimitiveFlag: methodHeader] ifFalse: [MULTIPLEBYTECODESETS ifTrue: + [(objectMemory headerIndicatesAlternateBytecodeSet: methodHeader) - [(self headerIndicatesAlternateBytecodeSet: methodHeader) ifTrue: [self alternateHeaderHasPrimitiveFlag: methodHeader] ifFalse: [methodHeader anyMask: V3PrimitiveBitsMask]] ifFalse: [methodHeader anyMask: V3PrimitiveBitsMask]]! Item was changed: ----- Method: StackInterpreter>>methodUsesAlternateBytecodeSet: (in category 'internal interpreter access') ----- methodUsesAlternateBytecodeSet: aMethodObj "A negative header selects the alternate bytecode set." + ^objectMemory headerIndicatesAlternateBytecodeSet: (objectMemory methodHeaderOf: aMethodObj)! - ^self headerIndicatesAlternateBytecodeSet: (objectMemory methodHeaderOf: aMethodObj)! Item was changed: ----- Method: StackInterpreter>>primitiveIndexOfMethod:header: (in category 'compiled methods') ----- primitiveIndexOfMethod: theMethod header: methodHeader + "Note: With the Squeak V3 format we now have 10 bits of primitive index, but they are + in two places for temporary backward compatibility. The time to unpack is negligible, + since the derived primitive function pointer is stored in the method cache. With the + Spur format we assume a 3-byte CallPrimitive with a little-endian 16-bit primitive index." - "Note: With the Squeak V0 format we now have 10 bits of primitive index, but they are in - two places for temporary backward compatibility. The time to unpack is negligible, - since the derived primitive function pointer is stored in the method cache. With the new - format we assume a 3-byte CallPrimitive with a little-endian 16-bit primitive index." | firstBytecode | ^objectMemory hasSpurMemoryManagerAPI ifTrue: [(self alternateHeaderHasPrimitiveFlag: methodHeader) ifTrue: [firstBytecode := self firstBytecodeOfAlternateHeader: methodHeader method: theMethod. (objectMemory byteAt: firstBytecode + 1) + ((objectMemory byteAt: firstBytecode + 2) << 8)] ifFalse: [0]] ifFalse: [MULTIPLEBYTECODESETS ifTrue: + [(objectMemory headerIndicatesAlternateBytecodeSet: methodHeader) - [(self headerIndicatesAlternateBytecodeSet: methodHeader) ifTrue: [(self alternateHeaderHasPrimitiveFlag: methodHeader) ifTrue: [firstBytecode := self firstBytecodeOfAlternateHeader: methodHeader method: theMethod. (objectMemory byteAt: firstBytecode + 1) + ((objectMemory byteAt: firstBytecode + 2) << 8)] ifFalse: [0]] ifFalse: [| primBits | primBits := objectMemory integerValueOf: methodHeader. (primBits bitAnd: 16r1FF) + (primBits >> 19 bitAnd: 16r200)]] ifFalse: [| primBits | primBits := objectMemory integerValueOf: methodHeader. (primBits bitAnd: 16r1FF) + (primBits >> 19 bitAnd: 16r200)]]! Item was changed: ----- Method: StackInterpreter>>setMethod:methodHeader: (in category 'internal interpreter access') ----- setMethod: aMethodObj methodHeader: methodHeader "Set the method and determine the bytecode set based on the method header's sign. If MULTIPLEBYTECODESETS then a negative header selects the alternate bytecode set. Conditionalizing the code on MULTIPLEBYTECODESETS allows the header sign bit to be used for other experiments." method := aMethodObj. self assert: (objectMemory isOopCompiledMethod: method). self assert: (objectMemory methodHeaderOf: method) = methodHeader. self cppIf: MULTIPLEBYTECODESETS + ifTrue: [bytecodeSetSelector := (objectMemory headerIndicatesAlternateBytecodeSet: methodHeader) - ifTrue: [bytecodeSetSelector := (self headerIndicatesAlternateBytecodeSet: methodHeader) ifTrue: [256] ifFalse: [0]]! Item was changed: ----- Method: StackInterpreter>>sizeOfCallPrimitiveBytecode: (in category 'compiled methods') ----- sizeOfCallPrimitiveBytecode: methodHeader "Answer if the method starts with a long store temp bytecode, which indicates it has a primitive error code." "249 11111001 i i i i i i i i jjjjjjjj Call Primitive #iiiiiiii + (jjjjjjjj * 256)" ^objectMemory hasSpurMemoryManagerAPI ifTrue: [3] ifFalse: [MULTIPLEBYTECODESETS + ifTrue: [(objectMemory headerIndicatesAlternateBytecodeSet: methodHeader) - ifTrue: [(self headerIndicatesAlternateBytecodeSet: methodHeader) ifTrue: [3] ifFalse: [0]] ifFalse: [0]]! From commits at source.squeak.org Tue Jun 7 22:20:30 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Jun 7 22:20:31 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1885.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1885.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1885 Author: eem Time: 7 June 2016, 3:18:23.229051 pm UUID: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 Ancestors: VMMaker.oscog-eem.1884 Oops. Need to nuke the old method on StackInterpreter. =============== Diff against VMMaker.oscog-eem.1884 =============== Item was removed: - ----- Method: StackInterpreter>>headerIndicatesAlternateBytecodeSet: (in category 'internal interpreter access') ----- - headerIndicatesAlternateBytecodeSet: methodHeader - - - "A negative header selects the alternate bytecode set." - ^methodHeader signedIntFromLong < 0! From commits at squeakvm.org Tue Jun 7 22:35:58 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Tue Jun 7 22:35:49 2016 Subject: [Vm-dev] [commit][3739] CogVM source as per VMMaker.oscog-eem.1885 Message-ID: Revision: 3739 Author: eliot Date: 2016-06-07 15:35:56 -0700 (Tue, 07 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1885 Fix multiple bytecode set selection in the Spur 64-bit VM, which must use signedIntFromLong64 to test for a negative header. Modified Paths: -------------- branches/Cog/nsspur64src/vm/cogit.h branches/Cog/nsspur64src/vm/cogitX64.c branches/Cog/nsspur64src/vm/cointerp.c branches/Cog/nsspur64src/vm/cointerp.h branches/Cog/nsspur64src/vm/gcc3x-cointerp.c branches/Cog/nsspursrc/vm/cogit.h branches/Cog/nsspursrc/vm/cogitARMv5.c branches/Cog/nsspursrc/vm/cogitIA32.c branches/Cog/nsspursrc/vm/cogitMIPSEL.c branches/Cog/nsspursrc/vm/cointerp.c branches/Cog/nsspursrc/vm/cointerp.h branches/Cog/nsspursrc/vm/gcc3x-cointerp.c branches/Cog/nsspurstack64src/vm/gcc3x-interp.c branches/Cog/nsspurstack64src/vm/interp.c branches/Cog/nsspurstacksrc/vm/gcc3x-interp.c branches/Cog/nsspurstacksrc/vm/interp.c branches/Cog/spur64src/vm/cogit.h branches/Cog/spur64src/vm/cogitX64.c branches/Cog/spur64src/vm/cointerp.c branches/Cog/spur64src/vm/cointerp.h branches/Cog/spur64src/vm/gcc3x-cointerp.c branches/Cog/spursistasrc/vm/cogit.h branches/Cog/spursistasrc/vm/cogitARMv5.c branches/Cog/spursistasrc/vm/cogitIA32.c branches/Cog/spursistasrc/vm/cogitMIPSEL.c branches/Cog/spursistasrc/vm/cointerp.c branches/Cog/spursistasrc/vm/cointerp.h branches/Cog/spursistasrc/vm/gcc3x-cointerp.c branches/Cog/spursrc/vm/cogit.h branches/Cog/spursrc/vm/cogitARMv5.c branches/Cog/spursrc/vm/cogitIA32.c branches/Cog/spursrc/vm/cogitMIPSEL.c branches/Cog/spursrc/vm/cointerp.c branches/Cog/spursrc/vm/cointerp.h branches/Cog/spursrc/vm/gcc3x-cointerp.c branches/Cog/spurstack64src/vm/gcc3x-interp.c branches/Cog/spurstack64src/vm/interp.c branches/Cog/spurstacksrc/vm/gcc3x-interp.c branches/Cog/spurstacksrc/vm/interp.c branches/Cog/src/vm/cogit.h branches/Cog/src/vm/cogitARMv5.c branches/Cog/src/vm/cogitIA32.c branches/Cog/src/vm/cogitMIPSEL.c branches/Cog/src/vm/cointerp.c branches/Cog/src/vm/cointerp.h branches/Cog/src/vm/cointerpmt.c branches/Cog/src/vm/cointerpmt.h branches/Cog/src/vm/gcc3x-cointerp.c branches/Cog/src/vm/gcc3x-cointerpmt.c branches/Cog/stacksrc/vm/gcc3x-interp.c branches/Cog/stacksrc/vm/interp.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Modified: branches/Cog/nsspur64src/vm/cogit.h =================================================================== --- branches/Cog/nsspur64src/vm/cogit.h 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspur64src/vm/cogit.h 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ Modified: branches/Cog/nsspur64src/vm/cogitX64.c =================================================================== --- branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -602,7 +602,7 @@ static AbstractInstruction * NoDbgRegParms gMoveCwR(sqInt wordConstant, sqInt reg); static AbstractInstruction * NoDbgRegParms gMoveRMwr(sqInt sourceReg, sqInt offset, sqInt baseReg); static AbstractInstruction * NoDbgRegParms gMoveRR(sqInt reg1, sqInt reg2); -static usqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); +static sqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod); static sqInt NoDbgRegParms mapForperformUntilarg(CogMethod *cogMethod, sqInt (*functionSymbol)(sqInt annotation, char *mcpc, sqInt arg), sqInt arg); static sqInt NoDbgRegParms mapObjectReferencesInClosedPIC(CogMethod *cPIC); static void mapObjectReferencesInGeneratedRuntime(void); @@ -2799,7 +2799,7 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - sqInt endbcpc; + usqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; @@ -5954,12 +5954,12 @@ generateMapAtstart(sqInt addressOrNull, sqInt startAddress) { unsigned char annotation; - sqInt delta; + usqInt delta; sqInt i; AbstractInstruction *instruction; sqInt length; - sqInt location; - sqInt mapEntry; + usqInt location; + usqInt mapEntry; sqInt maxDelta; usqInt mcpc; @@ -7175,7 +7175,7 @@ /* Answer the address of the null byte at the end of the method map. */ /* Cogit>>#mapEndFor: */ -static usqInt NoDbgRegParms +static sqInt NoDbgRegParms mapEndFor(CogMethod *cogMethod) { usqInt end; @@ -8237,7 +8237,7 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - sqInt endbcpc; + usqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; @@ -23169,7 +23169,7 @@ CogBlockMethod *cogMethod1; BytecodeDescriptor *descriptor; sqInt distance; - sqInt endbcpc; + usqInt endbcpc; sqInt errCode; CogMethod *homeMethod; sqInt isBackwardBranch; Modified: branches/Cog/nsspur64src/vm/cointerp.c =================================================================== --- branches/Cog/nsspur64src/vm/cointerp.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspur64src/vm/cointerp.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -892,6 +892,7 @@ static sqInt NoDbgRegParms fetchLong32ofFloatObject(sqInt fieldIndex, sqInt oop); extern sqInt floatObjectOf(double aFloat); extern double floatValueOf(sqInt oop); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); static sqInt NoDbgRegParms initFreeChunkWithBytesat(usqLong numBytes, sqInt address); static void NoDbgRegParms initSegmentBridgeWithBytesat(usqLong numBytes, sqInt address); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); @@ -1383,7 +1384,6 @@ static sqInt NoDbgRegParms handleSpecialSelectorSendFaultForfpsp(sqInt obj, char *theFP, char *theSP); static void handleStackOverflow(void); static sqInt NoDbgRegParms handleStackOverflowOrEventAllowContextSwitch(sqInt mayContextSwitch); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); static sqInt NoDbgRegParms ifCurrentStackPageHasValidHeadPointers(StackPage *thePage); static usqInt NoDbgRegParms iframeMethod(char *theFP); @@ -2452,7 +2452,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1883"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1885"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -6038,7 +6038,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -6064,7 +6064,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -13047,7 +13047,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -13073,7 +13073,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -13407,7 +13407,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -13433,7 +13433,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -13873,7 +13873,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -13899,7 +13899,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -14341,7 +14341,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -14367,7 +14367,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -14753,7 +14753,7 @@ /* Store the error code if the method starts with a long store temp. No instructionPointer skip because we're heading for machine code. */ initialPC = ((GIV(newMethod) + ((LiteralStart + (literalCountOfMethodHeader(methodHeader))) * BytesPerOop)) + BaseHeaderSize) + (3); if (GIV(primFailCode) != 0) { - if ((byteAt(initialPC)) == (((((int) methodHeader)) < 0 + if ((byteAt(initialPC)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -14848,7 +14848,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -14879,7 +14879,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ GIV(instructionPointer) += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(GIV(instructionPointer) + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(GIV(instructionPointer) + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -17629,7 +17629,7 @@ sqInt i; sqInt methodField; sqInt ok; - usqInt oop; + sqInt oop; char *theFP; StackPage *thePage; char *theSP; @@ -23700,7 +23700,7 @@ usqInt index; sqInt methodField; usqInt numArgs; - usqInt numTemps; + sqInt numTemps; char *rcvrAddress; sqInt rcvrOrClosure; sqInt theMethod; @@ -24951,7 +24951,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader1); - GIV(bytecodeSetSelector) = ((((int) methodHeader1)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader1)) < 0 ? 256 : 0); @@ -24986,7 +24986,7 @@ GIV(instructionPointer) = initialIP; } if (GIV(primFailCode) != 0) { - if ((byteAt(initialIP + 1)) == (((((int) methodHeader1)) < 0 + if ((byteAt(initialIP + 1)) == (((((sqLong) methodHeader1)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -25179,7 +25179,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader1); - GIV(bytecodeSetSelector) = ((((int) methodHeader1)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader1)) < 0 ? 256 : 0); @@ -25214,7 +25214,7 @@ GIV(instructionPointer) = initialIP; } if (GIV(primFailCode) != 0) { - if ((byteAt(initialIP + 1)) == (((((int) methodHeader1)) < 0 + if ((byteAt(initialIP + 1)) == (((((sqLong) methodHeader1)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -31031,7 +31031,7 @@ GIV(method) = theMethod; assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -31288,7 +31288,7 @@ GIV(method) = theMethod; assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -31578,7 +31578,7 @@ GIV(method) = theMethod; assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -42965,6 +42965,16 @@ } +/* A negative header selects the alternate bytecode set. */ + + /* Spur64BitMemoryManager>>#headerIndicatesAlternateBytecodeSet: */ +sqInt +headerIndicatesAlternateBytecodeSet(sqInt methodHeader) +{ + return (((sqLong) methodHeader)) < 0; +} + + /* must have room for a header (single or double) plus the next free pointer */ /* Spur64BitMemoryManager>>#initFreeChunkWithBytes:at: */ @@ -67496,7 +67506,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - usqInt address; + sqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -71885,16 +71895,6 @@ } -/* A negative header selects the alternate bytecode set. */ - - /* StackInterpreter>>#headerIndicatesAlternateBytecodeSet: */ -sqInt -headerIndicatesAlternateBytecodeSet(sqInt methodHeader) -{ - return (((int) methodHeader)) < 0; -} - - /* This is a C implementation needed by ioSetMaxExtSemTableSize and e.g. stackPageByteSize. */ @@ -72872,7 +72872,7 @@ sqInt longStoreBytecodeForHeader(sqInt methodHeader) { - return ((((int) methodHeader)) < 0 + return ((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode); } @@ -74967,7 +74967,7 @@ assert((((((CogMethod *) header))->objectHeader)) == (nullHeaderForMachineCodeMethod())); methodHeader = ((((CogMethod *) header))->methodHeader); } - return (((int) methodHeader)) < 0; + return (((sqLong) methodHeader)) < 0; } @@ -75304,12 +75304,12 @@ } -/* Note: With the Squeak V0 format we now have 10 bits of primitive index, - but they are in - two places for temporary backward compatibility. The time to unpack is +/* Note: With the Squeak V3 format we now have 10 bits of primitive index, + but they are + in two places for temporary backward compatibility. The time to unpack is negligible, since the derived primitive function pointer is stored in the - method cache. With the new - format we assume a 3-byte CallPrimitive with a little-endian 16-bit + method cache. With the + Spur format we assume a 3-byte CallPrimitive with a little-endian 16-bit primitive index. */ /* StackInterpreter>>#primitiveIndexOfMethod:header: */ @@ -78490,7 +78490,7 @@ static sqInt retryPrimitiveOnFailure(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - signed char accessorDepth; + sqInt accessorDepth; sqInt canRetry; sqInt firstBytecode; sqInt followDone; @@ -79581,7 +79581,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -79616,7 +79616,7 @@ GIV(instructionPointer) = initialIP; } if (GIV(primFailCode) != 0) { - if ((byteAt(initialIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(initialIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ Modified: branches/Cog/nsspur64src/vm/cointerp.h =================================================================== --- branches/Cog/nsspur64src/vm/cointerp.h 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspur64src/vm/cointerp.h 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ @@ -132,6 +132,7 @@ extern usqInt specialObjectsArrayAddress(void); extern sqInt withoutForwardingOnandwithsendToCogit(sqInt obj1, sqInt obj2, sqInt aBool, sqInt (*selector)(sqInt,sqInt,sqInt)); extern sqInt byteSwapped(sqInt w); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); extern sqInt isIntegerValue(sqInt intValue); extern sqInt isMarked(sqInt objOop); @@ -272,7 +273,6 @@ extern void (*functionPointerForinClass(sqInt primIdx,sqInt theClass))(void) ; extern usqLong getNextWakeupUsecs(void); extern sqInt * getStackPointer(void); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); extern sqInt isFloatObject(sqInt oop); extern sqInt isKindOfInteger(sqInt oop); Modified: branches/Cog/nsspur64src/vm/gcc3x-cointerp.c =================================================================== --- branches/Cog/nsspur64src/vm/gcc3x-cointerp.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspur64src/vm/gcc3x-cointerp.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -2,11 +2,11 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -895,6 +895,7 @@ static sqInt NoDbgRegParms fetchLong32ofFloatObject(sqInt fieldIndex, sqInt oop); extern sqInt floatObjectOf(double aFloat); extern double floatValueOf(sqInt oop); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); static sqInt NoDbgRegParms initFreeChunkWithBytesat(usqLong numBytes, sqInt address); static void NoDbgRegParms initSegmentBridgeWithBytesat(usqLong numBytes, sqInt address); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); @@ -1386,7 +1387,6 @@ static sqInt NoDbgRegParms handleSpecialSelectorSendFaultForfpsp(sqInt obj, char *theFP, char *theSP); static void handleStackOverflow(void); static sqInt NoDbgRegParms handleStackOverflowOrEventAllowContextSwitch(sqInt mayContextSwitch); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); static sqInt NoDbgRegParms ifCurrentStackPageHasValidHeadPointers(StackPage *thePage); static usqInt NoDbgRegParms iframeMethod(char *theFP); @@ -2455,7 +2455,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1883"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1885"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -6047,7 +6047,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -6073,7 +6073,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -13056,7 +13056,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -13082,7 +13082,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -13416,7 +13416,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -13442,7 +13442,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -13882,7 +13882,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -13908,7 +13908,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -14350,7 +14350,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -14376,7 +14376,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ localIP += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(localIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(localIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -14762,7 +14762,7 @@ /* Store the error code if the method starts with a long store temp. No instructionPointer skip because we're heading for machine code. */ initialPC = ((GIV(newMethod) + ((LiteralStart + (literalCountOfMethodHeader(methodHeader))) * BytesPerOop)) + BaseHeaderSize) + (3); if (GIV(primFailCode) != 0) { - if ((byteAt(initialPC)) == (((((int) methodHeader)) < 0 + if ((byteAt(initialPC)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -14857,7 +14857,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -14888,7 +14888,7 @@ with a long store temp. Strictly no need to skip the store because it's effectively a noop. */ GIV(instructionPointer) += 3; if (GIV(primFailCode) != 0) { - if ((byteAt(GIV(instructionPointer) + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(GIV(instructionPointer) + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -17638,7 +17638,7 @@ sqInt i; sqInt methodField; sqInt ok; - usqInt oop; + sqInt oop; char *theFP; StackPage *thePage; char *theSP; @@ -23709,7 +23709,7 @@ usqInt index; sqInt methodField; usqInt numArgs; - usqInt numTemps; + sqInt numTemps; char *rcvrAddress; sqInt rcvrOrClosure; sqInt theMethod; @@ -24960,7 +24960,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader1); - GIV(bytecodeSetSelector) = ((((int) methodHeader1)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader1)) < 0 ? 256 : 0); @@ -24995,7 +24995,7 @@ GIV(instructionPointer) = initialIP; } if (GIV(primFailCode) != 0) { - if ((byteAt(initialIP + 1)) == (((((int) methodHeader1)) < 0 + if ((byteAt(initialIP + 1)) == (((((sqLong) methodHeader1)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -25188,7 +25188,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader1); - GIV(bytecodeSetSelector) = ((((int) methodHeader1)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader1)) < 0 ? 256 : 0); @@ -25223,7 +25223,7 @@ GIV(instructionPointer) = initialIP; } if (GIV(primFailCode) != 0) { - if ((byteAt(initialIP + 1)) == (((((int) methodHeader1)) < 0 + if ((byteAt(initialIP + 1)) == (((((sqLong) methodHeader1)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ @@ -31040,7 +31040,7 @@ GIV(method) = theMethod; assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -31297,7 +31297,7 @@ GIV(method) = theMethod; assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -31587,7 +31587,7 @@ GIV(method) = theMethod; assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -42974,6 +42974,16 @@ } +/* A negative header selects the alternate bytecode set. */ + + /* Spur64BitMemoryManager>>#headerIndicatesAlternateBytecodeSet: */ +sqInt +headerIndicatesAlternateBytecodeSet(sqInt methodHeader) +{ + return (((sqLong) methodHeader)) < 0; +} + + /* must have room for a header (single or double) plus the next free pointer */ /* Spur64BitMemoryManager>>#initFreeChunkWithBytes:at: */ @@ -67505,7 +67515,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - usqInt address; + sqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -71894,16 +71904,6 @@ } -/* A negative header selects the alternate bytecode set. */ - - /* StackInterpreter>>#headerIndicatesAlternateBytecodeSet: */ -sqInt -headerIndicatesAlternateBytecodeSet(sqInt methodHeader) -{ - return (((int) methodHeader)) < 0; -} - - /* This is a C implementation needed by ioSetMaxExtSemTableSize and e.g. stackPageByteSize. */ @@ -72881,7 +72881,7 @@ sqInt longStoreBytecodeForHeader(sqInt methodHeader) { - return ((((int) methodHeader)) < 0 + return ((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode); } @@ -74976,7 +74976,7 @@ assert((((((CogMethod *) header))->objectHeader)) == (nullHeaderForMachineCodeMethod())); methodHeader = ((((CogMethod *) header))->methodHeader); } - return (((int) methodHeader)) < 0; + return (((sqLong) methodHeader)) < 0; } @@ -75313,12 +75313,12 @@ } -/* Note: With the Squeak V0 format we now have 10 bits of primitive index, - but they are in - two places for temporary backward compatibility. The time to unpack is +/* Note: With the Squeak V3 format we now have 10 bits of primitive index, + but they are + in two places for temporary backward compatibility. The time to unpack is negligible, since the derived primitive function pointer is stored in the - method cache. With the new - format we assume a 3-byte CallPrimitive with a little-endian 16-bit + method cache. With the + Spur format we assume a 3-byte CallPrimitive with a little-endian 16-bit primitive index. */ /* StackInterpreter>>#primitiveIndexOfMethod:header: */ @@ -78499,7 +78499,7 @@ static sqInt retryPrimitiveOnFailure(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - signed char accessorDepth; + sqInt accessorDepth; sqInt canRetry; sqInt firstBytecode; sqInt followDone; @@ -79590,7 +79590,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -79625,7 +79625,7 @@ GIV(instructionPointer) = initialIP; } if (GIV(primFailCode) != 0) { - if ((byteAt(initialIP + 1)) == (((((int) methodHeader)) < 0 + if ((byteAt(initialIP + 1)) == (((((sqLong) methodHeader)) < 0 ? AltLongStoreBytecode : LongStoreBytecode))) { /* begin getErrorObjectFromPrimFailCode */ Modified: branches/Cog/nsspursrc/vm/cogit.h =================================================================== --- branches/Cog/nsspursrc/vm/cogit.h 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/cogit.h 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ Modified: branches/Cog/nsspursrc/vm/cogitARMv5.c =================================================================== --- branches/Cog/nsspursrc/vm/cogitARMv5.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/cogitARMv5.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; Modified: branches/Cog/nsspursrc/vm/cogitIA32.c =================================================================== --- branches/Cog/nsspursrc/vm/cogitIA32.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/cogitIA32.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; Modified: branches/Cog/nsspursrc/vm/cogitMIPSEL.c =================================================================== --- branches/Cog/nsspursrc/vm/cogitMIPSEL.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/cogitMIPSEL.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -2682,7 +2682,7 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - sqInt endbcpc; + usqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; @@ -3188,7 +3188,7 @@ usqInt cacheTag1; sqInt classTag; sqInt enclosingObject; - usqInt entryPoint; + sqInt entryPoint; usqInt entryPoint1; usqInt entryPoint2; sqInt literal; @@ -4741,7 +4741,7 @@ static sqInt NoDbgRegParms cPICHasFreedTargets(CogMethod *cPIC) { - sqInt entryPoint; + usqInt entryPoint; sqInt i; sqInt pc; CogMethod *targetMethod; @@ -5808,12 +5808,12 @@ generateMapAtstart(sqInt addressOrNull, sqInt startAddress) { unsigned char annotation; - sqInt delta; + usqInt delta; sqInt i; AbstractInstruction *instruction; sqInt length; - sqInt location; - sqInt mapEntry; + usqInt location; + usqInt mapEntry; sqInt maxDelta; usqInt mcpc; @@ -8078,7 +8078,7 @@ sqInt byte; BytecodeDescriptor *descriptor; sqInt distance; - sqInt endbcpc; + usqInt endbcpc; CogMethod *homeMethod; sqInt isBackwardBranch; sqInt isInBlock; @@ -8754,7 +8754,7 @@ relocateCallsInClosedPIC(CogMethod *cPIC) { sqLong callDelta; - sqInt entryPoint; + usqInt entryPoint; sqInt i; sqInt pc; sqLong refDelta; @@ -9624,7 +9624,7 @@ unlinkIfLinkedSendpcto(sqInt annotation, char *mcpc, sqInt theCogMethod) { usqInt cacheAddress; - usqInt entryPoint; + sqInt entryPoint; usqInt entryPoint1; char *mcpc1; NSSendCache *nsSendCache; @@ -14780,7 +14780,7 @@ static AbstractInstruction * NoDbgRegParms relocateMethodReferenceBeforeAddressby(AbstractInstruction * self_in_relocateMethodReferenceBeforeAddressby, sqInt pc, sqInt delta) { - usqInt newValue; + sqInt newValue; usqInt oldValue; if (((opcodeAtAddress(self_in_relocateMethodReferenceBeforeAddressby, pc - 8)) == ADDIU) @@ -22263,7 +22263,7 @@ CogBlockMethod *cogMethod1; BytecodeDescriptor *descriptor; sqInt distance; - sqInt endbcpc; + usqInt endbcpc; sqInt errCode; CogMethod *homeMethod; sqInt isBackwardBranch; Modified: branches/Cog/nsspursrc/vm/cointerp.c =================================================================== --- branches/Cog/nsspursrc/vm/cointerp.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/cointerp.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -870,6 +870,7 @@ extern sqInt floatObjectOf(double aFloat); extern double floatValueOf(sqInt oop); static sqInt hasSixtyFourBitImmediates(void); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); static sqInt NoDbgRegParms initFreeChunkWithBytesat(usqLong numBytes, sqInt address); static void NoDbgRegParms initSegmentBridgeWithBytesat(usqLong numBytes, sqInt address); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); @@ -1358,7 +1359,6 @@ static sqInt NoDbgRegParms handleSpecialSelectorSendFaultForfpsp(sqInt obj, char *theFP, char *theSP); static void handleStackOverflow(void); static sqInt NoDbgRegParms handleStackOverflowOrEventAllowContextSwitch(sqInt mayContextSwitch); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); static sqInt NoDbgRegParms ifCurrentStackPageHasValidHeadPointers(StackPage *thePage); static usqInt NoDbgRegParms iframeMethod(char *theFP); @@ -2428,7 +2428,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1883"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1885"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -23022,7 +23022,7 @@ usqInt index; sqInt methodField; usqInt numArgs; - sqInt numTemps; + usqInt numTemps; char *rcvrAddress; sqInt rcvrOrClosure; sqInt theMethod; @@ -41803,7 +41803,7 @@ sqInt fmt; usqInt instBytes; sqInt instFormat; - sqInt newFormat; + usqInt newFormat; sqInt normalizedInstFormat; usqInt numBytes; usqInt numSlots; @@ -42074,6 +42074,16 @@ } +/* A negative header selects the alternate bytecode set. */ + + /* Spur32BitMemoryManager>>#headerIndicatesAlternateBytecodeSet: */ +sqInt +headerIndicatesAlternateBytecodeSet(sqInt methodHeader) +{ + return (((int) methodHeader)) < 0; +} + + /* must have room for a header (single or double) plus the next free pointer */ /* Spur32BitMemoryManager>>#initFreeChunkWithBytes:at: */ @@ -66226,7 +66236,7 @@ bridgeFromto(SpurSegmentInfo *aSegment, SpurSegmentInfo *nextSegmentOrNil) { usqInt bridgeSpan; - usqInt clifton; + sqInt clifton; usqInt segEnd; segEnd = ((aSegment->segSize)) + ((aSegment->segStart)); @@ -66407,7 +66417,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - sqInt address; + usqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -70822,16 +70832,6 @@ } -/* A negative header selects the alternate bytecode set. */ - - /* StackInterpreter>>#headerIndicatesAlternateBytecodeSet: */ -sqInt -headerIndicatesAlternateBytecodeSet(sqInt methodHeader) -{ - return (((int) methodHeader)) < 0; -} - - /* This is a C implementation needed by ioSetMaxExtSemTableSize and e.g. stackPageByteSize. */ @@ -74372,12 +74372,12 @@ } -/* Note: With the Squeak V0 format we now have 10 bits of primitive index, - but they are in - two places for temporary backward compatibility. The time to unpack is +/* Note: With the Squeak V3 format we now have 10 bits of primitive index, + but they are + in two places for temporary backward compatibility. The time to unpack is negligible, since the derived primitive function pointer is stored in the - method cache. With the new - format we assume a 3-byte CallPrimitive with a little-endian 16-bit + method cache. With the + Spur format we assume a 3-byte CallPrimitive with a little-endian 16-bit primitive index. */ /* StackInterpreter>>#primitiveIndexOfMethod:header: */ @@ -77506,7 +77506,7 @@ static sqInt retryPrimitiveOnFailure(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - signed char accessorDepth; + sqInt accessorDepth; sqInt canRetry; sqInt firstBytecode; sqInt followDone; Modified: branches/Cog/nsspursrc/vm/cointerp.h =================================================================== --- branches/Cog/nsspursrc/vm/cointerp.h 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/cointerp.h 2016-06-07 22:35:56 UTC (rev 3739) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ @@ -131,6 +131,7 @@ extern usqInt scavengeThresholdAddress(void); extern sqInt withoutForwardingOnandwithsendToCogit(sqInt obj1, sqInt obj2, sqInt aBool, sqInt (*selector)(sqInt,sqInt,sqInt)); extern sqInt byteSwapped(sqInt w); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); extern sqInt isIntegerValue(sqInt intValue); extern sqInt isMarked(sqInt objOop); @@ -271,7 +272,6 @@ extern void (*functionPointerForinClass(sqInt primIdx,sqInt theClass))(void) ; extern usqLong getNextWakeupUsecs(void); extern sqInt * getStackPointer(void); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); extern sqInt isFloatObject(sqInt oop); extern sqInt isKindOfInteger(sqInt oop); Modified: branches/Cog/nsspursrc/vm/gcc3x-cointerp.c =================================================================== --- branches/Cog/nsspursrc/vm/gcc3x-cointerp.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspursrc/vm/gcc3x-cointerp.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -2,11 +2,11 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -873,6 +873,7 @@ extern sqInt floatObjectOf(double aFloat); extern double floatValueOf(sqInt oop); static sqInt hasSixtyFourBitImmediates(void); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); static sqInt NoDbgRegParms initFreeChunkWithBytesat(usqLong numBytes, sqInt address); static void NoDbgRegParms initSegmentBridgeWithBytesat(usqLong numBytes, sqInt address); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); @@ -1361,7 +1362,6 @@ static sqInt NoDbgRegParms handleSpecialSelectorSendFaultForfpsp(sqInt obj, char *theFP, char *theSP); static void handleStackOverflow(void); static sqInt NoDbgRegParms handleStackOverflowOrEventAllowContextSwitch(sqInt mayContextSwitch); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); static sqInt NoDbgRegParms ifCurrentStackPageHasValidHeadPointers(StackPage *thePage); static usqInt NoDbgRegParms iframeMethod(char *theFP); @@ -2431,7 +2431,7 @@ }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1883"; +const char *interpreterVersion = "Newspeak Virtual Machine CoInterpreterPrimitives_VMMaker.oscog-eem.1885"; sqInt minBackwardJumpCountForCompile = MinBackwardJumpCountForCompile /* 40 */; volatile int sendTrace; @@ -23031,7 +23031,7 @@ usqInt index; sqInt methodField; usqInt numArgs; - sqInt numTemps; + usqInt numTemps; char *rcvrAddress; sqInt rcvrOrClosure; sqInt theMethod; @@ -41812,7 +41812,7 @@ sqInt fmt; usqInt instBytes; sqInt instFormat; - sqInt newFormat; + usqInt newFormat; sqInt normalizedInstFormat; usqInt numBytes; usqInt numSlots; @@ -42083,6 +42083,16 @@ } +/* A negative header selects the alternate bytecode set. */ + + /* Spur32BitMemoryManager>>#headerIndicatesAlternateBytecodeSet: */ +sqInt +headerIndicatesAlternateBytecodeSet(sqInt methodHeader) +{ + return (((int) methodHeader)) < 0; +} + + /* must have room for a header (single or double) plus the next free pointer */ /* Spur32BitMemoryManager>>#initFreeChunkWithBytes:at: */ @@ -66235,7 +66245,7 @@ bridgeFromto(SpurSegmentInfo *aSegment, SpurSegmentInfo *nextSegmentOrNil) { usqInt bridgeSpan; - usqInt clifton; + sqInt clifton; usqInt segEnd; segEnd = ((aSegment->segSize)) + ((aSegment->segStart)); @@ -66416,7 +66426,7 @@ static void postSnapshot(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - sqInt address; + usqInt address; sqInt bytes; usqInt freeChunk; sqInt i; @@ -70831,16 +70841,6 @@ } -/* A negative header selects the alternate bytecode set. */ - - /* StackInterpreter>>#headerIndicatesAlternateBytecodeSet: */ -sqInt -headerIndicatesAlternateBytecodeSet(sqInt methodHeader) -{ - return (((int) methodHeader)) < 0; -} - - /* This is a C implementation needed by ioSetMaxExtSemTableSize and e.g. stackPageByteSize. */ @@ -74381,12 +74381,12 @@ } -/* Note: With the Squeak V0 format we now have 10 bits of primitive index, - but they are in - two places for temporary backward compatibility. The time to unpack is +/* Note: With the Squeak V3 format we now have 10 bits of primitive index, + but they are + in two places for temporary backward compatibility. The time to unpack is negligible, since the derived primitive function pointer is stored in the - method cache. With the new - format we assume a 3-byte CallPrimitive with a little-endian 16-bit + method cache. With the + Spur format we assume a 3-byte CallPrimitive with a little-endian 16-bit primitive index. */ /* StackInterpreter>>#primitiveIndexOfMethod:header: */ @@ -77515,7 +77515,7 @@ static sqInt retryPrimitiveOnFailure(void) { DECL_MAYBE_SQ_GLOBAL_STRUCT - signed char accessorDepth; + sqInt accessorDepth; sqInt canRetry; sqInt firstBytecode; sqInt followDone; Modified: branches/Cog/nsspurstack64src/vm/gcc3x-interp.c =================================================================== --- branches/Cog/nsspurstack64src/vm/gcc3x-interp.c 2016-06-07 03:03:08 UTC (rev 3738) +++ branches/Cog/nsspurstack64src/vm/gcc3x-interp.c 2016-06-07 22:35:56 UTC (rev 3739) @@ -2,11 +2,11 @@ /* Automatically generated by - CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + CCodeGeneratorGlobalStructure VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 from - StackInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d + StackInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 */ -static char __buildInfo[] = "StackInterpreter VMMaker.oscog-eem.1883 uuid: a87f979f-7e5b-44d1-804d-fc8403bde06d " __DATE__ ; +static char __buildInfo[] = "StackInterpreter VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; char *__interpBuildInfo = __buildInfo; @@ -632,6 +632,7 @@ static sqInt NoDbgRegParms fetchLong32ofFloatObject(sqInt fieldIndex, sqInt oop); extern sqInt floatObjectOf(double aFloat); extern double floatValueOf(sqInt oop); +extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); static sqInt NoDbgRegParms initFreeChunkWithBytesat(usqLong numBytes, sqInt address); static void NoDbgRegParms initSegmentBridgeWithBytesat(usqLong numBytes, sqInt address); extern sqInt instantiateClassindexableSize(sqInt classObj, usqInt nElements); @@ -1140,7 +1141,6 @@ static sqInt NoDbgRegParms handleSpecialSelectorSendFaultForfpsp(sqInt obj, char *theFP, char *theSP); static void handleStackOverflow(void); static sqInt NoDbgRegParms handleStackOverflowOrEventAllowContextSwitch(sqInt mayContextSwitch); -extern sqInt headerIndicatesAlternateBytecodeSet(sqInt methodHeader); extern usqInt highBit(usqInt anUnsignedValue); static sqInt NoDbgRegParms ifCurrentStackPageHasValidHeadPointers(StackPage *thePage); static usqInt NoDbgRegParms iframeMethod(char *theFP); @@ -2193,7 +2193,7 @@ 0 }; sqInt checkedPluginName; char expensiveAsserts = 0; -const char *interpreterVersion = "Newspeak Virtual Machine StackInterpreterPrimitives_VMMaker.oscog-eem.1883"; +const char *interpreterVersion = "Newspeak Virtual Machine StackInterpreterPrimitives_VMMaker.oscog-eem.1885"; volatile int sendTrace; sqInt suppressHeartbeatFlag; @@ -5623,7 +5623,7 @@ GIV(method) = GIV(newMethod); assert(isOopCompiledMethod(GIV(method))); assert((methodHeaderOf(GIV(method))) == methodHeader); - GIV(bytecodeSetSelector) = ((((int) methodHeader)) < 0 + GIV(bytecodeSetSelector) = ((((sqLong) methodHeader)) < 0 ? 256 : 0); @@ -5647,7 +5647,7 @@ @@ Diff output truncated at 50000 characters. @@ From eliot.miranda at gmail.com Tue Jun 7 23:09:44 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 7 23:09:47 2016 Subject: [Vm-dev] Re: [Pharo-dev] [ANN] Ephemeron Support is Ready In-Reply-To: <5756949A.9010307@gmail.com> References: <5756949A.9010307@gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PharoScreenshot.1.png Type: image/png Size: 42165 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/70edda42/PharoScreenshot.1-0001.png From btc at openinworld.com Wed Jun 8 00:25:10 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 8 00:25:33 2016 Subject: [Vm-dev] Different bytecode set per process Message-ID: On Wed, Jun 8, 2016 at 6:07 AM, wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1884.mcz > > Fix multiple bytecode set selection in the Spur 64-bit VM, which must use signedIntFromLong64 to test for a negative header. Just a strange spark of an idea thats been floating in my head for a while regarding use of multiple CPU cores (it doesn't need a response - it just helps quiet my thoughts to share them...) The main problem with multiple native threads is concurrent modification objectmemory, plus most of the Image is not designed for such parallel execution, but... What if you could have a bytecode set that had all the bytecodes which modify objectmemory stripped out, so that only stack operations were permitted. And if a forked Smalltalk Process could be restricted to that bytecodeset (swapping the bytecode set when the Process is woken in #transferTo:), then you kindof enforce a functional style of programming for that Process that could not interfere with objectmemory. This might be suitable for some forms of intensive data processing that crunch a lot of data down to a small result. Maybe it would be difficult for such a forked Process to deal with the main UI Process changing objectmemory underfeet. cheers -ben From eliot.miranda at gmail.com Wed Jun 8 03:47:52 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 8 03:47:56 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: Hi Ben, On Fri, Jun 3, 2016 at 6:45 AM, Ben Coman wrote: > > Is their some method I can call in the Image to cause the simulator to > break into a debugger? I want to do this right before the end block > bracket, so I can trace the termination of a forked block without > needing to trace over the block's statements. > There is a general facility for message selectors (setBreakSelector:), either when sent in the interpreter, compiled in the JIT or not understood (setBreakMNUSelector:). There is a generalised breakpoint facility using blocks. In the Cogit you can specify a block that will be run on each machine instruction, e.g. | vm | vm := CogVMSimulator newWithOptions: #(#ObjectMemory #Spur32BitCoMemoryManager). vm desiredNumStackPages: 8. vm setBreakSelector: #behaviorHashOf:. vm openOn: (FileDirectory default fullNameFor: 'startreader.image'). vm breakBlock: [:cogit | cogit processor pc = 446009 and: [cogit processor edx = 3871504]]. In the interpreter there's an atEachStep block run on each bytecode. You can have separate atEachStep: and breakBlock: blocks. cheers -ben > > On Tue, May 31, 2016 at 1:27 AM, tim Rowledge wrote: > > > > > >> On 30-05-2016, at 10:09 AM, Ben Coman wrote: > >> > >> > >> On Mon, May 30, 2016 at 11:35 PM, Cl?ment Bera > wrote: > >>> > >>> I did a post out of this thread: > >>> > >>> https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/ > >> > >> Nice article Clement, thanks. > >> One thing though, I can't think what the "dis" means in genAndDis: ? > > > > Ooh, ooh - I can answer that one! "generate and disassemble? as in > generate the code and then disassemble it and display the nicely formatted > string result so you can see where it all went horribly wrong. > > > > > > tim > > -- > > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > > The less time planning, the more time programming. > > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160607/e7dbe754/attachment.htm From guillermopolito at gmail.com Wed Jun 8 07:36:27 2016 From: guillermopolito at gmail.com (Guille Polito) Date: Wed Jun 8 07:35:58 2016 Subject: [Vm-dev] Re: [Pharo-dev] [ANN] Ephemeron Support is Ready In-Reply-To: References: <5756949A.9010307@gmail.com> Message-ID: <5757CAFB.9060407@gmail.com> Hi Eliot, Pharo does AFAIK the same with the source files when you're navigating source code. Now, I remember that while adapting the finalization scheme that you sent me to Pharo (because there are indeed subtle differences), I noticed that there was a missing loop. [looking for the code... found!] finalizationProcess "The finalization process arranges to send mourn to each element of the VM's finalization queue, which is accessed via primitiveFetchMourner. The VM signals FinalizationSemaphore whenever the queue is non-empty. This process loops, waiting on the semaphore, fetches the first element of the queue and then spawns a process at a higher priority to acually send the mourn messages. If an error occurs in the higher priority mourn loop process then this process will simply spawn another process, hence ensuring that errors in finalization methods don't break finalization. In addition this process also runs the old finalization scheme, supporting clients of the older, WeakRegistry based scheme. Hopefully this will go away when all cleints have moved over." | throttle firstMourner | throttle := Semaphore new. [FinalizationSemaphore wait; initSignals. "Support the old scheme until things have changed over..." self doOldFinalization. [firstMourner := self primitiveFetchMourner. firstMourner notNil] whileTrue: [[throttle signal. self mournLoopWith: firstMourner] forkAt: Processor activePriority + 1. throttle wait]] At first I was using that code that you sent me and I noticed that the finalization process in there is a loop that is never evaluated! So I updated it to the following using a [true] whileTrue: finalizationProcess "The finalization process arranges to send mourn to each element of the VM's finalization queue, which is accessed via primitiveFetchMourner. The VM signals FinalizationSemaphore whenever the queue is non-empty. This process loops, waiting on the semaphore, fetches the first element of the queue and then spawns a process at a higher priority to acually send the mourn messages. If an error occurs in the higher priority mourn loop process then this process will simply spawn another process, hence ensuring that errors in finalization methods don't break finalization. In addition this process also runs the old finalization scheme, supporting clients of the older, WeakRegistry based scheme. Hopefully this will go away when all cleints have moved over." | throttle firstMourner | throttle := Semaphore new. [true] whileTrue: [FinalizationSemaphore wait; initSignals. "Support the old scheme until things have changed over..." self doOldFinalization. [firstMourner := self primitiveFetchMourner. firstMourner notNil] whileTrue: [[throttle signal. self mournLoopWith: firstMourner] forkAt: Processor activePriority + 1. throttle wait]] Maybe that's the reason of weak arrays not being finalized in squeak? Guille -------- Original Message -------- > > > > Hi Guille, > > good news! But I'm seeing something wrong with finalisation of > weak arrays using the new scheme. In Squeak method source access is > done by default by opening a new read-only file for each method's > source read (crazy, but that's not the issue). So by default > something that accesses lots of source ends up running out of file > descriptors, which causes primOpen:writable: to fail. The surrounding > code then uses retryWithGC:until:forFileNamed: to do a GC to try and > reclaim non-longer referenced files, close file descriptors and continue: > > StandardFileStream retryWithGC:[self primOpen: f writable: > writeMode] > until:[:id| id notNil] > forFileNamed: fileName. > > But in my tests I'm not seeing any files reclaimed. I wonder whether > the new finalisation code is failing to finalise weak arrays > properly. I wonder whether your weak tests work properly with the new > scheme or not. > > Anyway, I think I can reproduce the pathology in the simulator if I > modify it to implement a small limit on the number of file > descriptors. I'm going to try that to shed light on the problem. I > can't easily debug in a running image because...I run out of file > descriptors ;-) > > On Tue, Jun 7, 2016 at 2:32 AM, Guille Polito > > wrote: > > > > > > > > Hi All, > > > > Since this morning, in Pharo #60065, Ephemeron support is in the > image. Most of the changes are infrastructural, so far transparent > for the users. It is important to notice that even while the support > is there, it is not enabled by default. Also, this required changes > in the virtual machine that are not yet distributed everywhere. For > the ones that would like more detail, I invite you to read the > following :) > > > > * On the infrastructure side > > - There is support to create Ephemeric classes and load them from > monticello > > - There is a new finalization mechanism (by default disabled) that > will process Ephemerons using a finalization queue. This will avoid > scanning collections in look for weak objects to finalize ,as it > happens now with the WeakDependent mechanism in WeakArray. > > - System-Finalization features two new classes *Ephemeron* and > *EphemeronRegistry*. For the ones that want more details on > Ephemerons, you can read the associated paper [1], or the class > comment of Ephemeron: > > > > I represent ephemeric key-value objects. Ephemerons are > key-value objects (subclasses of Association) with special > semantics during garbage collection. My special behavior can > resumed as follows: > > > > - The garbage collection will iterate my instances only if the key > is not referenced strongly by another object. > > - Then, if no strong references to the key are found, then the > values of this ephemeron are hold weakly. > > - Otherwise, the values are hold strongly. > > > > In this implementation, an Ephemeron can hold more than one value, > which are all treated in the same manner. This ephemeron instance > knows its container, which allows the ephemeron to remove itself > from a container (such as a Dictionary) upon finalization. > > > > !! Example usages > > > > In general terms, do not use myself directly. Use instead an > Ephemeric container like EphemeronRegistry. An Ephemeron registry > will guarantee the collection of keys and values of the object > inside the Ephemeron. > > > > Otherwise, if you want to use it, you can create an Ephemeron as > any association: > > > > ephemeron := Ephemeron key: aKey value: aValue. > > ephemeron container: aContainer. > > > > !! Ephemeron Finalization > > > > When an ephemeron's key is hold strongly just by the ephemeron > itself, the Ephemeron will be mourned (finalized). That means that > the VM will: > > - put the Ephemeron in the mourning queue waiting for the image to > take care of mourning > > - make the Ephemeron non ephemeric. That is, the ephemeron > instance cannot be reused. > > > > On the image side, the finalization process will send the message > #mourn to an Ephemeron. #mourn will #finalize the Ephemeron's > key, and remove the Ephemeron from it's container to allow its > collection during a subsequent garbage collection. > > > > !! More Documentation > > > > You can read the associated paper to understand better the > semantics of ephemerons: > > > > [1]Ephemerons: A New Finalization Mechanism. Barry Hayes. OOPSLA > '97 > > > > > > > - WARNING: to be able to use ephemerons, you need to use the > *latestVm* that has several fixes for making ephemerons work, and > you need to enable ephemerons on the image side by evaluating: > > > > Smalltalk supportsQueueingFinalization: true. > > > > - With latest vm and ephemerons enabled, tests should be green, > otherwise they are skipped > > > > > > > > * From the user point of view: > > > > - The Weak registries were not yet migrated to the new > finalization mechanism. > > - We expect nothing will change from the user point of view. Just > less memory leaks. > > > > * Next steps (in order) > > 1) Bless the latest vm as stable > > 2) Enable queueing finalization by default > > 3) Replace Weak Registry by Ephemeron Registry. > > > > > > Informed by: Guille > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > > > > > -------------- next part -------------- Skipped content of type multipart/related From timfelgentreff at gmail.com Wed Jun 8 08:07:45 2016 From: timfelgentreff at gmail.com (timfelgentreff) Date: Wed Jun 8 08:46:18 2016 Subject: [Vm-dev] Re: Different bytecode set per process In-Reply-To: References: Message-ID: <1465373265401-4899809.post@n4.nabble.com> Hi Ben, We once experimented with STM to run Squeak Processes on multiple cores without any restrictions to the bytecodes. Due to the STM foundations, any conflicts are resolved automatically (with quite a bit of performance impact as more and more conflicts occur). But for algorithms that do not share data structures (except an output of some kind) we did actually see quite a bit of speedup when scaling over multiple cores - without any changes to the image. Now, if we had such a bytecode set restriction that could be attached to a process, this experiment could become very interesting again. Best, Tim Ben Coman wrote > On Wed, Jun 8, 2016 at 6:07 AM, < > commits@.squeak > > wrote: >> >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1884.mcz >> >> Fix multiple bytecode set selection in the Spur 64-bit VM, which must use >> signedIntFromLong64 to test for a negative header. > > > Just a strange spark of an idea thats been floating in my head for a > while regarding use of multiple CPU cores (it doesn't need a response > - it just helps quiet my thoughts to share them...) > > The main problem with multiple native threads is concurrent > modification objectmemory, plus most of the Image is not designed for > such parallel execution, > but... > > What if you could have a bytecode set that had all the bytecodes which > modify objectmemory stripped out, so that only stack operations were > permitted. And if a forked Smalltalk Process could be restricted to > that bytecodeset (swapping the bytecode set when the Process is woken > in #transferTo:), then you kindof enforce a functional style of > programming for that Process that could not interfere with > objectmemory. > > This might be suitable for some forms of intensive data processing > that crunch a lot of data down to a small result. Maybe it would be > difficult for such a forked Process to deal with the main UI Process > changing objectmemory underfeet. > > cheers -ben -- View this message in context: http://forum.world.st/Different-bytecode-set-per-process-tp4899760p4899809.html Sent from the Squeak VM mailing list archive at Nabble.com. From bera.clement at gmail.com Wed Jun 8 11:47:53 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Wed Jun 8 11:48:15 2016 Subject: [Vm-dev] Re: Different bytecode set per process In-Reply-To: <1465373265401-4899809.post@n4.nabble.com> References: <1465373265401-4899809.post@n4.nabble.com> Message-ID: I believe it's not about having a different bytecode set per process, I believe you want some process not to be able to edit the heap but to do computation only. So the process has access to a restricted bytecode set (not inst var store for example) and a restricted set of primitives (no #at:put:). STM is very interesting indeed. In the RSqueak/VM, how did you change the process scheduler ? Did you mark specific processes so they belong to a specific native thread ? I see that you added primitives for atomic blocks of code and to fork a process in another native thread. On Wed, Jun 8, 2016 at 10:07 AM, timfelgentreff wrote: > > Hi Ben, > > We once experimented with STM to run Squeak Processes on multiple cores > without any restrictions to the bytecodes. Due to the STM foundations, any > conflicts are resolved automatically (with quite a bit of performance > impact > as more and more conflicts occur). But for algorithms that do not share > data > structures (except an output of some kind) we did actually see quite a bit > of speedup when scaling over multiple cores - without any changes to the > image. > > Now, if we had such a bytecode set restriction that could be attached to a > process, this experiment could become very interesting again. > > Best, > Tim > > > Ben Coman wrote > > On Wed, Jun 8, 2016 at 6:07 AM, < > > > commits@.squeak > > > > wrote: > >> > >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1884.mcz > >> > >> Fix multiple bytecode set selection in the Spur 64-bit VM, which must > use > >> signedIntFromLong64 to test for a negative header. > > > > > > Just a strange spark of an idea thats been floating in my head for a > > while regarding use of multiple CPU cores (it doesn't need a response > > - it just helps quiet my thoughts to share them...) > > > > The main problem with multiple native threads is concurrent > > modification objectmemory, plus most of the Image is not designed for > > such parallel execution, > > but... > > > > What if you could have a bytecode set that had all the bytecodes which > > modify objectmemory stripped out, so that only stack operations were > > permitted. And if a forked Smalltalk Process could be restricted to > > that bytecodeset (swapping the bytecode set when the Process is woken > > in #transferTo:), then you kindof enforce a functional style of > > programming for that Process that could not interfere with > > objectmemory. > > > > This might be suitable for some forms of intensive data processing > > that crunch a lot of data down to a small result. Maybe it would be > > difficult for such a forked Process to deal with the main UI Process > > changing objectmemory underfeet. > > > > cheers -ben > > > > > > -- > View this message in context: > http://forum.world.st/Different-bytecode-set-per-process-tp4899760p4899809.html > Sent from the Squeak VM mailing list archive at Nabble.com. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160608/e0d25de9/attachment.htm From eliot.miranda at gmail.com Wed Jun 8 16:35:02 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 8 16:35:06 2016 Subject: [Vm-dev] Re: [Pharo-dev] [ANN] Ephemeron Support is Ready In-Reply-To: <5757CAFB.9060407@gmail.com> References: <5756949A.9010307@gmail.com> <5757CAFB.9060407@gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 42165 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160608/44491ddd/attachment-0001.png From marianopeck at gmail.com Wed Jun 8 16:42:14 2016 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Wed Jun 8 16:42:18 2016 Subject: [Vm-dev] Re: [Pharo-dev] [ANN] Ephemeron Support is Ready In-Reply-To: References: <5756949A.9010307@gmail.com> <5757CAFB.9060407@gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 42165 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160608/3d81823a/attachment-0001.png From tim at rowledge.org Wed Jun 8 16:56:38 2016 From: tim at rowledge.org (tim Rowledge) Date: Wed Jun 8 16:56:34 2016 Subject: [Vm-dev] Re: Different bytecode set per process In-Reply-To: References: <1465373265401-4899809.post@n4.nabble.com> Message-ID: <0B6B54A0-AA5B-4E4F-BE3A-1097901038E5@rowledge.org> The problem I anticipate here is almost the same as that which came up many, many, years ago when Ted K had a go at making projects act a bit like namespaces (by swapping in certain methods or something like that? I forget). In that case if you had any background processes (which we do by default) then they could get totally screwed by this change-over. Similarly here we are talking about multiple processes within the same object world, so the same panoply of methods are available. You start a new process, assign a restricted bytecode set for it, start it running? and send a message. Which finds a method that uses the now-forbidden bytecodes. What happens? How about a bug or other interruption? Now you want to open the debugger; what happens? I?d be much more in favour of being able to have disjoint object spaces and decently effective communications between them. If nothing else it would help (a little) to decently enforce encapsulation, something I see constantly being eroded by poor programming and the insanely common use of ?accessor methods? that do nothing but rip open the kimono. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Oh bother" said Pooh, as he reached for the reset button From commits at source.squeak.org Wed Jun 8 18:02:55 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 8 18:02:57 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1886.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1886.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1886 Author: eem Time: 8 June 2016, 11:00:38.901828 am UUID: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Ancestors: VMMaker.oscog-eem.1885 Slang: Fix type inferrence for the 64-bit VM and some other cases after the bug fix in VMMaker.oscog-eem.1883 uncovers bugs in existing code. Collapse returnTypeForSend:in: & returnTypeOrNilForSend:in: onto returnTypeForSend:in:ifNil:. If a method ends with an explicit return of an expression then default its type to #sqInt, only defaulting to #void if the class defines it as the default return type and there is no explicit return of an expression (other thna ^self). Replace transformVoidReturns with transformReturns to handle both void returns (^expr => expr. ^self) and self returns in methods defaulted to sqInt (^self => ^0). Eliminate some translation time warnings for plugins. If possible, put a CurrentReadOnlySourceFiles cacheDuring: around parsing of methods to TMethods toi save cycles. Simulator: Add a mechanism to limit the number of open files for debugging in the FilePluginSimulator. In 1886, Robert Louis Stevenson's novella Strange Case of Dr Jekyll and Mr Hyde is published, Karl Benz patents the first successful gasoline-driven automobile, the Benz Patent-Motorwagen (built in 1885), Wilhelm Steinitz becomes first recognized World Chess Champion, American pharmacist Dr. John Pemberton invents a carbonated beverage that will be named Coca-Cola, and Heinrich Hertz at the University of Karlsruhe verifies the existence of electromagnetic waves. =============== Diff against VMMaker.oscog-eem.1885 =============== Item was changed: ----- Method: CCodeGenerator>>computeKernelReturnTypes (in category 'public') ----- computeKernelReturnTypes | dictionary | dictionary := Dictionary newFromPairs: #(oopAt: #sqInt oopAt:put: #sqInt oopAtPointer: #sqInt oopAtPointer:put: #sqInt byteAt: #sqInt byteAt:put: #sqInt byteAtPointer: #sqInt byteAtPointer:put: #sqInt shortAt: #sqInt shortAt:put: #sqInt shortAtPointer: #sqInt shortAtPointer:put: #sqInt intAt: #sqInt intAt:put: #sqInt intAtPointer: #sqInt intAtPointer:put: #sqInt longAt: #sqInt longAt:put: #sqInt longAtPointer: #sqInt longAtPointer:put: #sqInt long32At: #int long32At:put: #int unalignedLongAt: #sqInt unalignedLongAt:put: #sqInt unalignedLong32At: #int unalignedLong32At:put: #int long64At: #sqLong long64At:put: #sqLong fetchFloatAt:into: #void storeFloatAt:from: #void fetchFloatAtPointer:into: #void storeFloatAtPointer:from: #void fetchSingleFloatAt:into: #void storeSingleFloatAt:from: #void fetchSingleFloatAtPointer:into: #void storeSingleFloatAtPointer:from: #void + pointerForOop: #'char *' oopForPointer: #sqInt + baseHeaderSize #sqInt wordSize #sqInt bytesPerOop #sqInt). - pointerForOop: #'char *' oopForPointer: #sqInt). ^dictionary! Item was changed: ----- Method: CCodeGenerator>>inferTypesForImplicitlyTypedVariablesAndMethods (in category 'type inference') ----- inferTypesForImplicitlyTypedVariablesAndMethods "Infer the return tupe and the types of untyped variables. As far as variables go, for now we try only to infer variables assigned the result of #longLongAt:, but much more could be done here." "Iterate over all methods, inferring #void return types, until we reach a fixed point." | allMethods | allMethods := apiMethods ifNil: [methods] ifNotNil: [(Set withAll: methods) addAll: apiMethods; yourself]. "Make an initial pass to assign the return types of all simple methods that return constants, or those that have explicit return types." allMethods do: [:m| m removeFinalSelfReturnIn: self. "must precede recordDeclarationsIn: because it may set returnType" m recordDeclarationsIn: self. (m returnType isNil and: [m isReturnConstant]) ifTrue: [m inferReturnTypeIn: self]]. "now iterate until we reach a fixed point" [| changedReturnType | changedReturnType := false. allMethods do: [:m| m inferTypesForImplicitlyTypedVariablesIn: self. (m inferReturnTypeIn: self) ifTrue: [changedReturnType := true]]. changedReturnType] whileTrue. "Type all as-yet-untyped methods as the default" methods do: [:m| m returnType ifNil: + [m returnType: (m returnsExpression + ifTrue: [#sqInt] + ifFalse: [self implicitReturnTypeFor: m])]. + m transformReturns]. - [m returnType: (self implicitReturnTypeFor: m selector)]]. "Make a final pass to type anything assigned from the default type" allMethods do: [:m| m inferTypesForImplicitlyTypedVariablesIn: self]! Item was removed: - ----- Method: CCodeGenerator>>returnTypeForSend:in: (in category 'type inference') ----- - returnTypeForSend: sendNode in: aTMethod - "Answer the return type for a send. Absent sends default to #sqInt. - The inferred type should match as closely as possible the C type of - generated expessions so that inlining would not change the expression." - | sel methodOrNil | - methodOrNil := self anyMethodNamed: (sel := sendNode selector). - (methodOrNil notNil and: [methodOrNil returnType notNil]) ifTrue: - [^self baseTypeForType: methodOrNil returnType]. - ^kernelReturnTypes - at: sel - ifAbsent: - [sel - caseOf: { - [#integerValueOf:] -> [#sqInt]. - [#isIntegerObject:] -> [#int]. - [#negated] -> [self promoteArithmeticTypes: (self typeFor: sendNode receiver in: aTMethod) and: #int]. - [#+] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#-] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#*] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#/] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#//] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#\\] -> [self typeForArithmetic: sendNode in: aTMethod]. - " [#>>] -> [self - promoteArithmeticTypes: (self unsignedTypeForIntegralType: (self typeFor: sendNode receiver in: aTMethod)) - and: (self typeFor: sendNode args first in: aTMethod)]. - [#<<] -> [self typeForArithmetic: sendNode in: aTMethod]." - [#rem:] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#quo:] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#addressOf:] -> [(self typeFor: sendNode receiver in: aTMethod) - ifNil: [#sqInt] - ifNotNil: [:type| type, (type last isLetter ifTrue: [' *'] ifFalse: ['*'])]]. - [#at:] -> [self typeForDereference: sendNode in: aTMethod]. - [#bitAnd:] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#bitOr:] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#bitXor:] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#bitClear:] -> [self typeForArithmetic: sendNode in: aTMethod]. - [#bitInvert32] -> [#'unsigned int']. - [#bitInvert64] -> [self promoteArithmeticTypes: (self typeFor: sendNode receiver in: aTMethod) and: #int]. - [#byteSwap32] -> [#'unsigned int']. - [#byteSwap64] -> [#'unsigned long long']. - [#byteSwapped32IfBigEndian:] -> [#'unsigned int']. - [#byteSwapped64IfBigEndian:] -> [#'unsigned long long']. - [#=] -> [#int]. - [#~=] -> [#int]. - [#==] -> [#int]. - [#~~] -> [#int]. - [#<] -> [#int]. - [#<=] -> [#int]. - [#>] -> [#int]. - [#>=] -> [#int]. - [#between:and:] -> [#int]. - [#anyMask:] -> [#int]. - [#allMask:] -> [#int]. - [#noMask:] -> [#int]. - [#isNil] -> [#int]. - [#notNil] -> [#int]. - [#&] -> [#int]. - [#|] -> [#int]. - [#not] -> [#int]. - [#asFloat] -> [#double]. - [#atan] -> [#double]. - [#exp] -> [#double]. - [#log] -> [#double]. - [#sin] -> [#double]. - [#sqrt] -> [#double]. - [#asLong] -> [#long]. - [#asInteger] -> [#sqInt]. - [#asUnsignedInteger] -> [#usqInt]. - [#asUnsignedLong] -> [#'unsigned long']. - [#asVoidPointer] -> [#'void *']. - [#signedIntToLong] -> [#usqInt]. "c.f. generateSignedIntToLong:on:indent:" - [#signedIntToShort] -> [#usqInt]. "c.f. generateSignedIntToShort:on:indent:" - [#cCoerce:to:] -> [sendNode args last value]. - [#cCoerceSimple:to:] -> [sendNode args last value]. - [#sizeof:] -> [#'unsigned long']. "Technically it's a size_t but it matches unsigned long on target architectures so far..." - [#ifTrue:ifFalse:] -> [self typeForConditional: sendNode in: aTMethod]. - [#ifFalse:ifTrue:] -> [self typeForConditional: sendNode in: aTMethod]. - [#ifTrue:] -> [self typeForConditional: sendNode in: aTMethod]. - [#ifFalse:] -> [self typeForConditional: sendNode in: aTMethod] } - otherwise: "If there /is/ a method for sel but its retrn type is as yet unknown we /mustn't/ default it. - We can only default unbound selectors." - [methodOrNil ifNotNil: [nil] ifNil: [#sqInt]]]! Item was added: + ----- Method: CCodeGenerator>>returnTypeForSend:in:ifNil: (in category 'type inference') ----- + returnTypeForSend: sendNode in: aTMethod ifNil: typeIfNil + "Answer the return type for a send. Unbound sends default to typeIfNil. + Methods with types as yet unknown have a type determined either by the + kernelReturnTypes or the table below, or, if they are in neither set, then nil. + The inferred type should match as closely as possible the C type of + generated expessions so that inlining would not change the expression. + If there is a method for sel but its return type is as yet unknown it mustn't + be defaulted, since on a subsequent pass its type may be computable." + | sel methodOrNil | + methodOrNil := self anyMethodNamed: (sel := sendNode selector). + (methodOrNil notNil and: [methodOrNil returnType notNil]) ifTrue: + [^self baseTypeForType: methodOrNil returnType]. + ^kernelReturnTypes + at: sel + ifAbsent: + [sel + caseOf: { + [#integerValueOf:] -> [#sqInt]. + [#isIntegerObject:] -> [#int]. + [#negated] -> [self promoteArithmeticTypes: (self typeFor: sendNode receiver in: aTMethod) and: #int]. + [#+] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#-] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#*] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#/] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#//] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#\\] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#rem:] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#quo:] -> [self typeForArithmetic: sendNode in: aTMethod]. + "C99 Sec Bitwise shift operators ... 3 Sematics ... + The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand..." + [#>>] -> [self typeFor: sendNode receiver in: aTMethod]. + [#<<] -> [self typeFor: sendNode receiver in: aTMethod]. + [#addressOf:] -> [(self typeFor: sendNode receiver in: aTMethod) + ifNil: [#sqInt] + ifNotNil: [:type| type, (type last isLetter ifTrue: [' *'] ifFalse: ['*'])]]. + [#at:] -> [self typeForDereference: sendNode in: aTMethod]. + [#bitAnd:] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#bitOr:] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#bitXor:] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#bitClear:] -> [self typeForArithmetic: sendNode in: aTMethod]. + [#bitInvert32] -> [#'unsigned int']. + [#bitInvert64] -> [self promoteArithmeticTypes: (self typeFor: sendNode receiver in: aTMethod) and: #int]. + [#byteSwap32] -> [#'unsigned int']. + [#byteSwap64] -> [#'unsigned long long']. + [#byteSwapped32IfBigEndian:] -> [#'unsigned int']. + [#byteSwapped64IfBigEndian:] -> [#'unsigned long long']. + [#=] -> [#int]. + [#~=] -> [#int]. + [#==] -> [#int]. + [#~~] -> [#int]. + [#<] -> [#int]. + [#<=] -> [#int]. + [#>] -> [#int]. + [#>=] -> [#int]. + [#between:and:] -> [#int]. + [#anyMask:] -> [#int]. + [#allMask:] -> [#int]. + [#noMask:] -> [#int]. + [#isNil] -> [#int]. + [#notNil] -> [#int]. + [#&] -> [#int]. + [#|] -> [#int]. + [#not] -> [#int]. + [#asFloat] -> [#double]. + [#atan] -> [#double]. + [#exp] -> [#double]. + [#log] -> [#double]. + [#sin] -> [#double]. + [#sqrt] -> [#double]. + [#asLong] -> [#long]. + [#asInteger] -> [#sqInt]. + [#asUnsignedInteger] -> [#usqInt]. + [#asUnsignedLong] -> [#'unsigned long']. + [#asVoidPointer] -> [#'void *']. + [#signedIntToLong] -> [#usqInt]. "c.f. generateSignedIntToLong:on:indent:" + [#signedIntToShort] -> [#usqInt]. "c.f. generateSignedIntToShort:on:indent:" + [#cCoerce:to:] -> [sendNode args last value]. + [#cCoerceSimple:to:] -> [sendNode args last value]. + [#sizeof:] -> [#'unsigned long']. "Technically it's a size_t but it matches unsigned long on target architectures so far..." + [#ifTrue:ifFalse:] -> [self typeForConditional: sendNode in: aTMethod]. + [#ifFalse:ifTrue:] -> [self typeForConditional: sendNode in: aTMethod]. + [#ifTrue:] -> [self typeForConditional: sendNode in: aTMethod]. + [#ifFalse:] -> [self typeForConditional: sendNode in: aTMethod]. + [#and:] -> [#sqInt]. + [#or:] -> [#sqInt] } + otherwise: "If there /is/ a method for sel but its return type is as yet unknown it /mustn't/ be defaulted, + since on a subsequent pass its type may be computable. Only default unbound selectors." + [methodOrNil ifNotNil: [nil] ifNil: [typeIfNil]]]! Item was removed: - ----- Method: CCodeGenerator>>returnTypeOrNilForSend:in: (in category 'type inference') ----- - returnTypeOrNilForSend: sendNode in: aTMethod - "Answer the return type for a send. Sends of known but as-yet-untyped methods answer nil." - | sel | - (self anyMethodNamed: (sel := sendNode selector)) ifNotNil: - [:m| - ^m returnType ifNotNil: [:type| self baseTypeForType: type]]. - ^self returnTypeForSend: sendNode in: aTMethod! Item was changed: FilePlugin subclass: #FilePluginSimulator + instanceVariableNames: 'openFiles states maxOpenFiles' - instanceVariableNames: 'openFiles states' classVariableNames: '' poolDictionaries: '' category: 'VMMaker-InterpreterSimulation'! !FilePluginSimulator commentStamp: 'tpr 5/5/2003 12:02' prior: 0! File plugin simulation for the VM simulator! Item was changed: ----- Method: FilePluginSimulator>>fileOpenName:size:write:secure: (in category 'file primitives') ----- fileOpenName: nameIndex size: nameSize write: writeFlag secure: secureFlag "Open the named file, possibly checking security. Answer the file oop." | path f index | + openFiles size >= maxOpenFiles ifTrue: + [^interpreterProxy primitiveFailFor: PrimErrLimitExceeded]. path := interpreterProxy interpreter asString: nameIndex size: nameSize. f := writeFlag ifTrue: [FileStream fileNamed: path] ifFalse: [(StandardFileStream isAFileNamed: path) ifTrue: [FileStream readOnlyFileNamed: path]]. f ifNil: [^interpreterProxy primitiveFail]. f binary. index := openFiles size + 1. openFiles at: index put: f. ^interpreterProxy integerObjectOf: index! Item was changed: ----- Method: FilePluginSimulator>>initialiseModule (in category 'initialize-release') ----- initialiseModule "See FilePluginSimulator>>sqFileStdioHandlesInto:" (openFiles := Dictionary new) at: 0 put: (FakeStdinStream for: interpreterProxy interpreter); "stdin" at: 1 put: Transcript; "stdout" at: 2 put: Transcript. "stderr" states := IdentityDictionary new. + maxOpenFiles := VMClass initializationOptions at: #MaxFileDescriptors ifAbsent: [1024]. ^super initialiseModule! Item was changed: ----- Method: InterpreterPlugin class>>declareCVarsIn: (in category 'translation') ----- declareCVarsIn: aCCodeGenerator "Note: This method must be implemented by all subclasses to declare variables." aCCodeGenerator var: #interpreterProxy type: #'struct VirtualMachine*'; + removeVariable: 'translatedMethodCache' ifAbsent: nil. + self declareHeaderFilesIn: aCCodeGenerator! - removeVariable: 'translatedMethodCache'. - self declareHeaderFilesIn: aCCodeGenerator.! Item was changed: ----- Method: InterpreterProxy>>characterObjectOf: (in category 'object access') ----- characterObjectOf: characterCode - ^StackInterpreter objectMemoryClass characterObjectOf: characterCode! Item was changed: ----- Method: StackInterpreter>>printOop: (in category 'debug printing') ----- printOop: oop | cls fmt lastIndex startIP bytecodesPerLine column | (objectMemory isImmediate: oop) ifTrue: [^self shortPrintOop: oop]. self printHex: oop. (objectMemory addressCouldBeObj: oop) ifFalse: [^self print: ((oop bitAnd: objectMemory allocationUnit - 1) ~= 0 ifTrue: [' is misaligned'] ifFalse: [self whereIs: oop]); cr]. (objectMemory isFreeObject: oop) ifTrue: [self print: ' is a free chunk of size '; printNum: (objectMemory sizeOfFree: oop). objectMemory hasSpurMemoryManagerAPI ifTrue: [self print: ' 0th: '; printHex: (objectMemory fetchPointer: 0 ofFreeChunk: oop). objectMemory printHeaderTypeOf: oop]. ^self cr]. (objectMemory isForwarded: oop) ifTrue: [self print: ' is a forwarded object to '; printHex: (objectMemory followForwarded: oop); print: ' of slot size '; printNum: (objectMemory numSlotsOfAny: oop). objectMemory printHeaderTypeOf: oop. ^self cr]. self print: ': a(n) '. self printNameOfClass: (cls := objectMemory fetchClassOfNonImm: oop) count: 5. cls = (objectMemory splObj: ClassFloat) ifTrue: [^self cr; printFloat: (objectMemory dbgFloatValueOf: oop); cr]. fmt := objectMemory formatOf: oop. fmt > objectMemory lastPointerFormat ifTrue: [self print: ' nbytes '; printNum: (objectMemory numBytesOf: oop)]. self cr. (fmt between: objectMemory firstLongFormat and: objectMemory firstCompiledMethodFormat - 1) ifTrue: ["This will answer false if splObj: ClassAlien is nilObject" (self is: oop KindOfClass: (objectMemory splObj: ClassAlien)) ifTrue: [self print: ' datasize '; printNum: (self sizeOfAlienData: oop). self print: ((self isIndirectAlien: oop) ifTrue: [' indirect @ '] ifFalse: [(self isPointerAlien: oop) ifTrue: [' pointer @ '] ifFalse: [' direct @ ']]). ^self printHex: (self startOfAlienData: oop) asUnsignedInteger; cr]. + (objectMemory isWordsNonImm: oop) ifTrue: - (objectMemory isWords: oop) ifTrue: [lastIndex := 64 min: ((objectMemory numBytesOf: oop) / objectMemory wordSize). lastIndex > 0 ifTrue: [1 to: lastIndex do: [:index| self space; printHex: (objectMemory fetchLong32: index - 1 ofObject: oop). (index \\ self elementsPerPrintOopLine) = 0 ifTrue: [self cr]]. (lastIndex \\ self elementsPerPrintOopLine) = 0 ifFalse: [self cr]]. ^self]. ^self printStringOf: oop; cr]. "this is nonsense. apologies." startIP := (objectMemory lastPointerOf: oop) + objectMemory bytesPerOop - objectMemory baseHeaderSize / objectMemory bytesPerOop. lastIndex := 256 min: startIP. lastIndex > 0 ifTrue: [1 to: lastIndex do: [:index| self cCode: [self printHex: (objectMemory fetchPointer: index - 1 ofObject: oop); space] inSmalltalk: [self space; printHex: (objectMemory fetchPointer: index - 1 ofObject: oop); space. self print: (self shortPrint: (objectMemory fetchPointer: index - 1 ofObject: oop))]. (index \\ self elementsPerPrintOopLine) = 0 ifTrue: [self cr]]. (lastIndex \\ self elementsPerPrintOopLine) = 0 ifFalse: [self cr]]. (objectMemory isCompiledMethod: oop) ifFalse: [startIP > 64 ifTrue: [self print: '...'; cr]] ifTrue: [startIP := startIP * objectMemory wordSize + 1. lastIndex := objectMemory lengthOf: oop. lastIndex - startIP > 100 ifTrue: [lastIndex := startIP + 100]. bytecodesPerLine := 8. column := 1. startIP to: lastIndex do: [:index| | byte | column = 1 ifTrue: [self cCode: 'printf("0x%08lx: ", (unsigned long)(oop+BaseHeaderSize+index-1))' inSmalltalk: [self print: (oop+objectMemory baseHeaderSize+index-1) hex; print: ': ']]. byte := objectMemory fetchByte: index - 1 ofObject: oop. self cCode: 'printf(" %02x/%-3d", (int)byte,(int)byte)' inSmalltalk: [self space; print: (byte radix: 16); printChar: $/; printNum: byte]. column := column + 1. column > bytecodesPerLine ifTrue: [column := 1. self cr]]. column = 1 ifFalse: [self cr]]! Item was changed: ----- Method: TAssignmentNode>>typeOrNilFrom:in: (in category 'type inference') ----- typeOrNilFrom: aCodeGenerator in: aTMethod "This is the default type in case of doubt" + ^(variable typeOrNilFrom: aCodeGenerator in: aTMethod) ifNil: + [expression typeOrNilFrom: aCodeGenerator in: aTMethod]! - ^variable typeOrNilFrom: aCodeGenerator in: aTMethod! Item was changed: ----- Method: TMethod>>addTypesFor:to:in: (in category 'type inference') ----- addTypesFor: node to: typeSet in: aCodeGen "Add the value types for the node to typeSet. Answer if any type was derived from an as-yet-untyped method, which allows us to abort inferReturnTypeFromReturnsIn: if the return type depends on a yet-to-be-typed method." | expr | expr := node. [expr isAssignment or: [expr isStmtList]] whileTrue: [expr isAssignment ifTrue: [expr := expr variable]. expr isStmtList ifTrue: [expr := expr statements last]]. expr isSend ifTrue: [(#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) includes: expr selector) ifTrue: [^expr args inject: false into: [:asYetUntyped :block| asYetUntyped | (self addTypesFor: block to: typeSet in: aCodeGen)]]. + (aCodeGen returnTypeForSend: expr in: self ifNil: nil) - (aCodeGen returnTypeOrNilForSend: expr in: self) ifNil: [^(aCodeGen methodNamed: expr selector) notNil and: [expr selector ~~ selector]] ifNotNil: [:type | typeSet add: type. ^false].]. expr isVariable ifTrue: [(aCodeGen typeOfVariable: expr name) ifNotNil: [:type| typeSet add: type] ifNil: [typeSet add: (expr name = 'self' ifTrue: [#void] ifFalse: [#sqInt])]]. expr isConstant ifTrue: + [(expr typeOrNilFrom: aCodeGen in: self) ifNotNil: + [:type | typeSet add: type]].. - [(expr typeOrNilFrom: aCodeGen in: self) - ifNotNil: [:type | typeSet add: type]].. ^false! Item was changed: ----- Method: TMethod>>determineTypeFor:in: (in category 'C code generation') ----- determineTypeFor: aNode in: aCodeGen aNode isSend ifTrue: + [^aCodeGen returnTypeForSend: aNode in: self ifNil: #sqInt]. - [^(aCodeGen returnTypeForSend: aNode in: self) ifNil: [#sqInt]]. aNode isAssignment ifTrue: [^self determineTypeFor: aNode expression in: aCodeGen]. self error: 'don''t know how to extract return type from this kind of node'! Item was changed: ----- Method: TMethod>>emitCFunctionPrototype:generator:isPrototype: (in category 'C code generation') ----- emitCFunctionPrototype: aStream generator: aCodeGen isPrototype: isPrototype "" "Emit a C function header for this method onto the given stream. Answer if the method has any compileTimeOptionPragmas" | compileTimeOptionPragmas returnTypeIsFunctionPointer | (compileTimeOptionPragmas := self compileTimeOptionPragmas) notEmpty ifTrue: [self outputConditionalDefineFor: compileTimeOptionPragmas on: aStream]. + returnTypeIsFunctionPointer := returnType notNil + and: [returnType last = $) + and: [returnType includesSubString: (aCodeGen cFunctionNameFor: selector)]]. - returnTypeIsFunctionPointer := returnType last = $) - and: [returnType includesSubString: (aCodeGen cFunctionNameFor: selector)]. export ifTrue: [aStream nextPutAll: 'EXPORT('; nextPutAll: returnType; nextPut: $)] ifFalse: [self isStatic ifTrue: [aStream nextPutAll: 'static '] ifFalse: [isPrototype ifTrue: [aStream nextPutAll: 'extern ']]. (isPrototype or: [inline ~~ #always]) ifFalse: [aStream nextPutAll: 'inline ']. + aStream nextPutAll: (returnType ifNil: [#sqInt])]. - aStream nextPutAll: returnType]. (functionAttributes isNil or: [returnTypeIsFunctionPointer]) ifFalse: [aStream space; nextPutAll: functionAttributes]. isPrototype ifTrue: [aStream space] ifFalse: [aStream cr]. returnTypeIsFunctionPointer ifFalse: [aStream nextPutAll: (aCodeGen cFunctionNameFor: selector); nextPut: $(. args isEmpty ifTrue: [aStream nextPutAll: #void] ifFalse: [args do: [:arg| aStream nextPutAll: (self declarationAt: arg)] separatedBy: [aStream nextPutAll: ', ']]. aStream nextPut: $)]. isPrototype ifTrue: [aStream nextPut: $;; cr. compileTimeOptionPragmas isEmpty ifFalse: [aCodeGen maybeEmitPrimitiveFailureDefineFor: selector on: aStream. self terminateConditionalDefineFor: compileTimeOptionPragmas on: aStream]]. ^compileTimeOptionPragmas notEmpty! Item was changed: ----- Method: TMethod>>inferReturnTypeIn: (in category 'type inference') ----- inferReturnTypeIn: aCodeGen "Attempt to infer the return type of the receiver and answer if it changed." | existingReturnType | existingReturnType := returnType. self inferReturnTypeFromReturnsIn: aCodeGen. - - "If the return type is now void, replace any and all ^expr with expr. ^self" - (existingReturnType ~= returnType and: [returnType = #void]) ifTrue: - [self transformVoidReturns]. - ^existingReturnType ~= returnType! Item was changed: ----- Method: TMethod>>inferTypesForImplicitlyTypedVariablesIn: (in category 'type inference') ----- inferTypesForImplicitlyTypedVariablesIn: aCodeGen "infer types for untyped variables from assignments and arithmetic uses. For debugging answer a Dictionary from var to the nodes that determined types This for debugging: (self copy inferTypesForImplicitlyTypedVariablesIn: aCodeGen)" | alreadyExplicitlyTypedOrNotToBeTyped effectiveNodes | aCodeGen maybeBreakForTestToInline: selector in: self. alreadyExplicitlyTypedOrNotToBeTyped := declarations keys asSet. effectiveNodes := Dictionary new. "this for debugging" parseTree nodesDo: [:node| | type var | "If there is something of the form i >= 0, then i should be signed, not unsigned." (node isSend and: [(locals includes: (var := node receiver variableNameOrNil)) and: [(alreadyExplicitlyTypedOrNotToBeTyped includes: var) not "don't be fooled by inferred unsigned types" and: [(#(<= < >= >) includes: node selector) and: [node args first isConstant and: [node args first value = 0 and: [(type := self typeFor: var in: aCodeGen) notNil and: [type first == $u]]]]]]]) ifTrue: [self declarationAt: var put: (aCodeGen signedTypeForIntegralType: type), ' ', var. effectiveNodes at: var put: { declarations at: var. node }]. "if an assignment to an untyped local of a known type, set the local's type to that type. Only observe known sends (methods in the current set) and typed local variables." (node isAssignment and: [(locals includes: (var := node variable name)) and: [(alreadyExplicitlyTypedOrNotToBeTyped includes: var) not]]) ifTrue: "don't be fooled by previously inferred types" [type := node expression isSend + ifTrue: [aCodeGen returnTypeForSend: node expression in: self ifNil: nil] - ifTrue: [aCodeGen returnTypeOrNilForSend: node expression in: self] ifFalse: [self typeFor: node expression in: aCodeGen]. type "If untyped, then cannot type the variable yet. A subsequent assignment may assign a subtype of what this type ends up being" ifNil: [alreadyExplicitlyTypedOrNotToBeTyped add: var] ifNotNil: "Merge simple types; complex types must be defined by the programmer." [(aCodeGen isSimpleType: type) ifTrue: [aCodeGen mergeTypeOf: var in: declarations with: type method: self. effectiveNodes at: var put: { declarations at: var. node }, (effectiveNodes at: var ifAbsent: [#()])]]]]. ^effectiveNodes! Item was changed: ----- Method: TMethod>>isNode:substitutableFor:inMethod:in: (in category 'inlining') ----- isNode: aNode substitutableFor: argName inMethod: targetMeth in: aCodeGen "Answer if the given parameter node may be substituted directly into the body of the method during inlining, instead of being bound to the actual parameter variable. We allow a constant, a local variable, or a formal parameter, or simple expressions involving only these to to be directly substituted. Note that global variables cannot be subsituted into methods with possible side effects (i.e., methods that may assign to global variables) because the inlined method might depend on having the value of the global variable captured when it is passed in as an argument." | madeNonTrivialCall count constantExpression usageCount | aNode isConstant ifTrue: [^true]. aNode isVariable ifTrue: [((locals includes: aNode name) or: [(args includes: aNode name) or: [#('self' 'true' 'false' 'nil') includes: aNode name]]) ifTrue: [^true]. "We can substitute any variable provided it is only read in the method being inlined, and if it is not read after any non-trivial call (which may update the variable)." madeNonTrivialCall := false. (targetMeth isComplete and: [targetMeth parseTree noneSatisfy: [:node| (node isSend and: [(aCodeGen isBuiltinSelector: node selector) not]) ifTrue: [madeNonTrivialCall := true]. (madeNonTrivialCall and: [node isVariable and: [node name = argName]]) or: [node isAssignment and: [node variable name = argName]]] unless: [:node| node isSend and: [aCodeGen isAssertSelector: node selector]]]) ifTrue: [^true]. ^targetMeth maySubstituteGlobal: aNode name in: aCodeGen]. "don't much up asserts with complex expansions" (targetMeth usesVariableUninlinably: argName in: aCodeGen) ifTrue: [^false]. "For now allow literal blocks to be substituted. They better be accessed only with value[:value:*] messages though!!" aNode isStmtList ifTrue: [^true]. "Don't inline expressions unless type-compatible," aNode isSend ifTrue: [(aCodeGen + isActualType: (aCodeGen returnTypeForSend: aNode in: self ifNil: #incompatible) - isActualType: (aCodeGen returnTypeForSend: aNode in: self) compatibleWithFormalType: (self typeFor: argName in: aCodeGen)) ifFalse: [^false]]. count := 0. constantExpression := true. "scan expression tree; must contain only constants, builtin ops, and inlineable vars" aNode nodesDo: [:node| node isConstant ifTrue: [] ifFalse: [node isSend ifTrue: [((VMBasicConstants mostBasicConstantSelectors includes: node selector) or: [node isBuiltinOperator]) ifFalse: [^false]. count := count + 1] ifFalse: [node isVariable ifTrue: [(aCodeGen isNonArgumentImplicitReceiverVariableName: node name) ifFalse: [constantExpression := false. ((locals includes: node name) or: [(args includes: node name) or: [(#('self' 'true' 'false' 'nil') includes: node name) or: [targetMeth maySubstituteGlobal: node name in: aCodeGen]]]) ifFalse: [^false]]] ifFalse: [^false]]]]. "inline constant expressions" constantExpression ifNil: [^true]. "scan target to find usage count" usageCount := 0. targetMeth parseTree nodesDo: [:node| (node isVariable and: [node name = argName]) ifTrue: [usageCount := usageCount + 1]]. "(usageCount > 1 and: [count <= usageCount]) ifTrue: [[UsageCounts := Dictionary new. self removeClassVarName: #UsageCounts]. (UsageCounts at: usageCount ifAbsentPut: [Set new]) add: ({targetMeth. argName. aNode})]." "Now only inline expressions if they are used only once or are simple w.r.t. the usage count, and the usage count is not large; a heuristic that seems to work well enough." ^usageCount = 1 or: [usageCount <= 7 and: [count <= usageCount]]! Item was changed: ----- Method: TMethod>>returnType: (in category 'accessing') ----- returnType: aString "Set the type of the values returned by this method. This string will be used in the C declaration of this function. If the type exists as a symbol, use that." + returnType := aString isSymbol + ifTrue: [aString] + ifFalse: [(Symbol findInterned: aString) ifNil: [aString]]! - returnType := (Symbol findInterned: aString) ifNil: [aString]! Item was added: + ----- Method: TMethod>>returnsExpression (in category 'testing') ----- + returnsExpression + "Answer true if the last statement of this method is a return of some expression, not merely self or nil." + + ^parseTree returnsExpression! Item was added: + ----- Method: TMethod>>transformReturns (in category 'type inference') ----- + transformReturns + "Once the return type has been found or inferred, returns may bneed to be modified. + If the return type is #void, any occurrences of ^expr must be replaced with expr. ^self. + If the type is #sqInt any any occurrences of ^self are replaced with ^0." + (returnType == #void or: [returnType == #sqInt]) ifFalse: + [^self]. + parseTree nodesWithParentsDo: + [:node :parent| + node isReturn ifTrue: + [(node expression isVariable and: [node expression name = 'self']) + ifTrue: + [returnType = #sqInt ifTrue: + [node setExpression: (TConstantNode new setValue: 0)]] + ifFalse: + [returnType = #void ifTrue: + [parent + replaceChild: node + with: (TStmtListNode new + setArguments: #() + statements: {node expression. + TReturnNode new + setExpression: (TVariableNode new setName: 'self') + yourself})]]]]! Item was removed: - ----- Method: TMethod>>transformVoidReturns (in category 'type inference') ----- - transformVoidReturns - "Once the return type has been found or inferred to be #void, - any occurrences of ^expr must be replaced with expr. ^self." - self assert: returnType == #void. - parseTree nodesWithParentsDo: - [:node :parent| - (node isReturn - and: [node expression isVariable not - or: [node expression name ~= 'self']]) ifTrue: - [parent - replaceChild: node - with: (TStmtListNode new - setArguments: #() - statements: {node expression. - TReturnNode new - setExpression: (TVariableNode new setName: 'self') - yourself})]]! Item was changed: ----- Method: TSendNode>>typeOrNilFrom:in: (in category 'type inference') ----- typeOrNilFrom: aCodeGenerator in: aTMethod + ^aCodeGenerator returnTypeForSend: self in: aTMethod ifNil: nil! - ^aCodeGenerator returnTypeOrNilForSend: self in: aTMethod! Item was added: + ----- Method: TStmtListNode>>returnsExpression (in category 'testing') ----- + returnsExpression + "Answer true if the last statement of this block is a return of some expression, not merely self or nil." + + statements isEmpty ifTrue: + [^false]. + statements last isReturn ifFalse: + [^false]. + statements last isVariable ifFalse: + [^true]. + ^statements last variable ~= 'self' + and: [statements last variable ~= 'nil']! Item was changed: ----- Method: TStmtListNode>>typeOrNilFrom:in: (in category 'type inference') ----- typeOrNilFrom: aCodeGenerator in: aTMethod + ^statements isEmpty ifFalse: + [statements last typeOrNilFrom: aCodeGenerator in: aTMethod]! - statements isEmpty ifTrue: [^nil]. - ^statements last typeOrNilFrom: aCodeGenerator in: aTMethod! Item was changed: ----- Method: VMMaker>>buildCodeGeneratorForCogit (in category 'generate sources') ----- buildCodeGeneratorForCogit "Answer the code generator for translating the cogit." + ^(Smalltalk classNamed: #CurrentReadOnlySourceFiles) + ifNil: [self + buildCodeGeneratorForCogit: self interpreterClass cogitClass + includeAPIMethods: true + initializeClasses: true] + ifNotNil: + [:crosf| + crosf cacheDuring: + [self + buildCodeGeneratorForCogit: self interpreterClass cogitClass + includeAPIMethods: true + initializeClasses: true]]! - ^self - buildCodeGeneratorForCogit: self interpreterClass cogitClass - includeAPIMethods: true - initializeClasses: true! Item was changed: ----- Method: VMMaker>>buildCodeGeneratorForInterpreter (in category 'generate sources') ----- buildCodeGeneratorForInterpreter "Answer the code generator for translating the interpreter." + ^(Smalltalk classNamed: #CurrentReadOnlySourceFiles) + ifNil: [self + buildCodeGeneratorForInterpreter: self interpreterClass + includeAPIMethods: true + initializeClasses: true] + ifNotNil: + [:crosf| + crosf cacheDuring: + [self + buildCodeGeneratorForInterpreter: self interpreterClass + includeAPIMethods: true + initializeClasses: true]]! - ^self - buildCodeGeneratorForInterpreter: self interpreterClass - includeAPIMethods: true - initializeClasses: true! From commits at squeakvm.org Wed Jun 8 18:21:52 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Wed Jun 8 18:21:42 2016 Subject: [Vm-dev] [commit][3740] CogVM source as per VMMaker.oscog-eem.1886 Message-ID: Revision: 3740 Author: eliot Date: 2016-06-08 11:21:49 -0700 (Wed, 08 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1886 Slang: Fix type inferrence for the 64-bit VM and some other cases after the bug fix in VMMaker.oscog-eem.1883 uncovers bugs in existing code. Add ImmX11Plugin to the linux squeak builds. Modified Paths: -------------- branches/Cog/build.linux32ARM/squeak.cog.spur/plugins.ext branches/Cog/build.linux32ARM/squeak.stack.spur/plugins.ext branches/Cog/build.linux32ARM/squeak.stack.v3/plugins.ext branches/Cog/build.linux32x86/squeak.cog.spur/plugins.ext branches/Cog/build.linux32x86/squeak.cog.spur.immutability/plugins.ext branches/Cog/build.linux32x86/squeak.cog.v3/plugins.ext branches/Cog/build.linux32x86/squeak.sista.spur/plugins.ext branches/Cog/build.linux32x86/squeak.stack.spur/plugins.ext branches/Cog/build.linux32x86/squeak.stack.v3/plugins.ext branches/Cog/build.linux64x64/squeak.cog.spur/plugins.ext branches/Cog/build.linux64x64/squeak.cog.spur.immutability/plugins.ext branches/Cog/build.linux64x64/squeak.stack.spur/plugins.ext branches/Cog/nsspur64src/vm/cogit.h branches/Cog/nsspur64src/vm/cogitX64.c branches/Cog/nsspur64src/vm/cointerp.c branches/Cog/nsspur64src/vm/cointerp.h branches/Cog/nsspur64src/vm/gcc3x-cointerp.c branches/Cog/nsspursrc/vm/cogit.h branches/Cog/nsspursrc/vm/cogitARMv5.c branches/Cog/nsspursrc/vm/cogitIA32.c branches/Cog/nsspursrc/vm/cogitMIPSEL.c branches/Cog/nsspursrc/vm/cointerp.c branches/Cog/nsspursrc/vm/cointerp.h branches/Cog/nsspursrc/vm/gcc3x-cointerp.c branches/Cog/nsspurstack64src/vm/gcc3x-interp.c branches/Cog/nsspurstack64src/vm/interp.c branches/Cog/nsspurstacksrc/vm/gcc3x-interp.c branches/Cog/nsspurstacksrc/vm/interp.c branches/Cog/spur64src/vm/cogit.h branches/Cog/spur64src/vm/cogitX64.c branches/Cog/spur64src/vm/cointerp.c branches/Cog/spur64src/vm/cointerp.h branches/Cog/spur64src/vm/gcc3x-cointerp.c branches/Cog/spursistasrc/vm/cogit.h branches/Cog/spursistasrc/vm/cogitARMv5.c branches/Cog/spursistasrc/vm/cogitIA32.c branches/Cog/spursistasrc/vm/cogitMIPSEL.c branches/Cog/spursistasrc/vm/cointerp.c branches/Cog/spursistasrc/vm/cointerp.h branches/Cog/spursistasrc/vm/gcc3x-cointerp.c branches/Cog/spursrc/vm/cogit.h branches/Cog/spursrc/vm/cogitARMv5.c branches/Cog/spursrc/vm/cogitIA32.c branches/Cog/spursrc/vm/cogitMIPSEL.c branches/Cog/spursrc/vm/cointerp.c branches/Cog/spursrc/vm/cointerp.h branches/Cog/spursrc/vm/gcc3x-cointerp.c branches/Cog/spurstack64src/vm/gcc3x-interp.c branches/Cog/spurstack64src/vm/interp.c branches/Cog/spurstacksrc/vm/gcc3x-interp.c branches/Cog/spurstacksrc/vm/interp.c branches/Cog/src/plugins/B2DPlugin/B2DPlugin.c branches/Cog/src/plugins/BitBltPlugin/BitBltPlugin.c branches/Cog/src/plugins/DSAPrims/DSAPrims.c branches/Cog/src/plugins/FFTPlugin/FFTPlugin.c branches/Cog/src/plugins/FloatMathPlugin/FloatMathPlugin.c branches/Cog/src/plugins/GeniePlugin/GeniePlugin.c branches/Cog/src/plugins/JPEGReaderPlugin/JPEGReaderPlugin.c branches/Cog/src/plugins/LargeIntegers/LargeIntegers.c branches/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c branches/Cog/src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c branches/Cog/src/plugins/ZipPlugin/ZipPlugin.c branches/Cog/src/vm/cogit.h branches/Cog/src/vm/cogitARMv5.c branches/Cog/src/vm/cogitIA32.c branches/Cog/src/vm/cogitMIPSEL.c branches/Cog/src/vm/cointerp.c branches/Cog/src/vm/cointerp.h branches/Cog/src/vm/cointerpmt.c branches/Cog/src/vm/cointerpmt.h branches/Cog/src/vm/gcc3x-cointerp.c branches/Cog/src/vm/gcc3x-cointerpmt.c branches/Cog/stacksrc/vm/gcc3x-interp.c branches/Cog/stacksrc/vm/interp.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Modified: branches/Cog/build.linux32ARM/squeak.cog.spur/plugins.ext =================================================================== --- branches/Cog/build.linux32ARM/squeak.cog.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32ARM/squeak.cog.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -11,4 +11,5 @@ UnixOSProcessPlugin \ UUIDPlugin \ WeDoPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32ARM/squeak.stack.spur/plugins.ext =================================================================== --- branches/Cog/build.linux32ARM/squeak.stack.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32ARM/squeak.stack.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -6,4 +6,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32ARM/squeak.stack.v3/plugins.ext =================================================================== --- branches/Cog/build.linux32ARM/squeak.stack.v3/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32ARM/squeak.stack.v3/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -6,4 +6,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32x86/squeak.cog.spur/plugins.ext =================================================================== --- branches/Cog/build.linux32x86/squeak.cog.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32x86/squeak.cog.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -10,4 +10,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32x86/squeak.cog.spur.immutability/plugins.ext =================================================================== --- branches/Cog/build.linux32x86/squeak.cog.spur.immutability/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32x86/squeak.cog.spur.immutability/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -10,4 +10,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32x86/squeak.cog.v3/plugins.ext =================================================================== --- branches/Cog/build.linux32x86/squeak.cog.v3/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32x86/squeak.cog.v3/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -8,4 +8,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32x86/squeak.sista.spur/plugins.ext =================================================================== --- branches/Cog/build.linux32x86/squeak.sista.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32x86/squeak.sista.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -8,4 +8,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32x86/squeak.stack.spur/plugins.ext =================================================================== --- branches/Cog/build.linux32x86/squeak.stack.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32x86/squeak.stack.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -7,4 +7,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux32x86/squeak.stack.v3/plugins.ext =================================================================== --- branches/Cog/build.linux32x86/squeak.stack.v3/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux32x86/squeak.stack.v3/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -7,4 +7,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux64x64/squeak.cog.spur/plugins.ext =================================================================== --- branches/Cog/build.linux64x64/squeak.cog.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux64x64/squeak.cog.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -7,4 +7,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux64x64/squeak.cog.spur.immutability/plugins.ext =================================================================== --- branches/Cog/build.linux64x64/squeak.cog.spur.immutability/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux64x64/squeak.cog.spur.immutability/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -7,4 +7,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/build.linux64x64/squeak.stack.spur/plugins.ext =================================================================== --- branches/Cog/build.linux64x64/squeak.stack.spur/plugins.ext 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/build.linux64x64/squeak.stack.spur/plugins.ext 2016-06-08 18:21:49 UTC (rev 3740) @@ -7,4 +7,5 @@ UnicodePlugin \ UnixOSProcessPlugin \ UUIDPlugin \ +ImmX11Plugin \ XDisplayControlPlugin Modified: branches/Cog/nsspur64src/vm/cogit.h =================================================================== --- branches/Cog/nsspur64src/vm/cogit.h 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/nsspur64src/vm/cogit.h 2016-06-08 18:21:49 UTC (rev 3740) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 + CCodeGenerator VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 */ Modified: branches/Cog/nsspur64src/vm/cogitX64.c =================================================================== --- branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-07 22:35:56 UTC (rev 3739) +++ branches/Cog/nsspur64src/vm/cogitX64.c 2016-06-08 18:21:49 UTC (rev 3740) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 + CCodeGenerator VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 from - StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 + StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1885 uuid: 3c9ce24b-d7c4-4160-ac59-56aed18461a1 " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -441,7 +441,7 @@ static usqInt NoDbgRegParms inlineCacheTagAt(AbstractInstruction * self_in_inlineCacheTagAt, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms isPCDependent(AbstractInstruction * self_in_isPCDependent); static usqInt NoDbgRegParms literal32BeforeFollowingAddress(AbstractInstruction * self_in_literal32BeforeFollowingAddress, sqInt followingAddress); -static void NoDbgRegParms literalBeforeFollowingAddress(AbstractInstruction * self_in_literalBeforeFollowingAddress, sqInt followingAddress); +static sqInt NoDbgRegParms literalBeforeFollowingAddress(AbstractInstruction * self_in_literalBeforeFollowingAddress, sqInt followingAddress); static sqInt NoDbgRegParms loadLiteralByteSize(AbstractInstruction * self_in_loadLiteralByteSize); static usqInt NoDbgRegParms sizePCDependentInstructionAt(AbstractInstruction * self_in_sizePCDependentInstructionAt, sqInt eventualAbsoluteAddress); static AbstractInstruction * NoDbgRegParms storeLiteralbeforeFollowingAddress(AbstractInstruction * self_in_storeLiteralbeforeFollowingAddress, sqInt literal, sqInt followingAddress); @@ -892,7 +892,7 @@ static SimStackEntry * NoDbgRegParms storeToReg(SimStackEntry * self_in_storeToReg, sqInt reg); static sqInt NoDbgRegParms isMergeFixup(BytecodeFixup * self_in_isMergeFixup); static sqInt NoDbgRegParms availableRegisterOrNoneFor(AbstractInstruction * self_in_availableRegisterOrNoneFor, sqInt liveRegsMask); -static void NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress); +static sqInt NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms callInstructionByteSize(AbstractInstruction * self_in_callInstructionByteSize); static sqInt NoDbgRegParms callTargetFromReturnAddress(AbstractInstruction * self_in_callTargetFromReturnAddress, sqInt callSiteReturnAddress); static sqInt NoDbgRegParms cmpC32RTempByteSize(AbstractInstruction * self_in_cmpC32RTempByteSize); @@ -939,7 +939,7 @@ static usqInt NoDbgRegParms machineCodeAt(AbstractInstruction * self_in_machineCodeAt, sqInt anOffset); static sqInt NoDbgRegParms machineCodeBytes(AbstractInstruction * self_in_machineCodeBytes); static sqInt NoDbgRegParms modRMRO(AbstractInstruction * self_in_modRMRO, sqInt mod, sqInt regMode, sqInt regOpcode); -static void NoDbgRegParms nsSendCacheAt(AbstractInstruction * self_in_nsSendCacheAt, char *callSiteReturnAddress); +static sqInt NoDbgRegParms nsSendCacheAt(AbstractInstruction * self_in_nsSendCacheAt, char *callSiteReturnAddress); static sqInt NoDbgRegParms numIntRegArgs(AbstractInstruction * self_in_numIntRegArgs); static AbstractInstruction * NoDbgRegParms padIfPossibleWithStopsFromto(AbstractInstruction * self_in_padIfPossibleWithStopsFromto, sqInt startAddr, sqInt endAddr); static AbstractInstruction * NoDbgRegParms relocateCallBeforeReturnPCby(AbstractInstruction * self_in_relocateCallBeforeReturnPCby, sqInt retpc, sqInt delta); @@ -2360,7 +2360,7 @@ least 16rC0. */ /* CogInLineLiteralsX64Compiler>>#literalBeforeFollowingAddress: */ -static void NoDbgRegParms +static sqInt NoDbgRegParms literalBeforeFollowingAddress(AbstractInstruction * self_in_literalBeforeFollowingAddress, sqInt followingAddress) { sqInt base; @@ -2374,8 +2374,7 @@ ? 9 : 10) : 11)); - unalignedLongAt(base); - return; + return unalignedLongAt(base); } /* CogInLineLiteralsX64Compiler>>#loadLiteralByteSize */ @@ -8686,7 +8685,7 @@ void printPCMapPairsFor(CogMethod *cogMethod) { - sqInt annotation; + unsigned char annotation; usqInt map; unsigned char mapByte; usqInt mcpc; @@ -13010,6 +13009,7 @@ sqInt quickConstant5; sqInt quickConstant6; sqInt quickConstant7; + sqInt quickConstant8; /* begin genLoadArgAtDepth:into: */ assert(1 < (numRegArgs())); @@ -13025,9 +13025,9 @@ # if IMMUTABILITY genGetFormatOfintoleastSignificantHalfOfBaseHeaderIntoScratch(ReceiverResultReg, (formatReg = SendNumArgsReg), TempReg); /* begin genJumpBaseHeaderImmutable: */ - quickConstant7 = immutableBitMask(); + quickConstant8 = immutableBitMask(); /* begin gen:quickConstant:operand: */ - anInstruction18 = genoperandoperand(TstCqR, quickConstant7, TempReg); + anInstruction18 = genoperandoperand(TstCqR, quickConstant8, TempReg); /* begin JumpNonZero: */ jumpImmutable = genConditionalBranchoperand(JumpNonZero, ((sqInt)0)); @@ -13119,7 +13119,9 @@ /* begin JumpBelow: */ jumpNotIndexableBits = genConditionalBranchoperand(JumpBelow, ((sqInt)0)); /* begin CmpCq:R: */ - anInstruction9 = genoperandoperand(CmpCqR, (((sqInt)0xFFFFFFFFU << 3) | 1), Arg1Reg); + quickConstant6 = (((sqInt)0xFFFFFFFFU << 3) | 1); + /* begin gen:quickConstant:operand: */ + anInstruction9 = genoperandoperand(CmpCqR, quickConstant6, Arg1Reg); /* begin JumpAbove: */ jumpWordsOutOfRange = genConditionalBranchoperand(JumpAbove, ((sqInt)0)); /* begin LogicalShiftLeftCq:R: */ @@ -13158,9 +13160,9 @@ /* begin JumpBelowOrEqual: */ jumpBytesOutOfBounds = genConditionalBranchoperand(JumpBelowOrEqual, ((sqInt)0)); /* begin CmpCq:R: */ - quickConstant6 = firstCompiledMethodFormat(); + quickConstant7 = firstCompiledMethodFormat(); /* begin gen:quickConstant:operand: */ - anInstruction12 = genoperandoperand(CmpCqR, quickConstant6, formatReg); + anInstruction12 = genoperandoperand(CmpCqR, quickConstant7, formatReg); /* begin JumpAboveOrEqual: */ jumpIsCompiledMethod = genConditionalBranchoperand(JumpAboveOrEqual, ((sqInt)0)); /* begin MoveR:R: */ @@ -13551,6 +13553,7 @@ sqInt quickConstant; sqInt quickConstant1; sqInt quickConstant10; + sqInt quickConstant11; sqInt quickConstant2; sqInt quickConstant3; sqInt quickConstant4; @@ -13635,7 +13638,9 @@ /* begin JumpNonZero: */ jumpFailCuzFixed = genConditionalBranchoperand(JumpNonZero, ((sqInt)0)); /* begin CmpCq:R: */ - anInstruction5 = genoperandoperand(CmpCqR, ((maxSlots << 3) | 1), Arg0Reg); + quickConstant6 = ((maxSlots << 3) | 1); + /* begin gen:quickConstant:operand: */ + anInstruction5 = genoperandoperand(CmpCqR, quickConstant6, Arg0Reg); /* begin JumpAbove: */ jumpLongTooBig = genConditionalBranchoperand(JumpAbove, ((sqInt)0)); /* begin MoveR:R: */ @@ -13647,8 +13652,8 @@ /* begin AndCq:R: */ anInstruction6 = genoperandoperand(AndCqR, (BytesPerWord / 4) - 1, TempReg); /* begin LogicalShiftLeftCq:R: */ - quickConstant6 = formatShift(); - genoperandoperand(LogicalShiftLeftCqR, quickConstant6, TempReg); + quickConstant7 = formatShift(); + genoperandoperand(LogicalShiftLeftCqR, quickConstant7, TempReg); /* begin AddR:R: */ genoperandoperand(AddRR, TempReg, headerReg); /* begin AddCq:R: */ @@ -13671,8 +13676,8 @@ /* begin AndCq:R: */ anInstruction8 = genoperandoperand(AndCqR, BytesPerWord - 1, TempReg); /* begin LogicalShiftLeftCq:R: */ - quickConstant7 = formatShift(); - genoperandoperand(LogicalShiftLeftCqR, quickConstant7, TempReg); + quickConstant8 = formatShift(); + genoperandoperand(LogicalShiftLeftCqR, quickConstant8, TempReg); /* begin AddR:R: */ genoperandoperand(AddRR, TempReg, headerReg); /* begin AddCq:R: */ @@ -13689,15 +13694,15 @@ /* begin MoveR:R: */ genoperandoperand(MoveRR, fillReg, instSpecReg); /* begin MoveCq:R: */ - quickConstant10 = nilObject(); + quickConstant11 = nilObject(); /* begin gen:quickConstant:operand: */ - anInstruction18 = genoperandoperand(MoveCqR, quickConstant10, fillReg); + anInstruction18 = genoperandoperand(MoveCqR, quickConstant11, fillReg); jmpTarget(jumpBytePrepDone, jmpTarget(jumpLongPrepDone, gLabel())); /* begin MoveR:R: */ genoperandoperand(MoveRR, instSpecReg, TempReg); /* begin LogicalShiftLeftCq:R: */ - quickConstant8 = numSlotsFullShift(); - genoperandoperand(LogicalShiftLeftCqR, quickConstant8, TempReg); + quickConstant9 = numSlotsFullShift(); + genoperandoperand(LogicalShiftLeftCqR, quickConstant9, TempReg); /* begin AddR:R: */ genoperandoperand(AddRR, TempReg, headerReg); /* begin CmpCq:R: */ @@ -13713,9 +13718,9 @@ genoperandoperand(LogicalShiftLeftCqR, shiftForWord(), byteSizeReg); jmpTarget(skip, gAddRR(Arg1Reg, byteSizeReg)); /* begin CmpCq:R: */ - quickConstant9 = getScavengeThreshold(); + quickConstant10 = getScavengeThreshold(); /* begin gen:quickConstant:operand: */ - anInstruction11 = genoperandoperand(CmpCqR, quickConstant9, byteSizeReg); + anInstruction11 = genoperandoperand(CmpCqR, quickConstant10, byteSizeReg); /* begin JumpAboveOrEqual: */ jumpNoSpace = genConditionalBranchoperand(JumpAboveOrEqual, ((sqInt)0)); /* begin MoveR:R: */ @@ -13971,13 +13976,13 @@ AbstractInstruction *jumpUnhashed; sqInt literal; sqInt literal1; - sqInt literal2; sqInt maxSlots; sqInt quickConstant; sqInt quickConstant1; sqInt quickConstant10; sqInt quickConstant11; sqInt quickConstant12; + sqInt quickConstant13; sqInt quickConstant2; sqInt quickConstant3; sqInt quickConstant4; @@ -14054,8 +14059,9 @@ /* begin JumpNonZero: */ jumpFailCuzFixed = genConditionalBranchoperand(JumpNonZero, ((sqInt)0)); /* begin CmpCq:R: */ - literal = (((maxSlots * 2) << 3) | 1); - anInstruction5 = genoperandoperand(CmpCqR, (((maxSlots * 2) << 3) | 1), Arg0Reg); + quickConstant6 = (((maxSlots * 2) << 3) | 1); + /* begin gen:quickConstant:operand: */ + anInstruction5 = genoperandoperand(CmpCqR, quickConstant6, Arg0Reg); /* begin JumpAbove: */ jumpLongTooBig = genConditionalBranchoperand(JumpAbove, ((sqInt)0)); /* begin MoveR:R: */ @@ -14065,18 +14071,18 @@ /* begin SubR:R: */ genoperandoperand(SubRR, instSpecReg, TempReg); /* begin AndCq:R: */ - quickConstant6 = (BytesPerWord / 4) - 1; + quickConstant7 = (BytesPerWord / 4) - 1; /* begin gen:quickConstant:operand: */ - anInstruction7 = genoperandoperand(AndCqR, quickConstant6, TempReg); + anInstruction7 = genoperandoperand(AndCqR, quickConstant7, TempReg); /* begin LogicalShiftLeftCq:R: */ - quickConstant7 = formatShift(); - genoperandoperand(LogicalShiftLeftCqR, quickConstant7, TempReg); + quickConstant8 = formatShift(); + genoperandoperand(LogicalShiftLeftCqR, quickConstant8, TempReg); /* begin AddR:R: */ genoperandoperand(AddRR, TempReg, headerReg); /* begin AddCq:R: */ - quickConstant8 = (BytesPerWord / 4) - 1; + quickConstant9 = (BytesPerWord / 4) - 1; /* begin gen:quickConstant:operand: */ - anInstruction8 = genoperandoperand(AddCqR, quickConstant8, instSpecReg); + anInstruction8 = genoperandoperand(AddCqR, quickConstant9, instSpecReg); /* begin LogicalShiftRightCq:R: */ genoperandoperand(LogicalShiftRightCqR, (shiftForWord()) - 2, instSpecReg); /* begin MoveCq:R: */ @@ -14093,15 +14099,15 @@ /* begin SubR:R: */ genoperandoperand(SubRR, instSpecReg, TempReg); /* begin AndCq:R: */ - literal1 = BytesPerWord - 1; + literal = BytesPerWord - 1; anInstruction11 = genoperandoperand(AndCqR, BytesPerWord - 1, TempReg); /* begin LogicalShiftLeftCq:R: */ - quickConstant9 = formatShift(); - genoperandoperand(LogicalShiftLeftCqR, quickConstant9, TempReg); + quickConstant10 = formatShift(); + genoperandoperand(LogicalShiftLeftCqR, quickConstant10, TempReg); /* begin AddR:R: */ genoperandoperand(AddRR, TempReg, headerReg); /* begin AddCq:R: */ - literal2 = BytesPerWord - 1; + literal1 = BytesPerWord - 1; anInstruction12 = genoperandoperand(AddCqR, BytesPerWord - 1, instSpecReg); /* begin LogicalShiftRightCq:R: */ genoperandoperand(LogicalShiftRightCqR, shiftForWord(), instSpecReg); @@ -14115,15 +14121,15 @@ /* begin MoveR:R: */ genoperandoperand(MoveRR, fillReg, instSpecReg); /* begin MoveCq:R: */ - quickConstant12 = nilObject(); + quickConstant13 = nilObject(); /* begin gen:quickConstant:operand: */ - anInstruction14 = genoperandoperand(MoveCqR, quickConstant12, fillReg); + anInstruction14 = genoperandoperand(MoveCqR, quickConstant13, fillReg); jmpTarget(jumpBytePrepDone, jmpTarget(jumpLongPrepDone, gLabel())); /* begin MoveR:R: */ genoperandoperand(MoveRR, instSpecReg, TempReg); /* begin LogicalShiftLeftCq:R: */ - quickConstant10 = numSlotsFullShift(); - genoperandoperand(LogicalShiftLeftCqR, quickConstant10, TempReg); + quickConstant11 = numSlotsFullShift(); + genoperandoperand(LogicalShiftLeftCqR, quickConstant11, TempReg); /* begin AddR:R: */ genoperandoperand(AddRR, TempReg, headerReg); /* begin CmpCq:R: */ @@ -14139,9 +14145,9 @@ genoperandoperand(LogicalShiftLeftCqR, shiftForWord(), byteSizeReg); jmpTarget(skip, gAddRR(Arg1Reg, byteSizeReg)); /* begin CmpCq:R: */ - quickConstant11 = getScavengeThreshold(); + quickConstant12 = getScavengeThreshold(); /* begin gen:quickConstant:operand: */ - anInstruction17 = genoperandoperand(CmpCqR, quickConstant11, byteSizeReg); + anInstruction17 = genoperandoperand(CmpCqR, quickConstant12, byteSizeReg); /* begin JumpAboveOrEqual: */ jumpNoSpace = genConditionalBranchoperand(JumpAboveOrEqual, ((sqInt)0)); /* begin MoveR:R: */ @@ -14762,7 +14768,7 @@ { AbstractInstruction *anInstruction; AbstractInstruction *anInstruction1; - sqInt mask; + int mask; sqInt rememberedBitByteOffset; rememberedBitByteOffset = (rememberedBitShift()) / 8; @@ -15750,6 +15756,8 @@ usqLong header; sqInt numSlots; sqInt quickConstant; + sqInt quickConstant1; + sqInt quickConstant2; AbstractInstruction *skip; @@ -15787,11 +15795,15 @@ /* begin MoveR:Mw:r: */ anInstruction6 = genoperandoperandoperand(MoveRMwr, ClassReg, (ClosureOuterContextIndex * BytesPerOop) + BaseHeaderSize, ReceiverResultReg); /* begin MoveCq:R: */ - anInstruction7 = genoperandoperand(MoveCqR, ((bcpc << 3) | 1), TempReg); + quickConstant1 = ((bcpc << 3) | 1); + /* begin gen:quickConstant:operand: */ + anInstruction7 = genoperandoperand(MoveCqR, quickConstant1, TempReg); /* begin MoveR:Mw:r: */ anInstruction8 = genoperandoperandoperand(MoveRMwr, TempReg, (ClosureStartPCIndex * BytesPerOop) + BaseHeaderSize, ReceiverResultReg); /* begin MoveCq:R: */ - anInstruction9 = genoperandoperand(MoveCqR, ((numArgs << 3) | 1), TempReg); + quickConstant2 = ((numArgs << 3) | 1); + /* begin gen:quickConstant:operand: */ + anInstruction9 = genoperandoperand(MoveCqR, quickConstant2, TempReg); /* begin MoveR:Mw:r: */ anInstruction10 = genoperandoperandoperand(MoveRMwr, TempReg, (ClosureNumArgsIndex * BytesPerOop) + BaseHeaderSize, ReceiverResultReg); return 0; @@ -15907,6 +15919,7 @@ AbstractInstruction *jumpBounds; AbstractInstruction *jumpNotHeaderIndex; sqInt quickConstant; + sqInt quickConstant1; /* begin genLoadArgAtDepth:into: */ assert(0 < (numRegArgs())); @@ -15914,7 +15927,9 @@ jumpBadIndex = genJumpNotSmallInteger(Arg0Reg); genGetMethodHeaderOfintoscratch(ReceiverResultReg, (headerReg = Arg1Reg), TempReg); /* begin CmpCq:R: */ - anInstruction = genoperandoperand(CmpCqR, (((sqInt)1 << 3) | 1), Arg0Reg); + quickConstant = (((sqInt)1 << 3) | 1); + /* begin gen:quickConstant:operand: */ + anInstruction = genoperandoperand(CmpCqR, quickConstant, Arg0Reg); /* begin JumpNonZero: */ jumpNotHeaderIndex = genConditionalBranchoperand(JumpNonZero, ((sqInt)0)); /* begin MoveR:R: */ @@ -15925,9 +15940,9 @@ genoperand(RetN, 0); jmpTarget(jumpNotHeaderIndex, gAndCqR((((alternateHeaderNumLiteralsMask()) << 3) | 1), headerReg)); /* begin SubCq:R: */ - quickConstant = ((((sqInt)1 << 3) | 1)) - (smallIntegerTag()); + quickConstant1 = ((((sqInt)1 << 3) | 1)) - (smallIntegerTag()); /* begin gen:quickConstant:operand: */ - anInstruction2 = genoperandoperand(SubCqR, quickConstant, Arg0Reg); + anInstruction2 = genoperandoperand(SubCqR, quickConstant1, Arg0Reg); /* begin CmpR:R: */ genoperandoperand(CmpRR, headerReg, Arg0Reg); /* begin JumpAbove: */ @@ -16907,12 +16922,10 @@ */ /* CogX64Compiler>>#callFullTargetFromReturnAddress: */ -static void NoDbgRegParms +static sqInt NoDbgRegParms callFullTargetFromReturnAddress(AbstractInstruction * self_in_callFullTargetFromReturnAddress, sqInt callSiteReturnAddress) { - /* begin sixtyFourBitLiteralBefore: */ - unalignedLongAt((callSiteReturnAddress - 2) - 8); - return; + return unalignedLongAt((callSiteReturnAddress - 2) - 8); } /* CogX64Compiler>>#callInstructionByteSize */ @@ -17801,7 +17814,7 @@ updateLabel(dependentChain, self_in_dispatchConcretize); dependentChain = (dependentChain->dependent); } - ((self_in_dispatchConcretize->machineCodeSize) = 0); + (self_in_dispatchConcretize->machineCodeSize) = 0; return; case AlignmentNops: @@ -17819,20 +17832,20 @@ ((self_in_dispatchConcretize->machineCode))[1] = ((((usqInt) word) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[2] = ((((usqInt) word) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) word) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case Nop: /* begin concretizeNop */ ((self_in_dispatchConcretize->machineCode))[0] = 144; - ((self_in_dispatchConcretize->machineCodeSize) = 1); + (self_in_dispatchConcretize->machineCodeSize) = 1; return; case CDQ: /* begin concretizeCDQ */ ((self_in_dispatchConcretize->machineCode))[0] = 72; ((self_in_dispatchConcretize->machineCode))[1] = 153; - ((self_in_dispatchConcretize->machineCodeSize) = 2); + (self_in_dispatchConcretize->machineCodeSize) = 2; return; case IDIVR: @@ -17841,7 +17854,7 @@ ((self_in_dispatchConcretize->machineCode))[0] = (rexRxb(self_in_dispatchConcretize, 0, 0, regDivisor)); ((self_in_dispatchConcretize->machineCode))[1] = 247; ((self_in_dispatchConcretize->machineCode))[2] = (modRMRO(self_in_dispatchConcretize, ModReg, regDivisor, 7)); - ((self_in_dispatchConcretize->machineCodeSize) = 3); + (self_in_dispatchConcretize->machineCodeSize) = 3; return; case IMULRR: @@ -17852,7 +17865,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 175; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, reg1, reg2)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case XCHGRR: @@ -17868,7 +17881,7 @@ ((self_in_dispatchConcretize->machineCode))[2] = ((((usqInt) offset) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 5); + (self_in_dispatchConcretize->machineCodeSize) = 5; return; case CallFull: @@ -17886,7 +17899,7 @@ ((self_in_dispatchConcretize->machineCode))[9] = ((((usqInt) operand) >> 56) & 0xFF); ((self_in_dispatchConcretize->machineCode))[10] = 0xFF; ((self_in_dispatchConcretize->machineCode))[11] = (modRMRO(self_in_dispatchConcretize, ModReg, RAX, 2)); - ((self_in_dispatchConcretize->machineCodeSize) = 12); + (self_in_dispatchConcretize->machineCodeSize) = 12; return; case JumpR: @@ -17894,7 +17907,7 @@ reg = ((self_in_dispatchConcretize->operands))[0]; ((self_in_dispatchConcretize->machineCode))[0] = 0xFF; ((self_in_dispatchConcretize->machineCode))[1] = (modRMRO(self_in_dispatchConcretize, ModReg, reg, 4)); - ((self_in_dispatchConcretize->machineCodeSize) = 2); + (self_in_dispatchConcretize->machineCodeSize) = 2; return; case JumpFull: @@ -17912,7 +17925,7 @@ ((self_in_dispatchConcretize->machineCode))[9] = ((((usqInt) operand1) >> 56) & 0xFF); ((self_in_dispatchConcretize->machineCode))[10] = 0xFF; ((self_in_dispatchConcretize->machineCode))[11] = (modRMRO(self_in_dispatchConcretize, ModReg, RAX, 4)); - ((self_in_dispatchConcretize->machineCodeSize) = 12); + (self_in_dispatchConcretize->machineCodeSize) = 12; return; case JumpLong: @@ -17929,7 +17942,7 @@ ((self_in_dispatchConcretize->machineCode))[2] = ((((usqInt) offset12) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset12) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset12) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 5); + (self_in_dispatchConcretize->machineCodeSize) = 5; return; case JumpLongZero: @@ -17950,8 +17963,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 4); ((self_in_dispatchConcretize->machineCode))[1] = (offset23 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l69; } /* begin concretizeConditionalJumpLong: */ jumpTarget11 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -17969,7 +17982,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset113) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset113) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset113) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l69: /* end concretizeConditionalJump: */; return; case JumpLongNonZero: @@ -17990,8 +18004,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 5); ((self_in_dispatchConcretize->machineCode))[1] = (offset24 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l74; } /* begin concretizeConditionalJumpLong: */ jumpTarget111 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18009,7 +18023,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset114) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset114) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset114) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l74: /* end concretizeConditionalJump: */; return; case Jump: @@ -18027,8 +18042,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = 235; ((self_in_dispatchConcretize->machineCode))[1] = (offset13 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l52; } offset13 = (((int) jumpTarget1)) - (((int) (((self_in_dispatchConcretize->address)) + 5))); ((self_in_dispatchConcretize->machineCode))[0] = 233; @@ -18036,7 +18051,8 @@ ((self_in_dispatchConcretize->machineCode))[2] = ((((usqInt) offset13) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset13) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset13) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 5); + (self_in_dispatchConcretize->machineCodeSize) = 5; + l52: /* end concretizeJump */; return; case JumpNegative: @@ -18055,8 +18071,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 8); ((self_in_dispatchConcretize->machineCode))[1] = (offset25 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l79; } /* begin concretizeConditionalJumpLong: */ jumpTarget112 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18074,7 +18090,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset115) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset115) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset115) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l79: /* end concretizeConditionalJump: */; return; case JumpNonNegative: @@ -18093,8 +18110,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 9); ((self_in_dispatchConcretize->machineCode))[1] = (offset26 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l84; } /* begin concretizeConditionalJumpLong: */ jumpTarget113 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18112,7 +18129,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset116) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset116) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset116) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l84: /* end concretizeConditionalJump: */; return; case JumpOverflow: @@ -18131,8 +18149,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112); ((self_in_dispatchConcretize->machineCode))[1] = (offset27 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l89; } /* begin concretizeConditionalJumpLong: */ jumpTarget114 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18150,7 +18168,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset117) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset117) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset117) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l89: /* end concretizeConditionalJump: */; return; case JumpNoOverflow: @@ -18169,8 +18188,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 1); ((self_in_dispatchConcretize->machineCode))[1] = (offset28 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l94; } /* begin concretizeConditionalJumpLong: */ jumpTarget115 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18188,7 +18207,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset118) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset118) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset118) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l94: /* end concretizeConditionalJump: */; return; case JumpCarry: @@ -18209,8 +18229,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 2); ((self_in_dispatchConcretize->machineCode))[1] = (offset29 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l99; } /* begin concretizeConditionalJumpLong: */ jumpTarget116 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18228,7 +18248,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset119) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset119) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset119) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l99: /* end concretizeConditionalJump: */; return; case JumpNoCarry: @@ -18249,8 +18270,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 3); ((self_in_dispatchConcretize->machineCode))[1] = (offset30 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l104; } /* begin concretizeConditionalJumpLong: */ jumpTarget117 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18268,7 +18289,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset120) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset120) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset120) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l104: /* end concretizeConditionalJump: */; return; case JumpLess: @@ -18287,8 +18309,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 12); ((self_in_dispatchConcretize->machineCode))[1] = (offset31 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l109; } /* begin concretizeConditionalJumpLong: */ jumpTarget118 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18306,7 +18328,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset121) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset121) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset121) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l109: /* end concretizeConditionalJump: */; return; case JumpGreaterOrEqual: @@ -18325,8 +18348,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 13); ((self_in_dispatchConcretize->machineCode))[1] = (offset32 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l114; } /* begin concretizeConditionalJumpLong: */ jumpTarget1110 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18344,7 +18367,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset122) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset122) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset122) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l114: /* end concretizeConditionalJump: */; return; case JumpGreater: @@ -18363,8 +18387,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 15); ((self_in_dispatchConcretize->machineCode))[1] = (offset33 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l119; } /* begin concretizeConditionalJumpLong: */ jumpTarget1111 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18382,7 +18406,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset123) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset123) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset123) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l119: /* end concretizeConditionalJump: */; return; case JumpLessOrEqual: @@ -18401,8 +18426,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 14); ((self_in_dispatchConcretize->machineCode))[1] = (offset34 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l124; } /* begin concretizeConditionalJumpLong: */ jumpTarget1112 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18420,7 +18445,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset124) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset124) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset124) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l124: /* end concretizeConditionalJump: */; return; case JumpAbove: @@ -18440,8 +18466,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 7); ((self_in_dispatchConcretize->machineCode))[1] = (offset35 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l129; } /* begin concretizeConditionalJumpLong: */ jumpTarget1113 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18459,7 +18485,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset125) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset125) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset125) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l129: /* end concretizeConditionalJump: */; return; case JumpBelowOrEqual: @@ -18479,8 +18506,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 6); ((self_in_dispatchConcretize->machineCode))[1] = (offset36 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l134; } /* begin concretizeConditionalJumpLong: */ jumpTarget1114 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18498,7 +18525,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset126) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset126) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset126) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l134: /* end concretizeConditionalJump: */; return; case JumpFPOrdered: @@ -18517,8 +18545,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 11); ((self_in_dispatchConcretize->machineCode))[1] = (offset37 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l139; } /* begin concretizeConditionalJumpLong: */ jumpTarget1115 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18536,7 +18564,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset127) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset127) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset127) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l139: /* end concretizeConditionalJump: */; return; case JumpFPUnordered: @@ -18555,8 +18584,8 @@ : ((self_in_dispatchConcretize->machineCodeSize)) == 2)) { ((self_in_dispatchConcretize->machineCode))[0] = (112 + 10); ((self_in_dispatchConcretize->machineCode))[1] = (offset38 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 2); - return; + (self_in_dispatchConcretize->machineCodeSize) = 2; + goto l144; } /* begin concretizeConditionalJumpLong: */ jumpTarget1116 = ((AbstractInstruction *) (((self_in_dispatchConcretize->operands))[0])); @@ -18574,7 +18603,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) offset128) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset128) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset128) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); + (self_in_dispatchConcretize->machineCodeSize) = 6; + l144: /* end concretizeConditionalJump: */; return; case RetN: @@ -18582,19 +18612,20 @@ offset1 = ((self_in_dispatchConcretize->operands))[0]; if (offset1 == 0) { ((self_in_dispatchConcretize->machineCode))[0] = 195; - ((self_in_dispatchConcretize->machineCodeSize) = 1); - return; + (self_in_dispatchConcretize->machineCodeSize) = 1; + goto l12; } ((self_in_dispatchConcretize->machineCode))[0] = 194; ((self_in_dispatchConcretize->machineCode))[1] = (offset1 & 0xFF); ((self_in_dispatchConcretize->machineCode))[2] = (((usqInt) offset1) >> 8); - ((self_in_dispatchConcretize->machineCodeSize) = 3); + (self_in_dispatchConcretize->machineCodeSize) = 3; + l12: /* end concretizeRetN */; return; case Stop: /* begin concretizeStop */ ((self_in_dispatchConcretize->machineCode))[0] = 204; - ((self_in_dispatchConcretize->machineCodeSize) = 1); + (self_in_dispatchConcretize->machineCodeSize) = 1; return; case AddCqR: @@ -18617,7 +18648,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 88; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, regRHS, regLHS)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case AndCqR: @@ -18641,8 +18672,8 @@ ((self_in_dispatchConcretize->machineCode))[1] = 246; ((self_in_dispatchConcretize->machineCode))[2] = (modRMRO(self_in_dispatchConcretize, ModReg, reg3, 0)); ((self_in_dispatchConcretize->machineCode))[3] = (value & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 4); - return; + (self_in_dispatchConcretize->machineCodeSize) = 4; + goto l15; } if (is32BitSignedImmediate(self_in_dispatchConcretize, value)) { if (reg3 == RAX) { @@ -18651,8 +18682,8 @@ ((self_in_dispatchConcretize->machineCode))[3] = ((((usqInt) value) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) value) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) value) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 6); - return; + (self_in_dispatchConcretize->machineCodeSize) = 6; + goto l15; } ((self_in_dispatchConcretize->machineCode))[1] = 247; ((self_in_dispatchConcretize->machineCode))[2] = (modRMRO(self_in_dispatchConcretize, ModReg, reg3, 0)); @@ -18660,10 +18691,11 @@ ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) value) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) value) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[6] = ((((usqInt) value) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 7); - return; + (self_in_dispatchConcretize->machineCodeSize) = 7; + goto l15; } concretizeArithCwR(self_in_dispatchConcretize, 133); + l15: /* end concretizeTstCqR */; return; case CmpCqR: @@ -18697,7 +18729,7 @@ ((self_in_dispatchConcretize->machineCode))[skip + 2] = ((((usqInt) value1) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[skip + 3] = ((((usqInt) value1) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[skip + 4] = ((((usqInt) value1) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 5 + skip); + (self_in_dispatchConcretize->machineCodeSize) = 5 + skip; return; case CmpRR: @@ -18712,7 +18744,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 46; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, regRHS1, regLHS1)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case DivRdRd: @@ -18723,7 +18755,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 94; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, regRHS2, regLHS2)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case MulRdRd: @@ -18734,7 +18766,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 89; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, regRHS3, regLHS3)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case OrCqR: @@ -18769,7 +18801,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 92; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, regRHS4, regLHS4)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case SqrtRd: @@ -18779,7 +18811,7 @@ ((self_in_dispatchConcretize->machineCode))[1] = 15; ((self_in_dispatchConcretize->machineCode))[2] = 81; ((self_in_dispatchConcretize->machineCode))[3] = (modRMRO(self_in_dispatchConcretize, ModReg, reg5, reg5)); - ((self_in_dispatchConcretize->machineCodeSize) = 4); + (self_in_dispatchConcretize->machineCodeSize) = 4; return; case XorCwR: @@ -18796,7 +18828,7 @@ ((self_in_dispatchConcretize->machineCode))[0] = (rexRxb(self_in_dispatchConcretize, 0, 0, reg6)); ((self_in_dispatchConcretize->machineCode))[1] = 247; ((self_in_dispatchConcretize->machineCode))[2] = (modRMRO(self_in_dispatchConcretize, ModReg, reg6, 3)); - ((self_in_dispatchConcretize->machineCodeSize) = 3); + (self_in_dispatchConcretize->machineCodeSize) = 3; return; case LoadEffectiveAddressMwrR: @@ -18811,23 +18843,23 @@ if (isQuick(self_in_dispatchConcretize, offset2)) { ((self_in_dispatchConcretize->machineCode))[2] = (modRMRO(self_in_dispatchConcretize, ModRegRegDisp8, srcReg, destReg)); ((self_in_dispatchConcretize->machineCode))[3] = (offset2 & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 4); - return; + (self_in_dispatchConcretize->machineCodeSize) = 4; + goto l23; } ((self_in_dispatchConcretize->machineCode))[2] = (modRMRO(self_in_dispatchConcretize, ModRegRegDisp32, srcReg, destReg)); ((self_in_dispatchConcretize->machineCode))[3] = (offset2 & 0xFF); ((self_in_dispatchConcretize->machineCode))[4] = ((((usqInt) offset2) >> 8) & 0xFF); ((self_in_dispatchConcretize->machineCode))[5] = ((((usqInt) offset2) >> 16) & 0xFF); ((self_in_dispatchConcretize->machineCode))[6] = ((((usqInt) offset2) >> 24) & 0xFF); - ((self_in_dispatchConcretize->machineCodeSize) = 7); - return; + (self_in_dispatchConcretize->machineCodeSize) = 7; + goto l23; } if (isQuick(self_in_dispatchConcretize, offset2)) { @@ Diff output truncated at 50000 characters. @@ From tim at rowledge.org Wed Jun 8 18:42:57 2016 From: tim at rowledge.org (tim Rowledge) Date: Wed Jun 8 18:42:52 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> Message-ID: <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> I finally got a moment to look at this - not that I really have much clue about the whole unix process thing - and it appears that something is odd with the compiled code in the plugin. My test is very simple - run the UnixProcess class>listDirectory example. It exits with a segfault and the forkAndExec? method as the last thing on the stack. I build a debug vm (and had some fun with asserts and the ARM fp offset in the process, all fixed now) and? it doesn?t fail. I?ve tried compiling the plugin with varying levels of optimisation, since we?ve fairly regularly seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. Nice. Ideas? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When all else fails, let a = 7. If that doesn't help, then read the manual. From lewis at mail.msen.com Wed Jun 8 20:49:02 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Jun 8 20:49:04 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> Message-ID: <48534.136.1.1.109.1465418942.squirrel@webmail.msen.com> Oh-oh, I might have to break down and buy a Raspberry Pi :-) Have you (or anyone else) run the OSProcess/CommandShell test suite on a Pi before, or is this the first time someone is looking at it? If it is the first time, then I /strongly/ recommend trying it first on a V3 image with interpreter VM build as per http://wiki.squeak.org/squeak/6354. I'm afraid you will be flying blind if you don't try that first. Dave > > I finally got a moment to look at this - not that I really have much clue > about the whole unix process thing - and it appears that something is odd > with the compiled code in the plugin. > > My test is very simple - run the UnixProcess class>listDirectory example. > It exits with a segfault and the forkAndExec??? method as the last thing > on the stack. > > I build a debug vm (and had some fun with asserts and the ARM fp offset in > the process, all fixed now) and??? it doesn???t fail. I???ve tried > compiling the plugin with varying levels of optimisation, since we???ve > fairly regularly seen problems there, and even at -O0 it fails. So debug > -> OK, no-debug -> boom. Nice. > > Ideas? > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > When all else fails, let a = 7. If that doesn't help, then read the > manual. > > From btc at openinworld.com Thu Jun 9 00:11:04 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 9 00:11:28 2016 Subject: [Vm-dev] Re: [Pharo-dev] [ANN] Ephemeron Support is Ready In-Reply-To: References: <5756949A.9010307@gmail.com> <5757CAFB.9060407@gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 42165 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160609/22c00a33/attachment-0001.png From smalltalk at stefan-marr.de Thu Jun 9 16:59:58 2016 From: smalltalk at stefan-marr.de (Stefan Marr) Date: Thu Jun 9 17:00:01 2016 Subject: [Vm-dev] Call for Participation: 3rd Virtual Machine Meetup, September 1-2, Lugano, Switzerland Message-ID: Call for Participation: VMM?16 ============================== 3rd Virtual Machine Meetup Co-located with PPPJ September 1-2, 2016, Lugano, Switzerland http://vmmeetup.github.io/2016/ The 3rd Virtual Machine Meetup (VMM'16) is a venue for discussing the latest research and developments in the area of managed language execution. It will be held on 1st and 2nd of September at the Universit? della Svizzera italiana (USI), Lugano, Switzerland and is part of the Managed Languages & Runtimes Week 2016 (http://manlang16.inf.usi.ch/, other colocated events are PPPJ'16 and JTRES'16, room Auditorium from 9am - 5pm). We welcome presentations of new research results, experience reports, as well as position statements that can lead to interesting discussions. Topics include, but are not limited to: - Programming language design - Dynamic and static program analysis - Compiler construction - Managed runtime architectures - Data processing engines - Distributed execution environments To participate, please email thomas.wuerthinger@oracle.com stating your wish to attend, and your name and affiliation as you wish to have them on your name badge. There are limited participant slots due to the constraints of the room, so please register early, and by July 20th the latest. If you would like to give a presentation, please email Thomas with a title (max. 100 characters) and abstract (max. 400 characters). We may ask for additional information from you before making the program decision. Presentation slots are either 30 minutes (long) or 15 minutes (short) including Q/A. Important dates: - Submissions: July 10, 2016 - Author notification: July 17, 2016 - Registration for participation: July 20, 2016 - Virtual machine Meetup: Sep 1st + 2nd 2016 at USI Lugano - Social Event: Sep 3rd 2016, optional Program committee: - Stefan Marr, JKU Linz, Austria - Matthias Grimmer, JKU Linz, Austria - Laurence Tratt, King's College London - Thomas Wuerthinger, Oracle Labs Switzerland As an optional social event, we will plan this year for Saturday the 3rd of September a trip to the Lake Como - a gorgeous lake in Italy close to Lugano. Please let us know whether you intend to participate for planning purposes. From commits at squeakvm.org Thu Jun 9 23:07:43 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Thu Jun 9 23:07:32 2016 Subject: [Vm-dev] [commit][3741] Integrate Laura Perez Carrato' s 8- & 16-bit JPEG enhancement support code. Message-ID: Revision: 3741 Author: eliot Date: 2016-06-09 16:07:42 -0700 (Thu, 09 Jun 2016) Log Message: ----------- Integrate Laura Perez Carrato's 8- & 16-bit JPEG enhancement support code. Added Paths: ----------- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c Property Changed: ---------------- trunk/platforms/Cross/plugins/sqPluginsSCCSVersion.h Added: trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c =================================================================== --- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c (rev 0) +++ trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c 2016-06-09 23:07:42 UTC (rev 3741) @@ -0,0 +1,307 @@ +/* sqJPEGReadWriter2Plugin.c + * Cross-platform interface to JPEG processing. + * + * Author: Laura Perez Carrato + * + * Copyright (c) 2013 3D Immersive Collaboration Consulting, LLC. + * + * All rights reserved. + * + * This file is part of Squeak. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ +#include "JPEGReadWriter2Plugin.h" + +/* + * For more info regarding what's being done here, download libjpeg 6b from + * http://www.ijg.org/files/ and take a look at example.c + */ + +void +primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgrWriteScanlines( + unsigned int width, + unsigned int height, + int nativeDepth, + unsigned int* bitmap, + char* jpegCompressStruct, + char* jpegErrorMgr2Struct, + int quality, + int progressiveFlag, + unsigned int pixelsPerWord, + unsigned int wordsPerRow, + char* destination, + unsigned int* destinationSizePtr) +{ + j_compress_ptr pcinfo = (j_compress_ptr)jpegCompressStruct; + error_ptr2 pjerr = (error_ptr2)jpegErrorMgr2Struct; + + pcinfo->err = jpeg_std_error(&pjerr->pub); + pjerr->pub.error_exit = error_exit; + + if (setjmp(pjerr->setjmp_buffer)) { + jpeg_destroy_compress(pcinfo); + + *destinationSizePtr = 0; + } + + if (*destinationSizePtr) { + jpeg_create_compress(pcinfo); + jpeg_mem_dest(pcinfo, destination, destinationSizePtr); + + pcinfo->image_width = width; + pcinfo->image_height = height; + pcinfo->input_components = (abs(nativeDepth) != 8 ? 3 : 1); + pcinfo->in_color_space = (abs(nativeDepth) != 8 ? JCS_RGB : JCS_GRAYSCALE); + jpeg_set_defaults(pcinfo); + if (quality > 0) + jpeg_set_quality (pcinfo, quality, 1); + if (progressiveFlag) + jpeg_simple_progression(pcinfo); + + jpeg_start_compress(pcinfo, TRUE); + + unsigned int rowStride = wordsPerRow * pixelsPerWord * pcinfo->input_components; + + JSAMPARRAY buffer = (*(pcinfo->mem)->alloc_sarray) + ((j_common_ptr) pcinfo, JPOOL_IMAGE, rowStride, 1); + + while (pcinfo->next_scanline < pcinfo->image_height) { + unsigned int i; + unsigned int j; + for(i = 0, j = 0; i < rowStride; i +=(pcinfo->input_components * pixelsPerWord), j++) { + unsigned int bitmapWord = bitmap[pcinfo->next_scanline * wordsPerRow + j]; + + switch (nativeDepth) { + case 32: + case -32: + buffer[0][i] = (bitmapWord >> 16) & 255; + buffer[0][i+1] = (bitmapWord >> 8) & 255; + buffer[0][i+2] = bitmapWord & 255; + break; + case 16: + buffer[0][i] = (bitmapWord >> 23) & 248; + buffer[0][i+1] = (bitmapWord >> 18) & 248; + buffer[0][i+2] = (bitmapWord >> 13) & 248; + buffer[0][i+3] = (bitmapWord >> 7) & 248; + buffer[0][i+4] = (bitmapWord >> 2) & 248; + buffer[0][i+5] = (bitmapWord << 3) & 248; + break; + case -16: + buffer[0][i] = (bitmapWord >> 7) & 248; + buffer[0][i+1] = (bitmapWord >> 2) & 248; + buffer[0][i+2] = (bitmapWord << 3) & 248; + buffer[0][i+3] = (bitmapWord >> 23) & 248; + buffer[0][i+4] = (bitmapWord >> 18) & 248; + buffer[0][i+5] = (bitmapWord >> 13) & 248; + break; + case 8: + buffer[0][i] = (bitmapWord >> 24) & 255; + buffer[0][i+1] = (bitmapWord >> 16) & 255; + buffer[0][i+2] = (bitmapWord >> 8) & 255; + buffer[0][i+3] = bitmapWord & 255; + break; + case -8: + buffer[0][i] = bitmapWord & 255; + buffer[0][i+1] = (bitmapWord >> 8) & 255; + buffer[0][i+2] = (bitmapWord >> 16) & 255; + buffer[0][i+3] = (bitmapWord >> 24) & 255; + break; + } + } + + (void) jpeg_write_scanlines(pcinfo, buffer, 1); + } + + jpeg_finish_compress(pcinfo); + jpeg_destroy_compress(pcinfo); + } +} + +void +primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgrReadScanlines( + char* jpegDecompressStruct, + char* jpegErrorMgr2Struct, + char* source, + unsigned int sourceSize, + int ditherFlag, + unsigned int* bitmap, + unsigned int pixelsPerWord, + unsigned int wordsPerRow, + int nativeDepth) +{ + j_decompress_ptr pcinfo = (j_decompress_ptr)jpegDecompressStruct; + error_ptr2 pjerr = (error_ptr2)jpegErrorMgr2Struct; + + int ok = 1; + pcinfo->err = jpeg_std_error(&pjerr->pub); + pjerr->pub.error_exit = error_exit; + + if (setjmp(pjerr->setjmp_buffer)) { + jpeg_destroy_decompress(pcinfo); + ok = 0; + } + + if (ok) + ok = jpeg_mem_src_newLocationOfData(pcinfo, source, sourceSize); + + if (ok) { + jpeg_start_decompress(pcinfo); + + int depth = abs(nativeDepth); + + unsigned int rowStride = pcinfo->output_width * pcinfo->output_components; + + JSAMPARRAY buffer = (*(pcinfo->mem)->alloc_sarray) + ((j_common_ptr) pcinfo, JPOOL_IMAGE, rowStride, 1); + + int redOffset1, redOffset2; + int greenOffset1, greenOffset2; + int blueOffset1, blueOffset2; + + if (pcinfo->out_color_components == 3) { + redOffset1 = 0; redOffset2 = 3; + greenOffset1 = 1; greenOffset2 = 4; + blueOffset1 = 2; blueOffset2 = 5; + } + else { + redOffset1 = 0; redOffset2 = 1; + greenOffset1 = 0; greenOffset2 = 1; + blueOffset1 = 0; blueOffset2 = 1; + } + + int grayOffset1 = 0; + int grayOffset2 = 1; + int grayOffset3 = 2; + int grayOffset4 = 3; + + // Dither Matrix taken from Form>>orderedDither32To16, but rewritten for this method + int ditherMatrix1[] = { 2, 0, 14, 12, 1, 3, 13, 15 }; + int ditherMatrix2[] = { 10, 8, 6, 4, 9, 11, 5, 7 }; + + while (pcinfo->output_scanline < pcinfo->output_height) { + (void) jpeg_read_scanlines(pcinfo, buffer, 1); + + unsigned int i; + unsigned int j; + + for(i = 0, j = 0; i < rowStride; i +=(pcinfo->out_color_components * pixelsPerWord), j++) { + unsigned int bitmapWord; + + switch (depth) { + case 32: ; + unsigned char red = buffer[0][i+redOffset1]; + unsigned char green = buffer[0][i+greenOffset1]; + unsigned char blue = buffer[0][i+blueOffset1]; + bitmapWord = (255 << 24) | (red << 16) | (green << 8) | blue; + break; + case 16: ; + unsigned char red1 = buffer[0][i+redOffset1]; + unsigned char red2 = buffer[0][i+redOffset2]; + unsigned char green1 = buffer[0][i+greenOffset1]; + unsigned char green2 = buffer[0][i+greenOffset2]; + unsigned char blue1 = buffer[0][i+blueOffset1]; + unsigned char blue2 = buffer[0][i+blueOffset2]; + + if (ditherFlag) { + // Do 4x4 ordered dithering. Taken from Form>>orderedDither32To16 + int dmv1, dmv2, di, dmi, dmo; + dmv1 = ditherMatrix1[((pcinfo->output_scanline & 3) << 1) | (j&1)]; + dmv2 = ditherMatrix2[((pcinfo->output_scanline & 3) << 1) | (j&1)]; + di = (red1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; + red1 = dmv1 < dmi ? dmo+1 : dmo; + di = (green1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; + green1 = dmv1 < dmi ? dmo+1 : dmo; + di = (blue1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; + blue1 = dmv1 < dmi ? dmo+1 : dmo; + di = (red2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; + red2 = dmv2 < dmi ? dmo+1 : dmo; + di = (green2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; + green2 = dmv2 < dmi ? dmo+1 : dmo; + di = (blue2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; + blue2 = dmv2 < dmi ? dmo+1 : dmo; + } + else { + red1 = red1 >> 3; + red2 = red2 >> 3; + green1 = green1 >> 3; + green2 = green2 >> 3; + blue1 = blue1 >> 3; + blue2 = blue2 >> 3; + } + + switch (nativeDepth) { + case 16: + bitmapWord = 32768 | (red1 << 10) | (green1 << 5) | blue1; + bitmapWord = (bitmapWord << 16) | 32768 | (red2 << 10) | (green2 << 5) | blue2; + break; + case -16: + bitmapWord = 32768 | (red2 << 10) | (green2 << 5) | blue2; + bitmapWord = (bitmapWord << 16) | 32768 | (red1 << 10) | (green1 << 5) | blue1; + break; + } + + break; + case 8: ; + unsigned char gray1 = buffer[0][i+grayOffset1]; + unsigned char gray2 = buffer[0][i+grayOffset2]; + unsigned char gray3 = buffer[0][i+grayOffset3]; + unsigned char gray4 = buffer[0][i+grayOffset4]; + switch (nativeDepth) { + case 8: + bitmapWord = gray1 << 24 | gray2 << 16 | gray3 << 8 | gray4; + break; + case -8: + bitmapWord = gray4 << 24 | gray3 << 16 | gray2 << 8 | gray1; + break; + } + break; + } + bitmap[((pcinfo->output_scanline - 1) * wordsPerRow) + j] = bitmapWord; + } + } + jpeg_finish_decompress(pcinfo); + jpeg_destroy_decompress(pcinfo); + } +} + +void +primJPEGReadHeaderfromByteArrayerrorMgrReadHeader ( + char* jpegDecompressStruct, + char* jpegErrorMgr2Struct, + char* source, + unsigned int sourceSize) +{ + j_decompress_ptr pcinfo = (j_decompress_ptr)jpegDecompressStruct; + error_ptr2 pjerr = (error_ptr2)jpegErrorMgr2Struct; + + pcinfo->err = jpeg_std_error(&pjerr->pub); + pjerr->pub.error_exit = error_exit; + + if (setjmp(pjerr->setjmp_buffer)) { + jpeg_destroy_decompress(pcinfo); + sourceSize = 0; + } + + if (sourceSize) { + jpeg_create_decompress(pcinfo); + jpeg_mem_src(pcinfo, source, sourceSize); + jpeg_read_header(pcinfo, TRUE); + } +} Property changes on: trunk/platforms/Cross/plugins/sqPluginsSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Tue May 24 17:24:39 PDT 2016 + Thu Jun 9 16:06:05 PDT 2016 From lewis at mail.msen.com Thu Jun 9 23:31:42 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Thu Jun 9 23:31:44 2016 Subject: [Vm-dev] [commit][3741] Integrate Laura Perez Carrato' s 8- & 16-bit JPEG enhancement support code. In-Reply-To: References: Message-ID: <20160609233142.GB63780@shell.msen.com> On Thu, Jun 09, 2016 at 04:07:43PM -0700, commits@squeakvm.org wrote: > > Revision: 3741 > Author: eliot > Date: 2016-06-09 16:07:42 -0700 (Thu, 09 Jun 2016) > Log Message: > ----------- > Integrate Laura Perez Carrato's 8- & 16-bit JPEG enhancement support code. Yay! Thank you Laura, this is a welcome improvement. Eliot, brilliant - thanks for pushing this. One small additional improvement might be to rename the functions in Cross to follow the naming convention sqSomePlatformFunction() so that they do not look like auto-generated code. So perhaps primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgrWriteScanlines() could be named sqJPEGWriteImageOnByteArray(), and similarly for the other two functions. Sorry for not suggesting this earlier, I meant to do so but got distracted. Dave From commits at squeakvm.org Thu Jun 9 23:52:51 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Thu Jun 9 23:52:40 2016 Subject: [Vm-dev] [commit][3742] And add the declarations to JPEGReadWriter2Plugin.h Message-ID: Revision: 3742 Author: eliot Date: 2016-06-09 16:52:48 -0700 (Thu, 09 Jun 2016) Log Message: ----------- And add the declarations to JPEGReadWriter2Plugin.h Modified Paths: -------------- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h Property Changed: ---------------- trunk/platforms/Cross/plugins/sqPluginsSCCSVersion.h Modified: trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h =================================================================== --- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h 2016-06-09 23:07:42 UTC (rev 3741) +++ trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h 2016-06-09 23:52:48 UTC (rev 3742) @@ -15,3 +15,33 @@ GLOBAL(void) jpeg_mem_src (j_decompress_ptr cinfo, char * pSourceData, unsigned sourceDataSize); GLOBAL(int) jpeg_mem_src_newLocationOfData (j_decompress_ptr cinfo, char * pSourceData, unsigned sourceDataSize); GLOBAL(void) jpeg_mem_dest (j_compress_ptr cinfo, char * pDestination, unsigned *pDestinationSize); +void primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgrWriteScanlines( + unsigned int, + unsigned int, + int, + unsigned int*, + char*, + char*, + int, + int, + unsigned int, + unsigned int, + char*, + unsigned int*); + +void primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgrReadScanlines( + char*, + char*, + char*, + unsigned int, + int, + unsigned int*, + unsigned int, + unsigned int, + int); + +void primJPEGReadHeaderfromByteArrayerrorMgrReadHeader( + char*, + char*, + char*, + unsigned int); Property changes on: trunk/platforms/Cross/plugins/sqPluginsSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Thu Jun 9 16:06:05 PDT 2016 + Thu Jun 9 16:51:50 PDT 2016 From commits at squeakvm.org Fri Jun 10 00:05:43 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Fri Jun 10 00:05:32 2016 Subject: [Vm-dev] [commit][3743] Rename one selector to allow elimination of a cCode: inSmalltalk: in the plugin code. Message-ID: Revision: 3743 Author: eliot Date: 2016-06-09 17:05:42 -0700 (Thu, 09 Jun 2016) Log Message: ----------- Rename one selector to allow elimination of a cCode:inSmalltalk: in the plugin code. Modified Paths: -------------- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c Property Changed: ---------------- trunk/platforms/Cross/plugins/sqPluginsSCCSVersion.h Modified: trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h =================================================================== --- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h 2016-06-09 23:52:48 UTC (rev 3742) +++ trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h 2016-06-10 00:05:42 UTC (rev 3743) @@ -40,8 +40,8 @@ unsigned int, int); -void primJPEGReadHeaderfromByteArrayerrorMgrReadHeader( +void primJPEGReadHeaderfromByteArraysizeerrorMgrReadHeader( char*, char*, - char*, unsigned int); + char*); Modified: trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c =================================================================== --- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c 2016-06-09 23:52:48 UTC (rev 3742) +++ trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/sqJPEGReadWriter2Plugin.c 2016-06-10 00:05:42 UTC (rev 3743) @@ -282,11 +282,11 @@ } void -primJPEGReadHeaderfromByteArrayerrorMgrReadHeader ( +primJPEGReadHeaderfromByteArraysizeerrorMgrReadHeader( char* jpegDecompressStruct, - char* jpegErrorMgr2Struct, char* source, - unsigned int sourceSize) + unsigned int sourceSize, + char* jpegErrorMgr2Struct) { j_decompress_ptr pcinfo = (j_decompress_ptr)jpegDecompressStruct; error_ptr2 pjerr = (error_ptr2)jpegErrorMgr2Struct; Property changes on: trunk/platforms/Cross/plugins/sqPluginsSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Thu Jun 9 16:51:50 PDT 2016 + Thu Jun 9 17:04:39 PDT 2016 From commits at source.squeak.org Fri Jun 10 00:07:58 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Jun 10 00:07:59 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1887.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1887.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1887 Author: eem Time: 9 June 2016, 5:05:44.192116 pm UUID: 39e48685-63a6-498b-b4c5-8e7aa0c162dd Ancestors: VMMaker.oscog-eem.1886 Integrate Laura's greyscale JPEG support code, eliminating one cCode:inSmalltalk. Too lazy to eliminate the other. Requires http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins r3742. =============== Diff against VMMaker.oscog-eem.1886 =============== Item was added: + ----- Method: JPEGReadWriter2Plugin>>primImageNumComponents: (in category 'primitives') ----- + primImageNumComponents: aJPEGDecompressStruct + + + + self + primitive: 'primImageNumComponents' + parameters: #(ByteArray). + + "Various parameter checks" + self cCode: ' + interpreterProxy->success + ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct jpeg_decompress_struct))); + if (interpreterProxy->failed()) return null; + ' inSmalltalk: []. + + ^(self cCode: '((j_decompress_ptr)aJPEGDecompressStruct)->num_components' inSmalltalk: [0]) + asOop: SmallInteger! Item was changed: ----- Method: JPEGReadWriter2Plugin>>primJPEGReadHeader:fromByteArray:errorMgr: (in category 'primitives') ----- primJPEGReadHeader: aJPEGDecompressStruct fromByteArray: source errorMgr: aJPEGErrorMgr2Struct + + | sourceSize | + - - | pcinfo pjerr sourceSize | + - - self primitive: 'primJPEGReadHeaderfromByteArrayerrorMgr' parameters: #(ByteArray ByteArray ByteArray). - - pcinfo := nil. pjerr := nil. sourceSize := nil. - pcinfo. pjerr. sourceSize. - "Various parameter checks" + interpreterProxy success: + (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(2)) >= (sizeof(struct jpeg_decompress_struct))' inSmalltalk: []). + interpreterProxy success: + (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))' inSmalltalk: []). + interpreterProxy failed ifTrue: [ ^ nil ]. + + sourceSize := interpreterProxy stSizeOf: (interpreterProxy stackValue: 1). + sourceSize > 0 ifTrue: + [self primJPEGReadHeader: aJPEGDecompressStruct + fromByteArray: source + size: sourceSize + errorMgrReadHeader: aJPEGErrorMgr2Struct]! - self cCode: ' - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(2))) >= (sizeof(struct jpeg_decompress_struct))); - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct error_mgr2))); - if (interpreterProxy->failed()) return null; - ' inSmalltalk: []. - - self cCode: ' - sourceSize = interpreterProxy->stSizeOf(interpreterProxy->stackValue(1)); - pcinfo = (j_decompress_ptr)aJPEGDecompressStruct; - pjerr = (error_ptr2)aJPEGErrorMgr2Struct; - if (sourceSize) { - pcinfo->err = jpeg_std_error(&pjerr->pub); - pjerr->pub.error_exit = error_exit; - if (setjmp(pjerr->setjmp_buffer)) { - jpeg_destroy_decompress(pcinfo); - sourceSize = 0; - } - if (sourceSize) { - jpeg_create_decompress(pcinfo); - jpeg_mem_src(pcinfo, source, sourceSize); - jpeg_read_header(pcinfo, TRUE); - } - } - ' inSmalltalk: [].! Item was changed: ----- Method: JPEGReadWriter2Plugin>>primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr: (in category 'primitives') ----- primJPEGReadImage: aJPEGDecompressStruct fromByteArray: source onForm: form doDithering: ditherFlag errorMgr: aJPEGErrorMgr2Struct + | formBitmap formNativeDepth formDepth formWidth formHeight pixelsPerWord formPitch formBitmapSizeInBytes sourceSize formBitmapOOP formComponentBitSize formComponents wordsPerRow | - | pcinfo pjerr buffer rowStride formBits formDepth i j formPix ok rOff gOff bOff rOff2 gOff2 bOff2 formWidth formHeight pixPerWord formPitch formBitsSize sourceSize r1 r2 g1 g2 b1 b2 formBitsOops dmv1 dmv2 di dmi dmo | + - - - - self primitive: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr' parameters: #(ByteArray ByteArray Form Boolean ByteArray). + formBitmapOOP := interpreterProxy fetchPointer: 0 ofObject: form. + formNativeDepth := interpreterProxy fetchInteger: 3 ofObject: form. + formWidth := interpreterProxy fetchInteger: 1 ofObject: form. + formHeight := interpreterProxy fetchInteger: 2 ofObject: form. + formDepth := formNativeDepth abs. + - "Avoid warnings when saving method" - pcinfo := nil. pjerr := nil. buffer := nil. rowStride := nil. - formDepth := nil. formBits := nil. i := nil. j := nil. formPix := nil. - ok := nil. rOff := nil. gOff := nil. bOff := nil. rOff2 := nil. gOff2 := nil. bOff2 := nil. sourceSize := nil. - r1 := nil. r2 := nil. g1 := nil. g2 := nil. b1 := nil. b2 := nil. - dmv1 := nil. dmv2 := nil. di := nil. dmi := nil. dmo := nil. - pcinfo. pjerr. buffer. rowStride. formBits. formDepth. i. j. formPix. ok. - rOff. gOff. bOff. rOff2. gOff2. bOff2. sourceSize. - r1. r2. g1.g2. b1. b2. dmv1. dmv2. di. dmi. dmo. - - formBitsOops := interpreterProxy fetchPointer: 0 ofObject: form. - formDepth := interpreterProxy fetchInteger: 3 ofObject: form. - "Various parameter checks" + interpreterProxy success: + (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(4)) >= (sizeof(struct jpeg_decompress_struct))' inSmalltalk: []). + interpreterProxy success: + (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))' inSmalltalk: []). + interpreterProxy failed ifTrue: [ ^ nil ]. + + formComponents := formDepth ~= 8 ifTrue: [4] ifFalse: [1]. + formComponentBitSize := formDepth ~= 16 ifTrue: [8] ifFalse: [4]. + pixelsPerWord := 32 // (formComponents * formComponentBitSize). + wordsPerRow := (formWidth + pixelsPerWord - 1) // pixelsPerWord. + formPitch := formWidth + (pixelsPerWord-1) // pixelsPerWord * 4. + formBitmapSizeInBytes := interpreterProxy byteSizeOf: formBitmapOOP. + - self cCode: ' - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(4))) >= (sizeof(struct jpeg_decompress_struct))); - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct error_mgr2))); - if (interpreterProxy->failed()) return null; - ' inSmalltalk: []. - formWidth := (self cCode: '((j_decompress_ptr)aJPEGDecompressStruct)->image_width' inSmalltalk: [0]). - formHeight := (self cCode: '((j_decompress_ptr)aJPEGDecompressStruct)->image_height' inSmalltalk: [0]). - pixPerWord := 32 // formDepth. - formPitch := formWidth + (pixPerWord-1) // pixPerWord * 4. - formBitsSize := interpreterProxy byteSizeOf: formBitsOops. interpreterProxy success: + ((interpreterProxy isWordsOrBytes: formBitmapOOP) and: + [formBitmapSizeInBytes = (formPitch * formHeight)]). - ((interpreterProxy isWordsOrBytes: formBitsOops) - and: [formBitsSize = (formPitch * formHeight)]). interpreterProxy failed ifTrue: [^ nil]. + + sourceSize := interpreterProxy stSizeOf: (interpreterProxy stackValue: 3). + + interpreterProxy success: (sourceSize ~= 0). + interpreterProxy failed ifTrue: [ ^ nil ]. + + formBitmap := interpreterProxy firstIndexableField: formBitmapOOP. + + self + cCode: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgrReadScanlines( + aJPEGDecompressStruct, + aJPEGErrorMgr2Struct, + source, + sourceSize, + ditherFlag, + formBitmap, + pixelsPerWord, + wordsPerRow, + formNativeDepth);' + inSmalltalk: [].! - formBits := interpreterProxy firstIndexableField: formBitsOops. - - self cCode: ' - sourceSize = interpreterProxy->stSizeOf(interpreterProxy->stackValue(3)); - if (sourceSize == 0) { - interpreterProxy->success(false); - return null; - } - pcinfo = (j_decompress_ptr)aJPEGDecompressStruct; - pjerr = (error_ptr2)aJPEGErrorMgr2Struct; - pcinfo->err = jpeg_std_error(&pjerr->pub); - pjerr->pub.error_exit = error_exit; - ok = 1; - if (setjmp(pjerr->setjmp_buffer)) { - jpeg_destroy_decompress(pcinfo); - ok = 0; - } - if (ok) { - ok = jpeg_mem_src_newLocationOfData(pcinfo, source, sourceSize); - if (ok) { - /* Dither Matrix taken from Form>>orderedDither32To16, but rewritten for this method. */ - int ditherMatrix1[] = { 2, 0, 14, 12, 1, 3, 13, 15 }; - int ditherMatrix2[] = { 10, 8, 6, 4, 9, 11, 5, 7 }; - jpeg_start_decompress(pcinfo); - rowStride = pcinfo->output_width * pcinfo->output_components; - if (pcinfo->out_color_components == 3) { - rOff = 0; gOff = 1; bOff = 2; - rOff2 = 3; gOff2 = 4; bOff2 = 5; - } else { - rOff = 0; gOff = 0; bOff = 0; - rOff2 = 1; gOff2 = 1; bOff2 = 1; - } - /* Make a one-row-high sample array that will go away when done with image */ - buffer = (*(pcinfo->mem)->alloc_sarray) - ((j_common_ptr) pcinfo, JPOOL_IMAGE, rowStride, 1); - - /* Step 6: while (scan lines remain to be read) */ - /* jpeg_read_scanlines(...); */ - - /* Here we use the library state variable cinfo.output_scanline as the - * loop counter, so that we dont have to keep track ourselves. - */ - while (pcinfo->output_scanline < pcinfo->output_height) { - /* jpeg_read_scanlines expects an array of pointers to scanlines. - * Here the array is only one element long, but you could ask for - * more than one scanline at a time if thats more convenient. - */ - (void) jpeg_read_scanlines(pcinfo, buffer, 1); - - switch (formDepth) { - case 32: - for(i = 0, j = 0; i < rowStride; i +=(pcinfo->out_color_components), j++) { - formPix = (255 << 24) | (buffer[0][i+rOff] << 16) | (buffer[0][i+gOff] << 8) | buffer[0][i+bOff]; - if (formPix == 0) formPix = 1; - formBits [ ((pcinfo->output_scanline - 1) * (pcinfo->image_width)) + j ] = formPix; - } - break; - - case 16: - for(i = 0, j = 0; i < rowStride; i +=(pcinfo->out_color_components*2), j++) { - r1 = buffer[0][i+rOff]; - r2 = buffer[0][i+rOff2]; - g1 = buffer[0][i+gOff]; - g2 = buffer[0][i+gOff2]; - b1 = buffer[0][i+bOff]; - b2 = buffer[0][i+bOff2]; - - if (!!ditherFlag) { - r1 = r1 >> 3; - r2 = r2 >> 3; - g1 = g1 >> 3; - g2 = g2 >> 3; - b1 = b1 >> 3; - b2 = b2 >> 3; - } else { - /* Do 4x4 ordered dithering. Taken from Form>>orderedDither32To16 */ - dmv1 = ditherMatrix1[ ((pcinfo->output_scanline & 3 )<< 1) | (j&1) ]; - dmv2 = ditherMatrix2[ ((pcinfo->output_scanline & 3 )<< 1) | (j&1) ]; - - di = (r1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv1 < dmi) { r1 = dmo+1; } else { r1 = dmo; }; - di = (g1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv1 < dmi) { g1 = dmo+1; } else { g1 = dmo; }; - di = (b1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv1 < dmi) { b1 = dmo+1; } else { b1 = dmo; }; - - di = (r2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv2 < dmi) { r2 = dmo+1; } else { r2 = dmo; }; - di = (g2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv2 < dmi) { g2 = dmo+1; } else { g2 = dmo; }; - di = (b2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv2 < dmi) { b2 = dmo+1; } else { b2 = dmo; }; - } - - formPix = (r1 << 10) | (g1 << 5) | b1; - if (!!formPix) formPix = 1; - formPix = (formPix << 16) | (r2 << 10) | (g2 << 5) | b2; - if (!!(formPix & 65535)) formPix = formPix | 1; - formBits [ ((pcinfo->output_scanline - 1) * (pcinfo->image_width)) / 2 + j ] = formPix; - } - break; - } - } - jpeg_finish_decompress(pcinfo); - } - jpeg_destroy_decompress(pcinfo); - } - ' inSmalltalk: [].! Item was changed: ----- Method: JPEGReadWriter2Plugin>>primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr: (in category 'primitives') ----- primJPEGWriteImage: aJPEGCompressStruct onByteArray: destination form: form quality: quality progressiveJPEG: progressiveFlag errorMgr: aJPEGErrorMgr2Struct + | formBitmap formWidth formHeight formNativeDepth formDepth destinationSize pixelsPerWord wordsPerRow formPitch formBitmapSizeInBytes formBitmapOOP formComponentBitSize formComponents | - | pcinfo pjerr buffer rowStride formBits formWidth formHeight formDepth i j formPix destinationSize pixPerWord formPitch formBitsSize formBitsOops | + - - - - self primitive: 'primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgr' parameters: #(ByteArray ByteArray Form SmallInteger Boolean ByteArray). + formBitmapOOP := interpreterProxy fetchPointer: 0 ofObject: form. - pcinfo := nil. pjerr := nil. buffer :=nil. rowStride := nil. formBits := nil. - formWidth := nil. formHeight := nil. formDepth := nil. i := nil. j := nil. formPix := nil. destinationSize := nil. - pcinfo. pjerr. buffer. rowStride. formBits. formWidth. formHeight. formDepth. i. j. formPix. destinationSize. - - formBitsOops := interpreterProxy fetchPointer: 0 ofObject: form. formWidth := interpreterProxy fetchInteger: 1 ofObject: form. formHeight := interpreterProxy fetchInteger: 2 ofObject: form. + formNativeDepth := interpreterProxy fetchInteger: 3 ofObject: form. + formDepth := formNativeDepth abs. - formDepth := interpreterProxy fetchInteger: 3 ofObject: form. "Various parameter checks" + interpreterProxy success: + (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(5)) >= (sizeof(struct jpeg_compress_struct))' inSmalltalk: []). - self cCode: ' - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(5))) >= (sizeof(struct jpeg_compress_struct))); - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct error_mgr2))); - if (interpreterProxy->failed()) return null; - ' inSmalltalk: []. - pixPerWord := 32 // formDepth. - formPitch := formWidth + (pixPerWord-1) // pixPerWord * 4. - formBitsSize := interpreterProxy byteSizeOf: formBitsOops. interpreterProxy success: + (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))' inSmalltalk: []). + interpreterProxy failed ifTrue: [ ^ nil ]. + + formComponents := formDepth ~= 8 ifTrue: [4] ifFalse: [1]. + formComponentBitSize := formDepth ~= 16 ifTrue: [8] ifFalse: [4]. + pixelsPerWord := 32 // (formComponents * formComponentBitSize). + wordsPerRow := (formWidth + pixelsPerWord - 1) // pixelsPerWord. + formPitch := wordsPerRow * 4. + formBitmapSizeInBytes := interpreterProxy byteSizeOf: formBitmapOOP. + interpreterProxy success: + ((interpreterProxy isWordsOrBytes: formBitmapOOP) and: + [formBitmapSizeInBytes = (formPitch * formHeight)]). + interpreterProxy failed ifTrue: [ ^ nil ]. + + formBitmap := interpreterProxy firstIndexableField: formBitmapOOP. + destinationSize := interpreterProxy stSizeOf: (interpreterProxy stackValue: 4). + (destinationSize = 0) + ifFalse: [ self + cCode: ' primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgrWriteScanlines( + formWidth, + formHeight, + formNativeDepth, + formBitmap, + aJPEGCompressStruct, + aJPEGErrorMgr2Struct, + quality, + progressiveFlag, + pixelsPerWord, + wordsPerRow, + destination, + &destinationSize);' + inSmalltalk: []]. + - ((interpreterProxy isWordsOrBytes: formBitsOops) - and: [formBitsSize = (formPitch * formHeight)]). - interpreterProxy failed ifTrue: [^ nil]. - formBits := interpreterProxy firstIndexableField: formBitsOops. - self cCode: ' - destinationSize = interpreterProxy->stSizeOf(interpreterProxy->stackValue(4)); - pcinfo = (j_compress_ptr)aJPEGCompressStruct; - pjerr = (error_ptr2)aJPEGErrorMgr2Struct; - if (destinationSize) { - pcinfo->err = jpeg_std_error(&pjerr->pub); - pjerr->pub.error_exit = error_exit; - if (setjmp(pjerr->setjmp_buffer)) { - jpeg_destroy_compress(pcinfo); - destinationSize = 0; - } - if (destinationSize) { - jpeg_create_compress(pcinfo); - jpeg_mem_dest(pcinfo, destination, &destinationSize); - pcinfo->image_width = formWidth; - pcinfo->image_height = formHeight; - pcinfo->input_components = 3; - pcinfo->in_color_space = JCS_RGB; - jpeg_set_defaults(pcinfo); - if (quality > 0) - jpeg_set_quality (pcinfo, quality, 1); - if (progressiveFlag) - jpeg_simple_progression(pcinfo); - jpeg_start_compress(pcinfo, TRUE); - rowStride = formWidth * 3; - - /* Make a one-row-high sample array that will go away - when done with image */ - buffer = (*(pcinfo->mem)->alloc_sarray) - ((j_common_ptr) pcinfo, JPOOL_IMAGE, rowStride, 1); - - while (pcinfo->next_scanline < pcinfo->image_height) { - switch (formDepth) { - case 32: - for(i = 0, j = 0; i < rowStride; i +=3, j++) { - formPix = formBits [ ((pcinfo->next_scanline) * formWidth) + j ]; - buffer[0][i] = (formPix >> 16) & 255; - buffer[0][i+1] = (formPix >> 8) & 255; - buffer[0][i+2] = formPix & 255; - } - break; - case 16: - for(i = 0, j = 0; i < rowStride; i +=6, j++) { - formPix = formBits [ ((pcinfo->next_scanline) * formWidth) / 2 + j ]; - buffer[0][i] = (formPix >> 23) & 248; - buffer[0][i+1] = (formPix >> 18) & 248; - buffer[0][i+2] = (formPix >> 13) & 248; - buffer[0][i+3] = (formPix >> 7) & 248; - buffer[0][i+4] = (formPix >> 2) & 248; - buffer[0][i+5] = (formPix << 3) & 248; - } - break; - } - (void) jpeg_write_scanlines(pcinfo, buffer, 1); - - } - jpeg_finish_compress(pcinfo); - jpeg_destroy_compress(pcinfo); - } - } - ' inSmalltalk: []. ^(self cCode: 'destinationSize' inSmalltalk: [0]) asOop: SmallInteger! Item was added: + ----- Method: JPEGReadWriter2Plugin>>primSupports8BitGrayscaleJPEGs (in category 'primitives') ----- + primSupports8BitGrayscaleJPEGs + + self + primitive: 'primSupports8BitGrayscaleJPEGs' + parameters: #(). + ^ true asOop: Boolean! From commits at squeakvm.org Fri Jun 10 00:08:29 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Fri Jun 10 00:08:17 2016 Subject: [Vm-dev] [commit][3744] CogVM source as per VMMaker.oscog-eem.1887 Message-ID: Revision: 3744 Author: eliot Date: 2016-06-09 17:08:28 -0700 (Thu, 09 Jun 2016) Log Message: ----------- CogVM source as per VMMaker.oscog-eem.1887 Integrate Laura's greyscale JPEG support code. Requires http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins r3742. Modified Paths: -------------- branches/Cog/src/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c Property Changed: ---------------- branches/Cog/platforms/Cross/vm/sqSCCSVersion.h Property changes on: branches/Cog/platforms/Cross/vm/sqSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Wed Jun 8 11:19:12 PDT 2016 + Thu Jun 9 17:07:14 PDT 2016 Modified: branches/Cog/src/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c =================================================================== --- branches/Cog/src/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c 2016-06-10 00:05:42 UTC (rev 3743) +++ branches/Cog/src/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c 2016-06-10 00:08:28 UTC (rev 3744) @@ -1,9 +1,9 @@ /* Automatically generated by - SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.1716 uuid: 9115c93b-f425-4118-96e7-7130adeff1f2 + SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.1887 uuid: 39e48685-63a6-498b-b4c5-8e7aa0c162dd from - JPEGReadWriter2Plugin VMMaker.oscog-eem.1716 uuid: 9115c93b-f425-4118-96e7-7130adeff1f2 + JPEGReadWriter2Plugin VMMaker.oscog-eem.1887 uuid: 39e48685-63a6-498b-b4c5-8e7aa0c162dd */ -static char __buildInfo[] = "JPEGReadWriter2Plugin VMMaker.oscog-eem.1716 uuid: 9115c93b-f425-4118-96e7-7130adeff1f2 " __DATE__ ; +static char __buildInfo[] = "JPEGReadWriter2Plugin VMMaker.oscog-eem.1887 uuid: 39e48685-63a6-498b-b4c5-8e7aa0c162dd " __DATE__ ; @@ -37,6 +37,7 @@ EXPORT(const char*) getModuleName(void); EXPORT(sqInt) initialiseModule(void); EXPORT(sqInt) primImageHeight(void); +EXPORT(sqInt) primImageNumComponents(void); EXPORT(sqInt) primImageWidth(void); EXPORT(sqInt) primJPEGCompressStructSize(void); EXPORT(sqInt) primJPEGDecompressStructSize(void); @@ -45,6 +46,7 @@ EXPORT(sqInt) primJPEGReadHeaderfromByteArrayerrorMgr(void); EXPORT(sqInt) primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr(void); EXPORT(sqInt) primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgr(void); +EXPORT(sqInt) primSupports8BitGrayscaleJPEGs(void); EXPORT(sqInt) setInterpreter(struct VirtualMachine*anInterpreter); EXPORT(sqInt) shutdownModule(void); static sqInt sqAssert(sqInt aBool); @@ -66,6 +68,7 @@ static sqInt (*isWordsOrBytes)(sqInt oop); static sqInt (*pop)(sqInt nItems); static sqInt (*popthenPush)(sqInt nItems, sqInt oop); +static sqInt (*stSizeOf)(sqInt oop); static sqInt (*stackIntegerValue)(sqInt offset); static sqInt (*stackValue)(sqInt offset); static sqInt (*success)(sqInt aBoolean); @@ -84,6 +87,7 @@ extern sqInt isWordsOrBytes(sqInt oop); extern sqInt pop(sqInt nItems); extern sqInt popthenPush(sqInt nItems, sqInt oop); +extern sqInt stSizeOf(sqInt oop); extern sqInt stackIntegerValue(sqInt offset); extern sqInt stackValue(sqInt offset); extern sqInt success(sqInt aBoolean); @@ -93,9 +97,9 @@ struct VirtualMachine* interpreterProxy; static const char *moduleName = #ifdef SQUEAK_BUILTIN_PLUGIN - "JPEGReadWriter2Plugin VMMaker.oscog-eem.1716 (i)" + "JPEGReadWriter2Plugin VMMaker.oscog-eem.1887 (i)" #else - "JPEGReadWriter2Plugin VMMaker.oscog-eem.1716 (e)" + "JPEGReadWriter2Plugin VMMaker.oscog-eem.1887 (e)" #endif ; @@ -148,6 +152,34 @@ return null; } + /* JPEGReadWriter2Plugin>>#primImageNumComponents: */ +EXPORT(sqInt) +primImageNumComponents(void) +{ + char *aJPEGDecompressStruct; + sqInt _return_value; + + success(isBytes(stackValue(0))); + aJPEGDecompressStruct = ((char *) (firstIndexableField(stackValue(0)))); + if (failed()) { + return null; + } + + interpreterProxy->success + ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct jpeg_decompress_struct))); + if (interpreterProxy->failed()) return null; + + if (failed()) { + return null; + } + _return_value = integerObjectOf((((j_decompress_ptr)aJPEGDecompressStruct)->num_components)); + if (failed()) { + return null; + } + popthenPush(2, _return_value); + return null; +} + /* JPEGReadWriter2Plugin>>#primImageWidth: */ EXPORT(sqInt) primImageWidth(void) @@ -250,8 +282,6 @@ { char *aJPEGDecompressStruct; char *aJPEGErrorMgr2Struct; - j_decompress_ptr pcinfo; - error_ptr2 pjerr; char *source; sqInt sourceSize; @@ -264,37 +294,18 @@ if (failed()) { return null; } - pcinfo = null; - pjerr = null; - sourceSize = null; - - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(2))) >= (sizeof(struct jpeg_decompress_struct))); - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct error_mgr2))); - if (interpreterProxy->failed()) return null; - - - sourceSize = interpreterProxy->stSizeOf(interpreterProxy->stackValue(1)); - pcinfo = (j_decompress_ptr)aJPEGDecompressStruct; - pjerr = (error_ptr2)aJPEGErrorMgr2Struct; - if (sourceSize) { - pcinfo->err = jpeg_std_error(&pjerr->pub); - pjerr->pub.error_exit = error_exit; - if (setjmp(pjerr->setjmp_buffer)) { - jpeg_destroy_decompress(pcinfo); - sourceSize = 0; - } - if (sourceSize) { - jpeg_create_decompress(pcinfo); - jpeg_mem_src(pcinfo, source, sourceSize); - jpeg_read_header(pcinfo, TRUE); - } - } - + success(interpreterProxy->stSizeOf(interpreterProxy->stackValue(2)) >= (sizeof(struct jpeg_decompress_struct))); + success(interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))); if (failed()) { return null; } + sourceSize = stSizeOf(stackValue(1)); + if (sourceSize > 0) { + primJPEGReadHeaderfromByteArraysizeerrorMgrReadHeader(aJPEGDecompressStruct, source, sourceSize, aJPEGErrorMgr2Struct); + } + if (failed()) { + return null; + } pop(3); return null; } @@ -305,43 +316,22 @@ { char *aJPEGDecompressStruct; char *aJPEGErrorMgr2Struct; - sqInt b1; - sqInt b2; - sqInt bOff; - sqInt bOff2; - JSAMPARRAY buffer; - sqInt di; sqInt ditherFlag; - sqInt dmi; - sqInt dmo; - sqInt dmv1; - sqInt dmv2; sqInt form; - unsigned * formBits; - sqInt formBitsOops; - sqInt formBitsSize; + unsigned int*formBitmap; + sqInt formBitmapOOP; + sqInt formBitmapSizeInBytes; + int formComponentBitSize; + int formComponents; sqInt formDepth; sqInt formHeight; + sqInt formNativeDepth; sqInt formPitch; - sqInt formPix; sqInt formWidth; - sqInt g1; - sqInt g2; - sqInt gOff; - sqInt gOff2; - sqInt i; - sqInt j; - sqInt ok; - j_decompress_ptr pcinfo; - sqInt pixPerWord; - error_ptr2 pjerr; - sqInt r1; - sqInt r2; - sqInt rOff; - sqInt rOff2; - sqInt rowStride; + int pixelsPerWord; char *source; sqInt sourceSize; + sqInt wordsPerRow; success(isBytes(stackValue(4))); aJPEGDecompressStruct = ((char *) (firstIndexableField(stackValue(4)))); @@ -355,165 +345,52 @@ if (failed()) { return null; } - pcinfo = null; - pjerr = null; - buffer = null; - rowStride = null; - formDepth = null; - formBits = null; - i = null; - j = null; - formPix = null; - ok = null; - rOff = null; - gOff = null; - bOff = null; - rOff2 = null; - gOff2 = null; - bOff2 = null; - sourceSize = null; - r1 = null; - r2 = null; - g1 = null; - g2 = null; - b1 = null; - b2 = null; - dmv1 = null; - dmv2 = null; - di = null; - dmi = null; - dmo = null; - formBitsOops = fetchPointerofObject(0, form); + formBitmapOOP = fetchPointerofObject(0, form); + formNativeDepth = fetchIntegerofObject(3, form); + formWidth = fetchIntegerofObject(1, form); + formHeight = fetchIntegerofObject(2, form); /* Various parameter checks */ - formDepth = fetchIntegerofObject(3, form); - - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(4))) >= (sizeof(struct jpeg_decompress_struct))); - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct error_mgr2))); - if (interpreterProxy->failed()) return null; - - formWidth = ((j_decompress_ptr)aJPEGDecompressStruct)->image_width; - formHeight = ((j_decompress_ptr)aJPEGDecompressStruct)->image_height; - pixPerWord = 32 / formDepth; - formPitch = ((formWidth + (pixPerWord - 1)) / pixPerWord) * 4; - formBitsSize = byteSizeOf(formBitsOops); - success((isWordsOrBytes(formBitsOops)) - && (formBitsSize == (formPitch * formHeight))); + formDepth = SQABS(formNativeDepth); + success(interpreterProxy->stSizeOf(interpreterProxy->stackValue(4)) >= (sizeof(struct jpeg_decompress_struct))); + success(interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))); if (failed()) { return null; } - formBits = firstIndexableField(formBitsOops); - - sourceSize = interpreterProxy->stSizeOf(interpreterProxy->stackValue(3)); - if (sourceSize == 0) { - interpreterProxy->success(false); - return null; - } - pcinfo = (j_decompress_ptr)aJPEGDecompressStruct; - pjerr = (error_ptr2)aJPEGErrorMgr2Struct; - pcinfo->err = jpeg_std_error(&pjerr->pub); - pjerr->pub.error_exit = error_exit; - ok = 1; - if (setjmp(pjerr->setjmp_buffer)) { - jpeg_destroy_decompress(pcinfo); - ok = 0; - } - if (ok) { - ok = jpeg_mem_src_newLocationOfData(pcinfo, source, sourceSize); - if (ok) { - /* Dither Matrix taken from Form>>orderedDither32To16, but rewritten for this method. */ - int ditherMatrix1[] = { 2, 0, 14, 12, 1, 3, 13, 15 }; - int ditherMatrix2[] = { 10, 8, 6, 4, 9, 11, 5, 7 }; - jpeg_start_decompress(pcinfo); - rowStride = pcinfo->output_width * pcinfo->output_components; - if (pcinfo->out_color_components == 3) { - rOff = 0; gOff = 1; bOff = 2; - rOff2 = 3; gOff2 = 4; bOff2 = 5; - } else { - rOff = 0; gOff = 0; bOff = 0; - rOff2 = 1; gOff2 = 1; bOff2 = 1; - } - /* Make a one-row-high sample array that will go away when done with image */ - buffer = (*(pcinfo->mem)->alloc_sarray) - ((j_common_ptr) pcinfo, JPOOL_IMAGE, rowStride, 1); - - /* Step 6: while (scan lines remain to be read) */ - /* jpeg_read_scanlines(...); */ - - /* Here we use the library state variable cinfo.output_scanline as the - * loop counter, so that we dont have to keep track ourselves. - */ - while (pcinfo->output_scanline < pcinfo->output_height) { - /* jpeg_read_scanlines expects an array of pointers to scanlines. - * Here the array is only one element long, but you could ask for - * more than one scanline at a time if thats more convenient. - */ - (void) jpeg_read_scanlines(pcinfo, buffer, 1); - - switch (formDepth) { - case 32: - for(i = 0, j = 0; i < rowStride; i +=(pcinfo->out_color_components), j++) { - formPix = (255 << 24) | (buffer[0][i+rOff] << 16) | (buffer[0][i+gOff] << 8) | buffer[0][i+bOff]; - if (formPix == 0) formPix = 1; - formBits [ ((pcinfo->output_scanline - 1) * (pcinfo->image_width)) + j ] = formPix; - } - break; - - case 16: - for(i = 0, j = 0; i < rowStride; i +=(pcinfo->out_color_components*2), j++) { - r1 = buffer[0][i+rOff]; - r2 = buffer[0][i+rOff2]; - g1 = buffer[0][i+gOff]; - g2 = buffer[0][i+gOff2]; - b1 = buffer[0][i+bOff]; - b2 = buffer[0][i+bOff2]; - - if (!ditherFlag) { - r1 = r1 >> 3; - r2 = r2 >> 3; - g1 = g1 >> 3; - g2 = g2 >> 3; - b1 = b1 >> 3; - b2 = b2 >> 3; - } else { - /* Do 4x4 ordered dithering. Taken from Form>>orderedDither32To16 */ - dmv1 = ditherMatrix1[ ((pcinfo->output_scanline & 3 )<< 1) | (j&1) ]; - dmv2 = ditherMatrix2[ ((pcinfo->output_scanline & 3 )<< 1) | (j&1) ]; - - di = (r1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv1 < dmi) { r1 = dmo+1; } else { r1 = dmo; }; - di = (g1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv1 < dmi) { g1 = dmo+1; } else { g1 = dmo; }; - di = (b1 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv1 < dmi) { b1 = dmo+1; } else { b1 = dmo; }; - - di = (r2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv2 < dmi) { r2 = dmo+1; } else { r2 = dmo; }; - di = (g2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv2 < dmi) { g2 = dmo+1; } else { g2 = dmo; }; - di = (b2 * 496) >> 8; dmi = di & 15; dmo = di >> 4; - if(dmv2 < dmi) { b2 = dmo+1; } else { b2 = dmo; }; - } - - formPix = (r1 << 10) | (g1 << 5) | b1; - if (!formPix) formPix = 1; - formPix = (formPix << 16) | (r2 << 10) | (g2 << 5) | b2; - if (!(formPix & 65535)) formPix = formPix | 1; - formBits [ ((pcinfo->output_scanline - 1) * (pcinfo->image_width)) / 2 + j ] = formPix; - } - break; - } - } - jpeg_finish_decompress(pcinfo); - } - jpeg_destroy_decompress(pcinfo); - } - + formComponents = (formDepth != 8 + ? 4 + : 1); + formComponentBitSize = (formDepth != 16 + ? 8 + : 4); + pixelsPerWord = 32 / (formComponents * formComponentBitSize); + wordsPerRow = ((formWidth + pixelsPerWord) - 1) / pixelsPerWord; + formPitch = ((formWidth + (pixelsPerWord - 1)) / pixelsPerWord) * 4; + formBitmapSizeInBytes = byteSizeOf(formBitmapOOP); + success((isWordsOrBytes(formBitmapOOP)) + && (formBitmapSizeInBytes == (formPitch * formHeight))); if (failed()) { return null; } + sourceSize = stSizeOf(stackValue(3)); + success(sourceSize != 0); + if (failed()) { + return null; + } + formBitmap = firstIndexableField(formBitmapOOP); + primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgrReadScanlines( + aJPEGDecompressStruct, + aJPEGErrorMgr2Struct, + source, + sourceSize, + ditherFlag, + formBitmap, + pixelsPerWord, + wordsPerRow, + formNativeDepth); + if (failed()) { + return null; + } pop(5); return null; } @@ -524,26 +401,23 @@ { char *aJPEGCompressStruct; char *aJPEGErrorMgr2Struct; - JSAMPARRAY buffer; char *destination; unsigned int destinationSize; sqInt form; - unsigned * formBits; - sqInt formBitsOops; - sqInt formBitsSize; + unsigned int *formBitmap; + sqInt formBitmapOOP; + sqInt formBitmapSizeInBytes; + int formComponentBitSize; + int formComponents; sqInt formDepth; sqInt formHeight; + sqInt formNativeDepth; sqInt formPitch; - sqInt formPix; sqInt formWidth; - sqInt i; - sqInt j; - j_compress_ptr pcinfo; - sqInt pixPerWord; - error_ptr2 pjerr; + int pixelsPerWord; sqInt progressiveFlag; sqInt quality; - sqInt rowStride; + sqInt wordsPerRow; sqInt _return_value; success(isBytes(stackValue(5))); @@ -559,104 +433,53 @@ if (failed()) { return null; } - pcinfo = null; - pjerr = null; - buffer = null; - rowStride = null; - formBits = null; - formWidth = null; - formHeight = null; - formDepth = null; - i = null; - j = null; - formPix = null; - destinationSize = null; - formBitsOops = fetchPointerofObject(0, form); + formBitmapOOP = fetchPointerofObject(0, form); formWidth = fetchIntegerofObject(1, form); formHeight = fetchIntegerofObject(2, form); + formNativeDepth = fetchIntegerofObject(3, form); /* Various parameter checks */ - formDepth = fetchIntegerofObject(3, form); - - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(5))) >= (sizeof(struct jpeg_compress_struct))); - interpreterProxy->success - ((interpreterProxy->stSizeOf(interpreterProxy->stackValue(0))) >= (sizeof(struct error_mgr2))); - if (interpreterProxy->failed()) return null; - - pixPerWord = 32 / formDepth; - formPitch = ((formWidth + (pixPerWord - 1)) / pixPerWord) * 4; - formBitsSize = byteSizeOf(formBitsOops); - success((isWordsOrBytes(formBitsOops)) - && (formBitsSize == (formPitch * formHeight))); + formDepth = SQABS(formNativeDepth); + success(interpreterProxy->stSizeOf(interpreterProxy->stackValue(5)) >= (sizeof(struct jpeg_compress_struct))); + success(interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))); if (failed()) { return null; } - formBits = firstIndexableField(formBitsOops); - - destinationSize = interpreterProxy->stSizeOf(interpreterProxy->stackValue(4)); - pcinfo = (j_compress_ptr)aJPEGCompressStruct; - pjerr = (error_ptr2)aJPEGErrorMgr2Struct; - if (destinationSize) { - pcinfo->err = jpeg_std_error(&pjerr->pub); - pjerr->pub.error_exit = error_exit; - if (setjmp(pjerr->setjmp_buffer)) { - jpeg_destroy_compress(pcinfo); - destinationSize = 0; - } - if (destinationSize) { - jpeg_create_compress(pcinfo); - jpeg_mem_dest(pcinfo, destination, &destinationSize); - pcinfo->image_width = formWidth; - pcinfo->image_height = formHeight; - pcinfo->input_components = 3; - pcinfo->in_color_space = JCS_RGB; - jpeg_set_defaults(pcinfo); - if (quality > 0) - jpeg_set_quality (pcinfo, quality, 1); - if (progressiveFlag) - jpeg_simple_progression(pcinfo); - jpeg_start_compress(pcinfo, TRUE); - rowStride = formWidth * 3; - - /* Make a one-row-high sample array that will go away - when done with image */ - buffer = (*(pcinfo->mem)->alloc_sarray) - ((j_common_ptr) pcinfo, JPOOL_IMAGE, rowStride, 1); - - while (pcinfo->next_scanline < pcinfo->image_height) { - switch (formDepth) { - case 32: - for(i = 0, j = 0; i < rowStride; i +=3, j++) { - formPix = formBits [ ((pcinfo->next_scanline) * formWidth) + j ]; - buffer[0][i] = (formPix >> 16) & 255; - buffer[0][i+1] = (formPix >> 8) & 255; - buffer[0][i+2] = formPix & 255; - } - break; - case 16: - for(i = 0, j = 0; i < rowStride; i +=6, j++) { - formPix = formBits [ ((pcinfo->next_scanline) * formWidth) / 2 + j ]; - buffer[0][i] = (formPix >> 23) & 248; - buffer[0][i+1] = (formPix >> 18) & 248; - buffer[0][i+2] = (formPix >> 13) & 248; - buffer[0][i+3] = (formPix >> 7) & 248; - buffer[0][i+4] = (formPix >> 2) & 248; - buffer[0][i+5] = (formPix << 3) & 248; - } - break; - } - (void) jpeg_write_scanlines(pcinfo, buffer, 1); - - } - jpeg_finish_compress(pcinfo); - jpeg_destroy_compress(pcinfo); - } - } - + formComponents = (formDepth != 8 + ? 4 + : 1); + formComponentBitSize = (formDepth != 16 + ? 8 + : 4); + pixelsPerWord = 32 / (formComponents * formComponentBitSize); + wordsPerRow = ((formWidth + pixelsPerWord) - 1) / pixelsPerWord; + formPitch = wordsPerRow * 4; + formBitmapSizeInBytes = byteSizeOf(formBitmapOOP); + success((isWordsOrBytes(formBitmapOOP)) + && (formBitmapSizeInBytes == (formPitch * formHeight))); if (failed()) { return null; } + formBitmap = firstIndexableField(formBitmapOOP); + destinationSize = stSizeOf(stackValue(4)); + if (!(destinationSize == 0)) { + primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgrWriteScanlines( + formWidth, + formHeight, + formNativeDepth, + formBitmap, + aJPEGCompressStruct, + aJPEGErrorMgr2Struct, + quality, + progressiveFlag, + pixelsPerWord, + wordsPerRow, + destination, + &destinationSize); + } + if (failed()) { + return null; + } _return_value = integerObjectOf((destinationSize)); if (failed()) { return null; @@ -665,7 +488,24 @@ return null; } + /* JPEGReadWriter2Plugin>>#primSupports8BitGrayscaleJPEGs */ +EXPORT(sqInt) +primSupports8BitGrayscaleJPEGs(void) +{ + sqInt _return_value; + if (failed()) { + return null; + } + _return_value = ((1) ? trueObject() : falseObject()); + if (failed()) { + return null; + } + popthenPush(1, _return_value); + return null; +} + + /* Note: This is coded so that it can be run in Squeak. */ /* InterpreterPlugin>>#setInterpreter: */ @@ -693,6 +533,7 @@ isWordsOrBytes = interpreterProxy->isWordsOrBytes; pop = interpreterProxy->pop; popthenPush = interpreterProxy->popthenPush; + stSizeOf = interpreterProxy->stSizeOf; stackIntegerValue = interpreterProxy->stackIntegerValue; stackValue = interpreterProxy->stackValue; success = interpreterProxy->success; @@ -725,6 +566,7 @@ {(void*)_m, "getModuleName", (void*)getModuleName}, {(void*)_m, "initialiseModule", (void*)initialiseModule}, {(void*)_m, "primImageHeight\000\377", (void*)primImageHeight}, + {(void*)_m, "primImageNumComponents\000\377", (void*)primImageNumComponents}, {(void*)_m, "primImageWidth\000\377", (void*)primImageWidth}, {(void*)_m, "primJPEGCompressStructSize\000\377", (void*)primJPEGCompressStructSize}, {(void*)_m, "primJPEGDecompressStructSize\000\377", (void*)primJPEGDecompressStructSize}, @@ -733,6 +575,7 @@ {(void*)_m, "primJPEGReadHeaderfromByteArrayerrorMgr\000\377", (void*)primJPEGReadHeaderfromByteArrayerrorMgr}, {(void*)_m, "primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr\000\002", (void*)primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr}, {(void*)_m, "primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgr\000\002", (void*)primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgr}, + {(void*)_m, "primSupports8BitGrayscaleJPEGs\000\377", (void*)primSupports8BitGrayscaleJPEGs}, {(void*)_m, "setInterpreter", (void*)setInterpreter}, {(void*)_m, "shutdownModule\000\377", (void*)shutdownModule}, {NULL, NULL, NULL} From btc at openinworld.com Fri Jun 10 01:46:24 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 10 01:46:46 2016 Subject: [Vm-dev] StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences Message-ID: Just curious about the difference in instructionPointer between these two... StackInterpreter>>transferTo: self assertValidExecutionPointe: instructionPointer + 1 r: framePointer s: stackPointer. CoIntepreter>>transferTo:from: self assertValidExecutionPointe: instructionPointer r: framePointer s: stackPointer. cheers -ben From eliot.miranda at gmail.com Fri Jun 10 03:30:06 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 10 03:30:11 2016 Subject: [Vm-dev] StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences In-Reply-To: References: Message-ID: <6CA987CA-B400-44AC-A285-E981818117D5@gmail.com> Hi Ben, > On Jun 9, 2016, at 6:46 PM, Ben Coman wrote: > > > Just curious about the difference in instructionPointer between these two... > > StackInterpreter>>transferTo: > self assertValidExecutionPointe: instructionPointer + 1 r: > framePointer s: stackPointer. > > > CoIntepreter>>transferTo:from: > self assertValidExecutionPointe: instructionPointer r: > framePointer s: stackPointer. The difference is to support richer logging of process switch events in the Cog VM. In the StackInterpreter context switches only occur in two contexts, within a primitive or checkForEventsMayContextSwitch:. One might think that the Cog VM is similar but it's much more complicated because a primitive can be invoked in different ways. One way is from the interpreter via slowPrimitiveResponse, just like the StackInterpreter. Another way is from a jitted method containing a primitive. Yet another way is in the attempt to lookup and link a send from machine code that binds to a method with a primitive. Yet another way is in invoking a primitive in a method that should be interpreted (because it has more literals than the limit for jitting) from machine code. The VM optimises this transition by using a PIC which can have entries that speed up invoking interpreted methods or MNUs, not just polymorphic sends. To debug context switch in these contexts (and one more historical context that I think no longer occurs) I needed the richer logging that the from: argument gave me to discover the actual path taken to a process switch. HTH > > cheers -ben From btc at openinworld.com Fri Jun 10 03:44:03 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 10 03:44:25 2016 Subject: [Vm-dev] StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences In-Reply-To: <6CA987CA-B400-44AC-A285-E981818117D5@gmail.com> References: <6CA987CA-B400-44AC-A285-E981818117D5@gmail.com> Message-ID: On Fri, Jun 10, 2016 at 11:30 AM, Eliot Miranda wrote: > > Hi Ben, > >> On Jun 9, 2016, at 6:46 PM, Ben Coman wrote: >> >> >> Just curious about the difference in instructionPointer between these two... >> >> StackInterpreter>>transferTo: >> self assertValidExecutionPointe: instructionPointer + 1 r: >> framePointer s: stackPointer. >> >> >> CoIntepreter>>transferTo:from: >> self assertValidExecutionPointe: instructionPointer r: >> framePointer s: stackPointer. > > The difference is to support richer logging of process switch events in the Cog VM. > > In the StackInterpreter context switches only occur in two contexts, within a primitive or checkForEventsMayContextSwitch:. > > One might think that the Cog VM is similar but it's much more complicated because a primitive can be invoked in different ways. One way is from the interpreter via slowPrimitiveResponse, just like the StackInterpreter. Another way is from a jitted method containing a primitive. Yet another way is in the attempt to lookup and link a send from machine code that binds to a method with a primitive. Yet another way is in invoking a primitive in a method that should be interpreted (because it has more literals than the limit for jitting) from machine code. The VM optimises this transition by using a PIC which can have entries that speed up invoking interpreted methods or MNUs, not just polymorphic sends. > > To debug context switch in these contexts (and one more historical context that I think no longer occurs) I needed the richer logging that the from: argument gave me to discover the actual path taken to a process switch. Thanks Eliot. Great info that I'll file for reference, but this seems only to describe the addition to Cog of the #from: argument, and I'm not sure how that relates to my query on why the assert for StackInterpreter increments the instructionPointer by one, and the assert for the CoInterpreter does not. Sorry if my question was too brief an unclear? cheers -ben From craig at blackpagedigital.com Fri Jun 10 07:46:08 2016 From: craig at blackpagedigital.com (Craig Latta) Date: Fri Jun 10 07:46:30 2016 Subject: [Vm-dev] re: StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences In-Reply-To: References: <6CA987CA-B400-44AC-A285-E981818117D5@gmail.com> Message-ID: Great info indeed! :) Eliot, is that in a class comment or a paper somewhere? I'd like to read the rest of it if so. thanks again, -C -- Craig Latta Black Page Digital Amsterdam craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From btc at openinworld.com Fri Jun 10 09:19:16 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 10 09:19:38 2016 Subject: [Vm-dev] CoInterpreter naming curiosity Message-ID: Random curiosity, why the name CoInterpreter and not CogInterpreter ? cheers -ben From eliot.miranda at gmail.com Fri Jun 10 12:17:01 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 10 12:17:06 2016 Subject: [Vm-dev] StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences In-Reply-To: References: Message-ID: Hi Ben, this time I'll try and answer your question rather than my brain fart... > On Jun 9, 2016, at 6:46 PM, Ben Coman wrote: > > > Just curious about the difference in instructionPointer between these two... > > StackInterpreter>>transferTo: > self assertValidExecutionPointe: instructionPointer + 1 r: > framePointer s: stackPointer. > > > CoIntepreter>>transferTo:from: > self assertValidExecutionPointe: instructionPointer r: > framePointer s: stackPointer. In the StackInterpreter, as in the context Interpreter the next bytecode is fetched by pre-incrementing the instructionPointer and then fetching the byte it points to. Hence it may point to before the first bytecode and hence the + 1 above. 1 is subtracted from a context's pc (2 actually cuz pc is 1-relative and instructionPointer is 0-relative) to derive instructionPointer. In the Cog VM instructionPointer may also be a machine code pc. So rather than add one, which only makes sense for interpreted methods, the CoInterpreter's assertValidExecutionPointer:s: allows for the - 1 if a frame us interpreted. The StackInterpreter's method predates the CoInterpreter. > > > cheers -ben _,,,^..^,,,_ (phone) From eliot.miranda at gmail.com Fri Jun 10 12:22:50 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 10 12:22:54 2016 Subject: [Vm-dev] re: StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences In-Reply-To: References: <6CA987CA-B400-44AC-A285-E981818117D5@gmail.com> Message-ID: <13A1D409-3023-413C-B938-88AF77779FC0@gmail.com> Hi Craig, > On Jun 10, 2016, at 12:46 AM, Craig Latta wrote: > > > > Great info indeed! :) Eliot, is that in a class comment or a paper > somewhere? I'd like to read the rest of it if so. I had planned to write at least a blog post on this and related topics, essentially in how Cog coordinates an interpreter and a JIT, but I've not found time in 5 years :-/. I think it's important to write up. I remember reading something about the Erlang VM wanting to do the same and they ended up having two separate stacks for interpreted and machine code frames, bad for a number of reasons. The stars may yet align and I'll write it up... > thanks again, > > -C _,,,^..^,,,_ (phone) From eliot.miranda at gmail.com Fri Jun 10 12:30:46 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 10 12:30:51 2016 Subject: [Vm-dev] CoInterpreter naming curiosity In-Reply-To: References: Message-ID: Hi Ben, _,,,^..^,,,_ (phone) > On Jun 10, 2016, at 2:19 AM, Ben Coman wrote: > > > Random curiosity, why the name CoInterpreter and not CogInterpreter ? I like puns, multiple meanings, word play (don't we all?). Cog can be punned in many ways: the sense of a gear is perfect for a virtual machine, the Greek root for knowing/learning cogno-/cogni- perfect for a sophisticated virtual machine. The CoInterpreter co-operates with the Cogit. Welcome to the cognoscenti ;-) > > cheers -ben From estebanlm at gmail.com Fri Jun 10 13:01:01 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Fri Jun 10 13:01:05 2016 Subject: [Vm-dev] Migration to github status? In-Reply-To: References: <7D19D997-3EBD-4A60-A89C-0F548BB7A6D4@gmail.com> Message-ID: <806A15B1-7FF1-4C92-B96C-6DE6CCFACE04@gmail.com> Hi, Sorry for urging on this, but as I said, I need to start working in this? Fabio just told me that he is ready for the migration and this mails from Tim confirmes it? Can we schedule the migration? Let?s say some day next week? (Thursday, as Fabio suggested)? Can we have a ?good to go?? thanks! Esteban > On 07 Jun 2016, at 20:13, Tim Felgentreff wrote: > > Fabio and I have finished integrating the changes to move to Github with a minimal patch against the current Cog branch. All scripts and build files have been migrated and we are building VMs for Newspeak, Squeak, and Pharo in the available flavor combinations (stack, cog, sista, spur, v3) on (what we think are) the most important platforms (linux, mac, windows) and the most used architectures (x86, x86_64, ARM). > > The patch ist currently on github.com/timfel/squeakvm and can be rebased onto the current SVN easily. I have currently disabled uploading the build artifacts. I was thinking maybe we could still use Eliot's webspace or else Bintray, but whatever the community thinks works best. > > As soon as everyone is happy with it the patch, we need to find a time when we switch the SVN to read-only and I rebase the patch one last time and then we go live on OpenSmalltalk/vm > > Best, > Tim > Am 03.06.2016 15:25 schrieb "Esteban Lorenzano" >: > > Hi, > > Last week (with help of Clement) I put online the 64bits image generation for Pharo. > Our CI now is producing regularly 64bits for both: > > - Pharo 5: https://ci.inria.fr/pharo/view/5.0/job/Pharo-5.0-Update-Step-3.1-64bits/ > - Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.1-64bits > > Now? I would like to start testing it, and for that I need to build also PharoVM 64bits? I do not wan to reproduce all the work already done for running 64bits in current so I?m urging you to complete the migration, so I can start to merge my changes into the master, instead the opposite :) > > cheers, > Esteban > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160610/5001fd42/attachment-0001.htm From btc at openinworld.com Fri Jun 10 15:54:11 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 10 15:54:33 2016 Subject: [Vm-dev] CoInterpreter naming curiosity In-Reply-To: References: Message-ID: On Fri, Jun 10, 2016 at 8:30 PM, Eliot Miranda wrote: > >> On Jun 10, 2016, at 2:19 AM, Ben Coman wrote: >> >> Random curiosity, why the name CoInterpreter and not CogInterpreter ? > > I like puns, multiple meanings, word play (don't we all?). Cog can be punned in many ways: the sense of a gear is perfect for a virtual machine, the Greek root for knowing/learning cogno-/cogni- perfect for a sophisticated virtual machine. The CoInterpreter co-operates with the Cogit. Welcome to the cognoscenti ;-) cool. thx. cheers -ben From commits at squeakvm.org Sat Jun 11 00:32:12 2016 From: commits at squeakvm.org (commits@squeakvm.org) Date: Sat Jun 11 00:32:01 2016 Subject: [Vm-dev] [commit][3745] Fix typo in method signature Message-ID: Revision: 3745 Author: lewis Date: 2016-06-10 17:32:11 -0700 (Fri, 10 Jun 2016) Log Message: ----------- Fix typo in method signature Modified Paths: -------------- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h Modified: trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h =================================================================== --- trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h 2016-06-10 00:08:28 UTC (rev 3744) +++ trunk/platforms/Cross/plugins/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.h 2016-06-11 00:32:11 UTC (rev 3745) @@ -43,5 +43,5 @@ void primJPEGReadHeaderfromByteArraysizeerrorMgrReadHeader( char*, char*, - unsigned int); + unsigned int, char*); From btc at openinworld.com Sat Jun 11 16:48:55 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 11 16:49:18 2016 Subject: [Vm-dev] Take Two - Primitive retry across suspension for OwnedLock waitAcquire Message-ID: I've thrown away previous attempts including: * pushing primFailCode via the stack; * adding new instance variables to Process to store primFail, newMethod, primitiveFunctionPointer across context switches. * naively decrementing the instructionPointer and found a promising stepping-stone to alternative solution, which I'm hoping to get some feedback on. Using the following sample code (per attached changeset)... > OwnedLock>>experiment1 > | result | > result := OrderedCollection new: 20. > result myAdd: 0. > > [result myAdd: 11. > [result myAdd: 12. > self experimentSuccessAndSleep] on: Error do: [result myAdd: 13]. > result myAdd: 14] forkAt: 72. > > [result myAdd: 21. > [result myAdd: 22. > self experimentFailAndWakeOther] on: Error do: [result myAdd: 23]. > result myAdd: 24] forkAt: 71. > > result myAdd: 8. > self experimentSuccessAndWakeOther. > result myAdd: 9. > ^result. > Where the primitives are... > > primitiveExperimentSuccessAndSleep > | ownedLock activeProc | > ownedLock := self stackTop. > activeProc := self activeProcess. > self addLastLink: activeProc toList: ownedLock. > self transferTo: self wakeHighestPriority. > > primitiveExperimentFailAndWakeOther > | ownedLock waitingProcess | > ownedLock := self stackTop. > self primitiveFailFor: 42. > (self isEmptyList: ownedLock) > ifFalse: > [waitingProcess := self removeFirstLinkOfList: ownedLock. > self resume: waitingProcess preemptedYieldingIf: preemptionYields] > > primitiveExperimentSuccessAndWakeOther > | ownedLock waitingProcess | > ownedLock := self stackTop. "rcvr" > (self isEmptyList: ownedLock) > ifFalse: > [waitingProcess := self removeFirstLinkOfList: ownedLock. > self resume: waitingProcess preemptedYieldingIf: preemptionYields] and inputting the following to the "reader.image" ... o := OwnedLockExperiment new. o experiment1. ! I find that unaltered StackVM and CogVM differ in their results. The StackVM produces... an OrderedCollection(0 11 12 21 22 13 14 24 8 9) while CogVM produces... an OrderedCollection(0 11 12 21 22 14 24 8 9) The StackVM can be aligned with the CogVM by appending "self initPrimCall" to the end of StackInterpreter>>transferTo: after which the StackVM produces... an OrderedCollection(0 11 12 21 22 14 24 8 9) However I propose and request for comment(!) that the following result is preferable... OrderedCollection(0 11 12 21 22 14 23 24 8 9) and I've found a way to do it. ---------------------------------------------------- Observing the context switch execution flow for the StackVM (with a halt in primitiveExperimentFailAndWakeOther)... commonSendOrdinary internalFindNewMethodOrdinary internalExecuteNewMethod . slowPrimitiveResponse . . dispatchFunctionPointer: . . primitiveExperimentFailAndWakeOther . . primitiveFailFor: . . resume:preemptedYieldingIf: . . putToSleep:yieldingIf . . transferTo: CONTEXT SWITCH . . "initPrimCall added to align StackVM with CogVM" . . maybeRetryPrimitiveOnFailure . succeeded ifTrue:[self browserPluginReturnIfNeeded. ^nil]]. . "if not primitive, or primitive failed, activate the method" . self internalActivateNewMethod fetchNextBytecode the difference in #experiment1 between the StackVM and CogVM was primFailCode set by primitiveFailFor: before the context switch was being handled by restored process. But another way to deal with this would be to delay the context switch until *after* the primitive failure was handled, with an execution flow like this... commonSendOrdinary internalFindNewMethodOrdinary internalExecuteNewMethod . slowPrimitiveResponse . . dispatchFunctionPointer: . . primitiveExperimentFailAndWakeOther . . primitiveFailFor: . . resume:preemptedYieldingIf: . . putToSleep:yieldingIf . . transferTo: FLAG DELAYED CONTEXT SWITCH . . "initPrimCall added to align StackVM with CogVM" . . maybeRetryPrimitiveOnFailure . succeeded ifTrue:[self browserPluginReturnIfNeeded. ^nil]]. . "if not primitive, or primitive failed, activate the method" . self internalActivateNewMethod CONTEXT SWITCH fetchNextBytecode The attached ExperimentPrimitives-minimal.2.cs makes this change for the StackVM such that #experiment1 now produces... an OrderedCollection(0 11 12 21 22 14 23 24 8 9) as proposed above. In this way, the primFailCode doesn't need to be carried across the context switch. It is fully dealt with before the context switch. Now the reason I'm particularly interested in this, is that the context switch occurs immediately before the fetchNextBytecode at the end of the dispatch loop, and *possibly* provides the opportunity to *not* fetchNextBytecode when a process is woken up. For example, re-entering primitiveOwnedLockWaitAcquire when the process wakes up, so a lock can only be acquired by the activeProcess, and primitiveOwnedLockRelease does not assign locks to sleeping processes, it *only* releases the lock. But besides that, I believe my proposed change may provide some general benefit even if my plans for primitiveOwnedLockWaitAcquire don't pan out. REVIEW NOTES 1. Run buildExperimentReaderImage.sh to produce experiment-reader.image manually file in Experiment.2.cs then [save&quit] 2. Load ExperimentPrimitives-minimal.3.cs into SpurVMMaker.image 3. Run Stack and Cog simulators as follows.. | cos | cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager). cos desiredNumStackPages: 8. cos openOn: 'experiment-reader.image'. cos openAsMorph; run | cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit "SimpleStackBasedCogit" ObjectMemory Spur32BitCoMemoryManager "ISA ARMv5" "ISA IA32"). "cos initializeThreadSupport." cos desiredNumStackPages: 8. cos openOn: 'experiment-reader.image'. cos openAsMorph; run 4. Run this simulator code... o := OwnedLockExperiment new. o experiment1. ! Initially there are no changes. The changes are wrapped by variable delayedTransferEnabled. Uncomment the halt in StackInterpreter>>commonSendOrdinary to provide the opportunity to enable the new code. Uncomment "delayedTransferEnabled := true" in: commonSendDynamicSuper; commonSendImplicitReceiver; commonSendOrdinary; commonSendOuter: to test all the way from image bootup. (I don't know if those four really need the mod, but they all similarly called #internalExecuteNewMethod, so its a guess it is) cheers -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: experiment.zip Type: application/zip Size: 172 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160612/c560c886/experiment.zip From btc at openinworld.com Sun Jun 12 06:35:18 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 12 06:35:41 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: I am stepping for the first time through the CogVM, having [set break selector...] forkAt: After stepping in a few times I get to #activateCoggedNewMethod. CogVMSimulatorLSB(CoInterpreter)>>dispatchOn:in: CogVMSimulatorLSB(CoInterpreter)>>sendLiteralSelector1ArgBytecode CogVMSimulatorLSB(CoInterpreter)>>commonSendOrdinary CogVMSimulatorLSB(CoInterpreter)>>insternalExecuteNewMethod CogVMSimulatorLSB(CoInterpreter)>>activateCoggedNewMethod Here from the code at the top. methodHeader := self rawHeaderOf: newMethod. self assert: (self isCogMethodReference: methodHeader). cogMethod := self cCoerceSimple: methodHeader to: #'CogMethod *'. methodHeader := cogMethod methodHeader. I guess methodHeader's double assignment above is related to the machine code frame having two addresses as Clement described... >> On Mon, May 30, 2016 at 4:12 PM, Cl?ment Bera wrote: >>> Now that you've print the frame, you can see the method addresses in this line: >>> 16r103144: method: 16r51578 16r102BDD0 16r102BDD0: a(n) CompiledMethod. >>> This is a machine code frame, so the method has two addresses: >>> 16r51578 => in generated method, so you need to use [disassembleMethod/trampoline...] and write down the hex to see the disassembly. >>> 16r102BDD0 => in the heap. This is the bytecode version of the method. You can print it using [print oop...] This time... [print ext head frame] ==> 16r101214 M BlockClosure>forkAt: 16r2FC420: a(n) BlockClosure 16r101210: method: 16rBBF0 16rC4E948 16rC4E948: a(n) CompiledMethod self rawHeaderOf: newMethod ==> 16rBBF0 So the "raw header" is the cogged method. Looking at the output below, the space ship operator <-> seems to link between cogged method headers like a call stack, except #forkAt: calls #newProcess which calls #asContext [print cog method for...] 16rBBF0 ==> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: [print cog method for...] 16rBC80 ==> 16rBC80 <-> 16rBEA8: method: 16rC51970 prim 19 selector: 16r6D1620 newProcess [print cog method for...] 16rBEA8 ==> 16rBEA8 <-> 16rBF28: method: 16rC518C0 selector: 16r76A600 asContext However the links don't seem to go back up the call stack but forward, to statements to be executed in the future. So I am confused? ------------- Considering further [print cog method for...] 16rBBF0 ==> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: [print oop...] 16r6CC798 ==> a(n) ByteSymbol nbytes 7 forkAt: Clement early advised is the bytecode version of the method is this... [print oop...] 16rC4E948 ==> 16rC4E948: a(n) CompiledMethod nbytes 37 16rBBF0 is in generated methods 16r6D1620 #newProcess 16r6CC650 #priority: 16r6CC690 #resume 16r6CC798 #forkAt: 16rAE5490 a ClassBinding #BlockClosure -> 16r0088D618 16rC4E968: 70/112 D0/208 88/136 10/16 E1/225 87/135 D2/210 7C/124 16rC4E970: 28/40 AF/175 BA/186 F3/243 20/32 Now I've been a bit slow on the uptake and only just realised, but to confirm... the line 16r6CC798 is the one specifying the method as BlockClosure>>forkAt: For the last two lines, I notice the numbers before the slash (70, 88, 10...) are the method bytecode, but what are the numbers after the slash? ---------------- In #activeCoggedNewMethod: the second assignment to methodHeader ==> 16r208000B which matches the mthhdr field of the raw header [print cog method header for...] 16rBBF0 ==> BBF0 objhdr: 8000000A000035 nArgs: 1 type: 2 blksiz: 90 method: C4E948 mthhdr: 208000B selctr: 6CC798=#forkAt: blkentry: 0 stackCheckOffset: 5E/BC4E cmRefersToYoung: no cmIsFullBlock: no What is "type: 2" ? -------------------------- Stepping through to Cogit>>ceEnterCogCodePopReceiverReg I notice its protocol is "simulation only" and it calls "simulateEnilopmart:numArgs: ceEnterCogCodePopReceiverReg" but I don't see any other implementors of #ceEnterCogCodePopReceiverReg. Also there is a pragma . Obviously the real non-simulated VM works differently, but I can't determine how. btw, I have noticed that ceEnterCogCodePopReceiverReg ==> 16r10B8 and [print cog method for...] 16r10B8 ==> trampoline ceEnterCogCodePopReceiverReg Is ceEnterCogCodePopReceiverReg provided by the platform C code? --------------------------- Stepping through to simulateCogCodeAt: it called processor singleStepIn:minimumAddress:readOnlyBelow: which called BochsIA32Alien>>primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: ^ec == #'inappropriate operation' ifTrue: [self handleExecutionPrimitiveFailureIn: memoryArray minimumAddress: minimumAddress] ifFalse: [self reportPrimitiveFailure] and the debugger cursor was inside the ifTrue: statement. I found I didn't have bochs installed, but after installing bochs-2.6-2, I go the same result. So could I get some background around this.. Also I'm curious how the simulator seemed to be running a CogVM before bochs was installed. Perhaps since I was not debugging through it, the machine code ran for real rather than being simulated. cheers -ben From bera.clement at gmail.com Sun Jun 12 08:44:02 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Sun Jun 12 08:44:24 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: Hi Ben, I'm glad you're now looking into the JIT. If you have some blog or something, please write an experience report about you looking into the simulator. It's helpful for us to have noise around the VM. On Sun, Jun 12, 2016 at 8:35 AM, Ben Coman wrote: > > I am stepping for the first time through the CogVM, having [set break > selector...] forkAt: > After stepping in a few times I get to #activateCoggedNewMethod. > CogVMSimulatorLSB(CoInterpreter)>>dispatchOn:in: > CogVMSimulatorLSB(CoInterpreter)>>sendLiteralSelector1ArgBytecode > CogVMSimulatorLSB(CoInterpreter)>>commonSendOrdinary > CogVMSimulatorLSB(CoInterpreter)>>insternalExecuteNewMethod > CogVMSimulatorLSB(CoInterpreter)>>activateCoggedNewMethod > > Here from the code at the top. > methodHeader := self rawHeaderOf: newMethod. > self assert: (self isCogMethodReference: methodHeader). > cogMethod := self cCoerceSimple: methodHeader to: #'CogMethod *'. > methodHeader := cogMethod methodHeader. > > I guess methodHeader's double assignment above is related to the > machine code frame having two addresses as Clement described... > Errr... I don't really fancy the way you say it but I think yes that's it. A method can have 2 addresses, the address of the bytecoded version in the heap and the address of its jitted version in the machine code zone. In the machine code frame printing, the simulator displays the 2 addresses. But the frame has a single pointer to the method. So what you're looking at is the dispatch logic from the bytecoded method to the jitted method. When the JIT compiles a bytecoded method to machine code, it replaces the bytecoded method compiled method header (first literal) by a pointer to the jitted version. The machine code version of the method keeps the compiled method header, so accessing it is different in methods compiled to machine code and methods not compiled to machine code. #rawHeaderOf: answers the first literal of the bytecoded method which is a pointer to the jitted version of the method if the method has a jitted version, else is the compiled method header. In the code you show, the VM ensures the method has a jitted version with the assertion, hence the compiled method header is fetched from the jitted version. > >> On Mon, May 30, 2016 at 4:12 PM, Cl?ment Bera > wrote: > >>> Now that you've print the frame, you can see the method addresses in > this line: > >>> 16r103144: method: 16r51578 16r102BDD0 16r102BDD0: a(n) > CompiledMethod. > >>> This is a machine code frame, so the method has two addresses: > >>> 16r51578 => in generated method, so you need to use > [disassembleMethod/trampoline...] and write down the hex to see the > disassembly. > >>> 16r102BDD0 => in the heap. This is the bytecode version of the method. > You can print it using [print oop...] > > This time... > [print ext head frame] ==> > 16r101214 M BlockClosure>forkAt: 16r2FC420: a(n) BlockClosure > 16r101210: method: 16rBBF0 16rC4E948 16rC4E948: a(n) CompiledMethod > > self rawHeaderOf: newMethod ==> 16rBBF0 > So the "raw header" is the cogged method. > > Looking at the output below, the space ship operator <-> seems to link > between cogged method headers like a call stack, except #forkAt: > calls #newProcess which calls #asContext > > [print cog method for...] 16rBBF0 ==> > 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: > > [print cog method for...] 16rBC80 ==> > 16rBC80 <-> 16rBEA8: method: 16rC51970 prim 19 selector: 16r6D1620 > newProcess > > [print cog method for...] 16rBEA8 ==> > 16rBEA8 <-> 16rBF28: method: 16rC518C0 selector: 16r76A600 > asContext > > However the links don't seem to go back up the call stack but forward, > to statements to be executed in the future. So I am confused? > Yeah it's the jitted version of the method header address, then <->, then the jitted method entry point address, the bytecode version address, selector address. The cogMethod header is used to store the bytecoded compiled method header (because it was replaced with a pointer to the cogMethod) and various flags. > > ------------- > > Considering further [print cog method for...] 16rBBF0 ==> > 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: > > [print oop...] 16r6CC798 ==> > a(n) ByteSymbol nbytes 7 forkAt: > > Clement early advised is the bytecode version of the method is this... > [print oop...] 16rC4E948 ==> > 16rC4E948: a(n) CompiledMethod nbytes 37 > 16rBBF0 is in generated methods > 16r6D1620 #newProcess 16r6CC650 #priority: 16r6CC690 #resume > 16r6CC798 #forkAt: 16rAE5490 a ClassBinding #BlockClosure -> > 16r0088D618 > 16rC4E968: 70/112 D0/208 88/136 10/16 E1/225 87/135 D2/210 7C/124 > 16rC4E970: 28/40 AF/175 BA/186 F3/243 20/32 > > Now I've been a bit slow on the uptake and only just realised, but to > confirm... > the line 16r6CC798 is the one specifying the method as > BlockClosure>>forkAt: > 16r6CC798 is the address of the selector #forkAt: > For the last two lines, I notice the numbers before the slash (70, 88, > 10...) are the method bytecode, but what are the numbers after the > slash? > The bytecode in decimal instead of hexa I think. > > ---------------- > > In #activeCoggedNewMethod: the second assignment to methodHeader > ==> 16r208000B > > which matches the mthhdr field of the raw header > [print cog method header for...] 16rBBF0 ==> > BBF0 > objhdr: 8000000A000035 > nArgs: 1 type: 2 > blksiz: 90 > method: C4E948 > mthhdr: 208000B > selctr: 6CC798=#forkAt: > blkentry: 0 > stackCheckOffset: 5E/BC4E > cmRefersToYoung: no cmIsFullBlock: no > > What is "type: 2" ? > Haha. Well when you iterate over the machine code zone you need to know what the current element you iterate on is. In the machine code zone there can be: - cog method - closed PICS - open PICS - free space And now we're adding cog full block method but it's sharing the index with cog method and have a separated flag :-) The type tells you what it is. Look at the Literal variables CMFree, CMClosedPIC, CMOpenPIC, etc . 2 is CMMethod with is a constant. You can improve the printing there and commit the changes if you feel so. Ok I have to go I will look at the rest of your mail later. > > -------------------------- > > Stepping through to Cogit>>ceEnterCogCodePopReceiverReg > I notice its protocol is "simulation only" > and it calls "simulateEnilopmart:numArgs: ceEnterCogCodePopReceiverReg" > but I don't see any other implementors of #ceEnterCogCodePopReceiverReg. > Also there is a pragma . > > Obviously the real non-simulated VM works differently, but I can't > determine how. > > btw, I have noticed that ceEnterCogCodePopReceiverReg > ==> 16r10B8 > and [print cog method for...] 16r10B8 > ==> trampoline ceEnterCogCodePopReceiverReg > > Is ceEnterCogCodePopReceiverReg provided by the platform C code? > > --------------------------- > Stepping through to simulateCogCodeAt: > it called processor singleStepIn:minimumAddress:readOnlyBelow: > which called > BochsIA32Alien>>primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: > module: 'BochsIA32Plugin' > error: ec> > ^ec == #'inappropriate operation' > ifTrue: [self handleExecutionPrimitiveFailureIn: memoryArray > minimumAddress: minimumAddress] > ifFalse: [self reportPrimitiveFailure] > > and the debugger cursor was inside the ifTrue: statement. I found I > didn't have bochs installed, but after installing bochs-2.6-2, I go > the same result. So could I get some background around this.. > > Also I'm curious how the simulator seemed to be running a CogVM before > bochs was installed. Perhaps since I was not debugging through it, the > machine code ran for real rather than being simulated. > > cheers -ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160612/a2773c3c/attachment-0001.htm From bera.clement at gmail.com Sun Jun 12 14:59:41 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Sun Jun 12 15:00:02 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: Hi again, On Sun, Jun 12, 2016 at 10:44 AM, Cl?ment Bera wrote: > Hi Ben, > > I'm glad you're now looking into the JIT. If you have some blog or > something, please write an experience report about you looking into the > simulator. It's helpful for us to have noise around the VM. > > On Sun, Jun 12, 2016 at 8:35 AM, Ben Coman wrote: > >> >> I am stepping for the first time through the CogVM, having [set break >> selector...] forkAt: >> After stepping in a few times I get to #activateCoggedNewMethod. >> CogVMSimulatorLSB(CoInterpreter)>>dispatchOn:in: >> CogVMSimulatorLSB(CoInterpreter)>>sendLiteralSelector1ArgBytecode >> CogVMSimulatorLSB(CoInterpreter)>>commonSendOrdinary >> CogVMSimulatorLSB(CoInterpreter)>>insternalExecuteNewMethod >> CogVMSimulatorLSB(CoInterpreter)>>activateCoggedNewMethod >> >> Here from the code at the top. >> methodHeader := self rawHeaderOf: newMethod. >> self assert: (self isCogMethodReference: methodHeader). >> cogMethod := self cCoerceSimple: methodHeader to: #'CogMethod *'. >> methodHeader := cogMethod methodHeader. >> >> I guess methodHeader's double assignment above is related to the >> machine code frame having two addresses as Clement described... >> > > Errr... I don't really fancy the way you say it but I think yes that's it. > > A method can have 2 addresses, the address of the bytecoded version in the > heap and the address of its jitted version in the machine code zone. In the > machine code frame printing, the simulator displays the 2 addresses. But > the frame has a single pointer to the method. > > So what you're looking at is the dispatch logic from the bytecoded method > to the jitted method. When the JIT compiles a bytecoded method to machine > code, it replaces the bytecoded method compiled method header (first > literal) by a pointer to the jitted version. The machine code version of > the method keeps the compiled method header, so accessing it is different > in methods compiled to machine code and methods not compiled to machine > code. > > #rawHeaderOf: answers the first literal of the bytecoded method which is a > pointer to the jitted version of the method if the method has a jitted > version, else is the compiled method header. In the code you show, the VM > ensures the method has a jitted version with the assertion, hence the > compiled method header is fetched from the jitted version. > > >> >> On Mon, May 30, 2016 at 4:12 PM, Cl?ment Bera >> wrote: >> >>> Now that you've print the frame, you can see the method addresses in >> this line: >> >>> 16r103144: method: 16r51578 16r102BDD0 16r102BDD0: a(n) >> CompiledMethod. >> >>> This is a machine code frame, so the method has two addresses: >> >>> 16r51578 => in generated method, so you need to use >> [disassembleMethod/trampoline...] and write down the hex to see the >> disassembly. >> >>> 16r102BDD0 => in the heap. This is the bytecode version of the >> method. You can print it using [print oop...] >> >> This time... >> [print ext head frame] ==> >> 16r101214 M BlockClosure>forkAt: 16r2FC420: a(n) BlockClosure >> 16r101210: method: 16rBBF0 16rC4E948 16rC4E948: a(n) CompiledMethod >> >> self rawHeaderOf: newMethod ==> 16rBBF0 >> So the "raw header" is the cogged method. >> >> Looking at the output below, the space ship operator <-> seems to link >> between cogged method headers like a call stack, except #forkAt: >> calls #newProcess which calls #asContext >> >> [print cog method for...] 16rBBF0 ==> >> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: >> >> [print cog method for...] 16rBC80 ==> >> 16rBC80 <-> 16rBEA8: method: 16rC51970 prim 19 selector: 16r6D1620 >> newProcess >> >> [print cog method for...] 16rBEA8 ==> >> 16rBEA8 <-> 16rBF28: method: 16rC518C0 selector: 16r76A600 >> asContext >> >> However the links don't seem to go back up the call stack but forward, >> to statements to be executed in the future. So I am confused? >> > > Yeah it's the jitted version of the method header address, then <->, then > the jitted method entry point address, the bytecode version address, > selector address. > > The cogMethod header is used to store the bytecoded compiled method header > (because it was replaced with a pointer to the cogMethod) and various flags. > > >> >> ------------- >> >> Considering further [print cog method for...] 16rBBF0 ==> >> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: >> >> [print oop...] 16r6CC798 ==> >> a(n) ByteSymbol nbytes 7 forkAt: >> >> Clement early advised is the bytecode version of the method is this... >> [print oop...] 16rC4E948 ==> >> 16rC4E948: a(n) CompiledMethod nbytes 37 >> 16rBBF0 is in generated methods >> 16r6D1620 #newProcess 16r6CC650 #priority: 16r6CC690 #resume >> 16r6CC798 #forkAt: 16rAE5490 a ClassBinding #BlockClosure -> >> 16r0088D618 >> 16rC4E968: 70/112 D0/208 88/136 10/16 E1/225 87/135 D2/210 7C/124 >> 16rC4E970: 28/40 AF/175 BA/186 F3/243 20/32 >> >> Now I've been a bit slow on the uptake and only just realised, but to >> confirm... >> the line 16r6CC798 is the one specifying the method as >> BlockClosure>>forkAt: >> > > 16r6CC798 is the address of the selector #forkAt: > > >> For the last two lines, I notice the numbers before the slash (70, 88, >> 10...) are the method bytecode, but what are the numbers after the >> slash? >> > > The bytecode in decimal instead of hexa I think. > > >> >> ---------------- >> >> In #activeCoggedNewMethod: the second assignment to methodHeader >> ==> 16r208000B >> >> which matches the mthhdr field of the raw header >> [print cog method header for...] 16rBBF0 ==> >> BBF0 >> objhdr: 8000000A000035 >> nArgs: 1 type: 2 >> blksiz: 90 >> method: C4E948 >> mthhdr: 208000B >> selctr: 6CC798=#forkAt: >> blkentry: 0 >> stackCheckOffset: 5E/BC4E >> cmRefersToYoung: no cmIsFullBlock: no >> >> What is "type: 2" ? >> > > Haha. > > Well when you iterate over the machine code zone you need to know what the > current element you iterate on is. In the machine code zone there can be: > - cog method > - closed PICS > - open PICS > - free space > And now we're adding cog full block method but it's sharing the index with > cog method and have a separated flag :-) > > The type tells you what it is. Look at the Literal > variables CMFree, CMClosedPIC, CMOpenPIC, etc . > > 2 is CMMethod with is a constant. You can improve the printing there and > commit the changes if you feel so. > What did I write here I don't understand myself ? I mean CMMethod = 2, so type = 2 means the struct you're looking at in the machine code zone is a method and not free space or a PIC. > > Ok I have to go I will look at the rest of your mail later. > Let's do this... > > >> >> -------------------------- >> >> Stepping through to Cogit>>ceEnterCogCodePopReceiverReg >> I notice its protocol is "simulation only" >> and it calls "simulateEnilopmart:numArgs: ceEnterCogCodePopReceiverReg" >> but I don't see any other implementors of #ceEnterCogCodePopReceiverReg. >> Also there is a pragma . >> >> Obviously the real non-simulated VM works differently, but I can't >> determine how. >> >> btw, I have noticed that ceEnterCogCodePopReceiverReg >> ==> 16r10B8 >> and [print cog method for...] 16r10B8 >> ==> trampoline ceEnterCogCodePopReceiverReg >> >> Is ceEnterCogCodePopReceiverReg provided by the platform C code? >> > Well it's in cogitIA32.c. I don't remember where it comes from. Basically in Cog you have specific machine code routines, called trampolines, that switch from machine code to C code. When trampoline is written backward (Enilopmart) it means that the routine is meant to switch from C code to machine code. The real VM calls in ceEnterCogCodePopReceiverReg a machine code routine that does the right thing (register remapped, maybe fp and sp saved, etc) to switch from the C runtime from the C compiler to the machine code runtime executing code generated by the JIT. In simulation, the C code is simulated by executing Slang as Smalltalk code and the machine code is simulated using the processor simulator (Bochs for IA32). So it has to be done differently as there is no C stack with register state and stuff. Both trampolines and enilmoparts are simulated with specific code. > >> --------------------------- >> Stepping through to simulateCogCodeAt: >> it called processor singleStepIn:minimumAddress:readOnlyBelow: >> which called >> BochsIA32Alien>>primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: >> > module: 'BochsIA32Plugin' >> error: ec> >> ^ec == #'inappropriate operation' >> ifTrue: [self handleExecutionPrimitiveFailureIn: memoryArray >> minimumAddress: minimumAddress] >> ifFalse: [self reportPrimitiveFailure] >> >> and the debugger cursor was inside the ifTrue: statement. I found I >> didn't have bochs installed, but after installing bochs-2.6-2, I go >> the same result. So could I get some background around this.. >> >> Also I'm curious how the simulator seemed to be running a CogVM before >> bochs was installed. Perhaps since I was not debugging through it, the >> machine code ran for real rather than being simulated. >> >> No the machine code is always simulated. Bochs was working for sure if you successfully simulated the image on top of the cog simulator until the display was shown. If you have a VM from one of Eliot's build (from the Cog blog) the processor simulators are present as plugins by default. On Mac you can do [show package contents...] and then look at the file inside to check the Bochs Plugin is there. It's not the case on the Pharo VMs so don't use them for CogVM simulation. You don't need to install anything. On normal simulation the simulator goes often in the branch you've just shown. It means it reached a simulation trap. As for enilmopart that can't be properly simulated, trampolines can't be simulated. So to simulate a trampoline the processor simulator fails a call and the trampoline is done in the simulation code. Look at #handleCallOrJumpSimulationTrap: for example. > cheers -ben >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160612/bff33f25/attachment-0001.htm From btc at openinworld.com Sun Jun 12 17:36:32 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 12 17:36:56 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: On Sun, Jun 12, 2016 at 10:59 PM, Cl?ment Bera wrote: > > Hi again, > > On Sun, Jun 12, 2016 at 10:44 AM, Cl?ment Bera wrote: >> >> Hi Ben, >> >> I'm glad you're now looking into the JIT. If you have some blog or something, please write an experience report about you looking into the simulator. It's helpful for us to have noise around the VM. Cool. I'll have a go. >> >> On Sun, Jun 12, 2016 at 8:35 AM, Ben Coman wrote: >>> >>> >>> I am stepping for the first time through the CogVM, having [set break >>> selector...] forkAt: >>> After stepping in a few times I get to #activateCoggedNewMethod. >>> CogVMSimulatorLSB(CoInterpreter)>>dispatchOn:in: >>> CogVMSimulatorLSB(CoInterpreter)>>sendLiteralSelector1ArgBytecode >>> CogVMSimulatorLSB(CoInterpreter)>>commonSendOrdinary >>> CogVMSimulatorLSB(CoInterpreter)>>insternalExecuteNewMethod >>> CogVMSimulatorLSB(CoInterpreter)>>activateCoggedNewMethod >>> >>> Here from the code at the top. >>> methodHeader := self rawHeaderOf: newMethod. >>> self assert: (self isCogMethodReference: methodHeader). >>> cogMethod := self cCoerceSimple: methodHeader to: #'CogMethod *'. >>> methodHeader := cogMethod methodHeader. >>> >>> I guess methodHeader's double assignment above is related to the >>> machine code frame having two addresses as Clement described... >> >> >> Errr... I don't really fancy the way you say it but I think yes that's it. >> >> A method can have 2 addresses, the address of the bytecoded version in the heap and the address of its jitted version in the machine code zone. In the machine code frame printing, the simulator displays the 2 addresses. But the frame has a single pointer to the method. >> >> So what you're looking at is the dispatch logic from the bytecoded method to the jitted method. When the JIT compiles a bytecoded method to machine code, it replaces the bytecoded method compiled method header (first literal) by a pointer to the jitted version. The machine code version of the method keeps the compiled method header, so accessing it is different in methods compiled to machine code and methods not compiled to machine code. >> >> #rawHeaderOf: answers the first literal of the bytecoded method which is a pointer to the jitted version of the method if the method has a jitted version, else is the compiled method header. In the code you show, the VM ensures the method has a jitted version with the assertion, hence the compiled method header is fetched from the jitted version. I think I've got it. So upon JITing, CompiledMethod and its literals and bytecodes don't move. Only its bytecodeHeader is manipulated and re-purposed. Before JIT... compiledMethod := { bytecodeHeader, literals, bytecodes }. byteCodeHeader := compiledMethod at: 1 After JIT something like... cogMethod := { cogMethodHeader, bytecodeHeader, machineCode } compiledMethod := { pointerTo_cogMethod, literals, bytecodes }. rawHeader := compiledMethod at: 1 cogMethodHeader := dereferenced(rawHeader) at: 1. >> >>> >>> >> On Mon, May 30, 2016 at 4:12 PM, Cl?ment Bera wrote: >>> >>> Now that you've print the frame, you can see the method addresses in this line: >>> >>> 16r103144: method: 16r51578 16r102BDD0 16r102BDD0: a(n) CompiledMethod. >>> >>> This is a machine code frame, so the method has two addresses: >>> >>> 16r51578 => in generated method, so you need to use [disassembleMethod/trampoline...] and write down the hex to see the disassembly. >>> >>> 16r102BDD0 => in the heap. This is the bytecode version of the method. You can print it using [print oop...] >>> >>> This time... >>> [print ext head frame] ==> >>> 16r101214 M BlockClosure>forkAt: 16r2FC420: a(n) BlockClosure >>> 16r101210: method: 16rBBF0 16rC4E948 16rC4E948: a(n) CompiledMethod >>> >>> self rawHeaderOf: newMethod ==> 16rBBF0 >>> So the "raw header" is the cogged method. >>> >>> Looking at the output below, the space ship operator <-> seems to link >>> between cogged method headers like a call stack, except #forkAt: >>> calls #newProcess which calls #asContext >>> >>> [print cog method for...] 16rBBF0 ==> >>> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: >>> >>> [print cog method for...] 16rBC80 ==> >>> 16rBC80 <-> 16rBEA8: method: 16rC51970 prim 19 selector: 16r6D1620 newProcess >>> >>> [print cog method for...] 16rBEA8 ==> >>> 16rBEA8 <-> 16rBF28: method: 16rC518C0 selector: 16r76A600 asContext >>> >>> However the links don't seem to go back up the call stack but forward, >>> to statements to be executed in the future. So I am confused? >> >> >> Yeah it's the jitted version of the method header address, then <->, then the jitted method entry point address, the bytecode version address, selector address. >> >> The cogMethod header is used to store the bytecoded compiled method header (because it was replaced with a pointer to the cogMethod) and various flags. >> >>> >>> >>> ------------- >>> >>> Considering further [print cog method for...] 16rBBF0 ==> >>> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: >>> >>> [print oop...] 16r6CC798 ==> >>> a(n) ByteSymbol nbytes 7 forkAt: >>> >>> Clement early advised is the bytecode version of the method is this... >>> [print oop...] 16rC4E948 ==> >>> 16rC4E948: a(n) CompiledMethod nbytes 37 >>> 16rBBF0 is in generated methods >>> 16r6D1620 #newProcess 16r6CC650 #priority: 16r6CC690 #resume >>> 16r6CC798 #forkAt: 16rAE5490 a ClassBinding #BlockClosure -> 16r0088D618 >>> 16rC4E968: 70/112 D0/208 88/136 10/16 E1/225 87/135 D2/210 7C/124 >>> 16rC4E970: 28/40 AF/175 BA/186 F3/243 20/32 >>> >>> Now I've been a bit slow on the uptake and only just realised, but to confirm... >>> the line 16r6CC798 is the one specifying the method as BlockClosure>>forkAt: >> >> 16r6CC798 is the address of the selector #forkAt: Sorry I wasn't clear. I wasn't referring to the address itself of the selector - that was just a line reference. My insight I wanted to confirm was that the last oop before the bytecode was... a ClassBinding #BlockClosure -> 16r0088D618 and the next last before that was... #forkAt: 16rAE5490 indicating the output of [print oop...] was method BlockClosure>>forkAt: , while above that line are the methods called by #forkAt: and below it is the bytecode. Ahhh, actually I just saw this relevant comment in CompiledMethod... "The last literal in a CompiledMethod must be its methodClassAssociation, a binding whose value is the class the method is installed in. The methodClassAssociation is used to implement super sends. If a method contains no super send then its methodClassAssociation may be nil (as would be the case for example of methods providing a pool of inst var accessors). By convention the penultimate literal of a method is either its selector or an instance of AdditionalMethodState. " So it seems it won't always show the Class>>method, but often will. >> >>> >>> For the last two lines, I notice the numbers before the slash (70, 88, >>> 10...) are the method bytecode, but what are the numbers after the >>> slash? >> >> >> The bytecode in decimal instead of hexa I think. I checked. You are right. Obvious in hindsight. >>> ---------------- >>> >>> In #activeCoggedNewMethod: the second assignment to methodHeader >>> ==> 16r208000B >>> >>> which matches the mthhdr field of the raw header >>> [print cog method header for...] 16rBBF0 ==> >>> BBF0 >>> objhdr: 8000000A000035 >>> nArgs: 1 type: 2 >>> blksiz: 90 >>> method: C4E948 >>> mthhdr: 208000B >>> selctr: 6CC798=#forkAt: >>> blkentry: 0 >>> stackCheckOffset: 5E/BC4E >>> cmRefersToYoung: no cmIsFullBlock: no >>> >>> What is "type: 2" ? >> >> >> Haha. >> >> Well when you iterate over the machine code zone you need to know what the current element you iterate on is. In the machine code zone there can be: >> - cog method >> - closed PICS >> - open PICS >> - free space >> And now we're adding cog full block method but it's sharing the index with cog method and have a separated flag :-) >> >> The type tells you what it is. Look at the Literal variables CMFree, CMClosedPIC, CMOpenPIC, etc . >> >> 2 is CMMethod with is a constant. You can improve the printing there and commit the changes if you feel so. > > > What did I write here I don't understand myself ? I mean CMMethod = 2, so type = 2 means the struct you're looking at in the machine code zone is a method and not free space or a PIC. >> >> >> Ok I have to go I will look at the rest of your mail later. > > > Let's do this... >> >> >>> >>> >>> -------------------------- >>> >>> Stepping through to Cogit>>ceEnterCogCodePopReceiverReg >>> I notice its protocol is "simulation only" >>> and it calls "simulateEnilopmart:numArgs: ceEnterCogCodePopReceiverReg" >>> but I don't see any other implementors of #ceEnterCogCodePopReceiverReg. >>> Also there is a pragma . >>> >>> Obviously the real non-simulated VM works differently, but I can't >>> determine how. >>> >>> btw, I have noticed that ceEnterCogCodePopReceiverReg >>> ==> 16r10B8 >>> and [print cog method for...] 16r10B8 >>> ==> trampoline ceEnterCogCodePopReceiverReg >>> >>> Is ceEnterCogCodePopReceiverReg provided by the platform C code? > > > Well it's in cogitIA32.c. I don't remember where it comes from. Cool. I had a peek. > > Basically in Cog you have specific machine code routines, called trampolines, that switch from machine code to C code. When trampoline is written backward (Enilopmart) it means that the routine is meant to switch from C code to machine code. > > The real VM calls in ceEnterCogCodePopReceiverReg a machine code routine that does the right thing (register remapped, maybe fp and sp saved, etc) to switch from the C runtime from the C compiler to the machine code runtime executing code generated by the JIT. I see its a function pointer... void (*ceEnterCogCodePopReceiverReg)(void) set by... ceEnterCogCodePopReceiverReg = genEnilopmartForandandforCallcalled(ReceiverResultReg, NoReg, NoReg, 0, "ceEnterCogCodePopReceiverReg"); which is beyond my current level need-to-know. Still useful to fill in the background architecture. This comment comparing trampoline/enilopmart to system-call-like transition was enlightening... /* An enilopmart (the reverse of a trampoline) is a piece of code that makes the system-call-like transition from the C runtime into generated machine code. The desired arguments and entry-point are pushed on a stackPage's stack. The enilopmart pops off the values to be loaded into registers and then executes a return instruction to pop off the entry-point and jump to it. BEFORE AFTER (stacks grow down) whatever stackPointer -> whatever target address => reg1 = reg1val, etc reg1val pc = target address reg2val stackPointer -> reg3val */ /* Cogit>>#genEnilopmartFor:and:and:forCall:called: */ > > In simulation, the C code is simulated by executing Slang as Smalltalk code and the machine code is simulated using the processor simulator (Bochs for IA32). So it has to be done differently as there is no C stack with register state and stuff. Both trampolines and enilmoparts are simulated with specific code. > >>> >>> >>> --------------------------- >>> Stepping through to simulateCogCodeAt: >>> it called processor singleStepIn:minimumAddress:readOnlyBelow: >>> which called BochsIA32Alien>>primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: >>> >> module: 'BochsIA32Plugin' >>> error: ec> >>> ^ec == #'inappropriate operation' >>> ifTrue: [self handleExecutionPrimitiveFailureIn: memoryArray >>> minimumAddress: minimumAddress] >>> ifFalse: [self reportPrimitiveFailure] >>> >>> and the debugger cursor was inside the ifTrue: statement. I found I >>> didn't have bochs installed, but after installing bochs-2.6-2, I go >>> the same result. So could I get some background around this.. >>> >>> Also I'm curious how the simulator seemed to be running a CogVM before >>> bochs was installed. Perhaps since I was not debugging through it, the >>> machine code ran for real rather than being simulated. >>> > > No the machine code is always simulated. Bochs was working for sure if you successfully simulated the image on top of the cog simulator until the display was shown. > > If you have a VM from one of Eliot's build (from the Cog blog) the processor simulators are present as plugins by default. On Mac you can do [show package contents...] and then look at the file inside to check the Bochs Plugin is there. It's not the case on the Pharo VMs so don't use them for CogVM simulation. You don't need to install anything. Ahhh... I see them now. ./lib/squeak/5.0-3692/BochsX64Plugin ./lib/squeak/5.0-3692/BochsIA32Plugin The clears my misconception - a lack of understanding the purpose of the primitive failure and a red herring when I saw the Boch's system package wasn't installed. > > On normal simulation the simulator goes often in the branch you've just shown. It means it reached a simulation trap. As for enilmopart that can't be properly simulated, trampolines can't be simulated. So to simulate a trampoline the processor simulator fails a call and the trampoline is done in the simulation code. Look at #handleCallOrJumpSimulationTrap: for example. Ah, so its an 'inappropriate operation' from Bochs' perspective, but from the Simulator's perspective the primitiveFail is a useful condition like the #ensure: "Primitive 198 always fails. The VM uses prim 198 in a context's method as the mark for an ensure:/ifCurtailed: activation." ? cheers -ben btw, I bumped into a bit of history... http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/ From eliot.miranda at gmail.com Sun Jun 12 17:59:21 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun Jun 12 17:59:25 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: Hi Ben, On Sun, Jun 12, 2016 at 10:36 AM, Ben Coman wrote: > > On Sun, Jun 12, 2016 at 10:59 PM, Cl?ment Bera > wrote: > > > > Hi again, > > > > On Sun, Jun 12, 2016 at 10:44 AM, Cl?ment Bera > wrote: > >> > >> Hi Ben, > >> > >> I'm glad you're now looking into the JIT. If you have some blog or > something, please write an experience report about you looking into the > simulator. It's helpful for us to have noise around the VM. > > Cool. I'll have a go. > > >> > >> On Sun, Jun 12, 2016 at 8:35 AM, Ben Coman wrote: > >>> > >>> > >>> I am stepping for the first time through the CogVM, having [set break > >>> selector...] forkAt: > >>> After stepping in a few times I get to #activateCoggedNewMethod. > >>> CogVMSimulatorLSB(CoInterpreter)>>dispatchOn:in: > >>> CogVMSimulatorLSB(CoInterpreter)>>sendLiteralSelector1ArgBytecode > >>> CogVMSimulatorLSB(CoInterpreter)>>commonSendOrdinary > >>> CogVMSimulatorLSB(CoInterpreter)>>insternalExecuteNewMethod > >>> CogVMSimulatorLSB(CoInterpreter)>>activateCoggedNewMethod > >>> > >>> Here from the code at the top. > >>> methodHeader := self rawHeaderOf: newMethod. > >>> self assert: (self isCogMethodReference: methodHeader). > >>> cogMethod := self cCoerceSimple: methodHeader to: #'CogMethod *'. > >>> methodHeader := cogMethod methodHeader. > >>> > >>> I guess methodHeader's double assignment above is related to the > >>> machine code frame having two addresses as Clement described... > >> > >> > >> Errr... I don't really fancy the way you say it but I think yes that's > it. > >> > >> A method can have 2 addresses, the address of the bytecoded version in > the heap and the address of its jitted version in the machine code zone. In > the machine code frame printing, the simulator displays the 2 addresses. > But the frame has a single pointer to the method. > >> > >> So what you're looking at is the dispatch logic from the bytecoded > method to the jitted method. When the JIT compiles a bytecoded method to > machine code, it replaces the bytecoded method compiled method header > (first literal) by a pointer to the jitted version. The machine code > version of the method keeps the compiled method header, so accessing it is > different in methods compiled to machine code and methods not compiled to > machine code. > >> > >> #rawHeaderOf: answers the first literal of the bytecoded method which > is a pointer to the jitted version of the method if the method has a jitted > version, else is the compiled method header. In the code you show, the VM > ensures the method has a jitted version with the assertion, hence the > compiled method header is fetched from the jitted version. > > I think I've got it. So upon JITing, CompiledMethod and its literals > and bytecodes don't move. > Only its bytecodeHeader is manipulated and re-purposed. > > Before JIT... > compiledMethod := { bytecodeHeader, literals, bytecodes }. > byteCodeHeader := compiledMethod at: 1 > > After JIT something like... > cogMethod := { cogMethodHeader, bytecodeHeader, machineCode } > compiledMethod := { pointerTo_cogMethod, literals, bytecodes }. > rawHeader := compiledMethod at: 1 > cogMethodHeader := dereferenced(rawHeader) at: 1. > Right. When a method is cogged (jitter) its header is set to point to the Cog method (machine code method), and the actual header is stashed inside the Cog method. This is invisible to the image because only the objectAt: primitive accesses CompiledMethod literals and this primitive checks. In the VM all points where methodHeader is accessed must check for a normal method (header is a SmallInteger) and a cogged method (header is not a SmallInteger). > > > >> > >>> > >>> >> On Mon, May 30, 2016 at 4:12 PM, Cl?ment Bera < > bera.clement@gmail.com> wrote: > >>> >>> Now that you've print the frame, you can see the method addresses > in this line: > >>> >>> 16r103144: method: 16r51578 16r102BDD0 16r102BDD0: a(n) > CompiledMethod. > >>> >>> This is a machine code frame, so the method has two addresses: > >>> >>> 16r51578 => in generated method, so you need to use > [disassembleMethod/trampoline...] and write down the hex to see the > disassembly. > >>> >>> 16r102BDD0 => in the heap. This is the bytecode version of the > method. You can print it using [print oop...] > >>> > >>> This time... > >>> [print ext head frame] ==> > >>> 16r101214 M BlockClosure>forkAt: 16r2FC420: a(n) BlockClosure > >>> 16r101210: method: 16rBBF0 16rC4E948 16rC4E948: a(n) > CompiledMethod > >>> > >>> self rawHeaderOf: newMethod ==> 16rBBF0 > >>> So the "raw header" is the cogged method. > >>> > >>> Looking at the output below, the space ship operator <-> seems to link > >>> between cogged method headers like a call stack, except #forkAt: > >>> calls #newProcess which calls #asContext > >>> > >>> [print cog method for...] 16rBBF0 ==> > >>> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: > >>> > >>> [print cog method for...] 16rBC80 ==> > >>> 16rBC80 <-> 16rBEA8: method: 16rC51970 prim 19 selector: 16r6D1620 > newProcess > >>> > >>> [print cog method for...] 16rBEA8 ==> > >>> 16rBEA8 <-> 16rBF28: method: 16rC518C0 selector: 16r76A600 > asContext > >>> > >>> However the links don't seem to go back up the call stack but forward, > >>> to statements to be executed in the future. So I am confused? > >> > >> > >> Yeah it's the jitted version of the method header address, then <->, > then the jitted method entry point address, the bytecode version address, > selector address. > >> > >> The cogMethod header is used to store the bytecoded compiled method > header (because it was replaced with a pointer to the cogMethod) and > various flags. > >> > >>> > >>> > >>> ------------- > >>> > >>> Considering further [print cog method for...] 16rBBF0 ==> > >>> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: > >>> > >>> [print oop...] 16r6CC798 ==> > >>> a(n) ByteSymbol nbytes 7 forkAt: > >>> > >>> Clement early advised is the bytecode version of the method is this... > >>> [print oop...] 16rC4E948 ==> > >>> 16rC4E948: a(n) CompiledMethod nbytes 37 > >>> 16rBBF0 is in generated methods > >>> 16r6D1620 #newProcess 16r6CC650 #priority: 16r6CC690 #resume > >>> 16r6CC798 #forkAt: 16rAE5490 a ClassBinding #BlockClosure -> > 16r0088D618 > >>> 16rC4E968: 70/112 D0/208 88/136 10/16 E1/225 87/135 D2/210 7C/124 > >>> 16rC4E970: 28/40 AF/175 BA/186 F3/243 20/32 > >>> > >>> Now I've been a bit slow on the uptake and only just realised, but to > confirm... > >>> the line 16r6CC798 is the one specifying the method as > BlockClosure>>forkAt: > >> > >> 16r6CC798 is the address of the selector #forkAt: > > Sorry I wasn't clear. I wasn't referring to the address itself of the > selector - that was just a line reference. My insight I wanted to > confirm was that the last oop before the bytecode was... > a ClassBinding #BlockClosure -> 16r0088D618 > and the next last before that was... > #forkAt: 16rAE5490 > indicating the output of [print oop...] was method BlockClosure>>forkAt: , > while above that line are the methods called by #forkAt: and below it > is the bytecode. > > Ahhh, actually I just saw this relevant comment in CompiledMethod... > "The last literal in a CompiledMethod must be its > methodClassAssociation, a binding whose value is the class the method > is installed in. The methodClassAssociation is used to implement > super sends. If a method contains no super send then its > methodClassAssociation may be nil (as would be the case for example of > methods providing a pool of inst var accessors). By convention the > penultimate literal of a method is either its selector or an instance > of AdditionalMethodState. " > > So it seems it won't always show the Class>>method, but often will. > > > >> > >>> > >>> For the last two lines, I notice the numbers before the slash (70, 88, > >>> 10...) are the method bytecode, but what are the numbers after the > >>> slash? > >> > >> > >> The bytecode in decimal instead of hexa I think. > > I checked. You are right. Obvious in hindsight. > Note that you can use the image[level byte code printing machinery on a method in the simulator by using Stackinterpreter>>symbolicMethod:. The text is output in the simulator window's transcript or the system transcript. See "toggle transcript" towards the top of the bottom right hand simulator window's menu. > >>> ---------------- > >>> > >>> In #activeCoggedNewMethod: the second assignment to methodHeader > >>> ==> 16r208000B > >>> > >>> which matches the mthhdr field of the raw header > >>> [print cog method header for...] 16rBBF0 ==> > >>> BBF0 > >>> objhdr: 8000000A000035 > >>> nArgs: 1 type: 2 > >>> blksiz: 90 > >>> method: C4E948 > >>> mthhdr: 208000B > >>> selctr: 6CC798=#forkAt: > >>> blkentry: 0 > >>> stackCheckOffset: 5E/BC4E > >>> cmRefersToYoung: no cmIsFullBlock: no > >>> > >>> What is "type: 2" ? > >> > >> > >> Haha. > >> > >> Well when you iterate over the machine code zone you need to know what > the current element you iterate on is. In the machine code zone there can > be: > >> - cog method > >> - closed PICS > >> - open PICS > >> - free space > >> And now we're adding cog full block method but it's sharing the index > with cog method and have a separated flag :-) > >> > >> The type tells you what it is. Look at the Literal variables CMFree, > CMClosedPIC, CMOpenPIC, etc . > >> > >> 2 is CMMethod with is a constant. You can improve the printing there > and commit the changes if you feel so. > > > > > > What did I write here I don't understand myself ? I mean CMMethod = 2, > so type = 2 means the struct you're looking at in the machine code zone is > a method and not free space or a PIC. > >> > >> > >> Ok I have to go I will look at the rest of your mail later. > > > > > > Let's do this... > >> > >> > >>> > >>> > >>> -------------------------- > >>> > >>> Stepping through to Cogit>>ceEnterCogCodePopReceiverReg > >>> I notice its protocol is "simulation only" > >>> and it calls "simulateEnilopmart:numArgs: > ceEnterCogCodePopReceiverReg" > >>> but I don't see any other implementors of > #ceEnterCogCodePopReceiverReg. > >>> Also there is a pragma . > >>> > >>> Obviously the real non-simulated VM works differently, but I can't > >>> determine how. > >>> > >>> btw, I have noticed that ceEnterCogCodePopReceiverReg > >>> ==> 16r10B8 > >>> and [print cog method for...] 16r10B8 > >>> ==> trampoline ceEnterCogCodePopReceiverReg > >>> > >>> Is ceEnterCogCodePopReceiverReg provided by the platform C code? > > > > > > Well it's in cogitIA32.c. I don't remember where it comes from. > > Cool. I had a peek. > > > > > Basically in Cog you have specific machine code routines, called > trampolines, that switch from machine code to C code. When trampoline is > written backward (Enilopmart) it means that the routine is meant to switch > from C code to machine code. > > > > The real VM calls in ceEnterCogCodePopReceiverReg a machine code routine > that does the right thing (register remapped, maybe fp and sp saved, etc) > to switch from the C runtime from the C compiler to the machine code > runtime executing code generated by the JIT. > > I see its a function pointer... > void (*ceEnterCogCodePopReceiverReg)(void) > > set by... > ceEnterCogCodePopReceiverReg = > genEnilopmartForandandforCallcalled(ReceiverResultReg, NoReg, NoReg, > 0, "ceEnterCogCodePopReceiverReg"); > > which is beyond my current level need-to-know. Still useful to fill > in the background architecture. This comment comparing > trampoline/enilopmart to system-call-like transition was > enlightening... > > /* An enilopmart (the reverse of a trampoline) is a piece of code > that makes > the system-call-like transition from the C runtime into > generated machine > code. The desired arguments and entry-point are pushed on a > stackPage's > stack. The enilopmart pops off the values to be loaded into > registers and > then executes a return instruction to pop off the entry-point > and jump to > it. > BEFORE AFTER > (stacks grow down) > whatever stackPointer -> whatever > target address => reg1 = reg1val, etc > reg1val pc = target address > reg2val > stackPointer -> reg3val */ > > /* Cogit>>#genEnilopmartFor:and:and:forCall:called: */ > > Right. Trampolines are the machine code routines that call into the Smalltalk (simulator) / C (real VM) run-time support routines. They make a stack switch from the Smalltalk/Cog-machine-code stack to the actual C stack, and pass parameters. Enilopmarts do the reverse. They switch from the actual C stack back into the Smalltalk/Cog-machine-code stack, possibly popping values pushed onto that stack into specific registers, and then executing a return instruction to jump to some machine code address in the machine code zone to start or resume machine-code execution. > > > In simulation, the C code is simulated by executing Slang as Smalltalk > code and the machine code is simulated using the processor simulator (Bochs > for IA32). So it has to be done differently as there is no C stack with > register state and stuff. Both trampolines and enilmoparts are simulated > with specific code. > > > > >>> > >>> > >>> --------------------------- > >>> Stepping through to simulateCogCodeAt: > >>> it called processor singleStepIn:minimumAddress:readOnlyBelow: > >>> which called > BochsIA32Alien>>primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: > >>> >>> module: 'BochsIA32Plugin' > >>> error: ec> > >>> ^ec == #'inappropriate operation' > >>> ifTrue: [self handleExecutionPrimitiveFailureIn: memoryArray > >>> minimumAddress: minimumAddress] > >>> ifFalse: [self reportPrimitiveFailure] > >>> > >>> and the debugger cursor was inside the ifTrue: statement. I found I > >>> didn't have bochs installed, but after installing bochs-2.6-2, I go > >>> the same result. So could I get some background around this.. > >>> > >>> Also I'm curious how the simulator seemed to be running a CogVM before > >>> bochs was installed. Perhaps since I was not debugging through it, the > >>> machine code ran for real rather than being simulated. > >>> > > > > No the machine code is always simulated. Bochs was working for sure if > you successfully simulated the image on top of the cog simulator until the > display was shown. > > > > If you have a VM from one of Eliot's build (from the Cog blog) the > processor simulators are present as plugins by default. On Mac you can do > [show package contents...] and then look at the file inside to check the > Bochs Plugin is there. It's not the case on the Pharo VMs so don't use them > for CogVM simulation. You don't need to install anything. > > Ahhh... I see them now. > ./lib/squeak/5.0-3692/BochsX64Plugin > ./lib/squeak/5.0-3692/BochsIA32Plugin > > The clears my misconception - a lack of understanding the purpose of > the primitive failure and a red herring when I saw the Boch's system > package wasn't installed. > > > > > On normal simulation the simulator goes often in the branch you've just > shown. It means it reached a simulation trap. As for enilmopart that can't > be properly simulated, trampolines can't be simulated. So to simulate a > trampoline the processor simulator fails a call and the trampoline is done > in the simulation code. Look at #handleCallOrJumpSimulationTrap: for > example. > Not quite. The trampolines are simulated. The calls the trampolines make can't be simulated. These calls are to illegal addresses and cause traps. The trap handler maps the addresses into the appropriate Smalltalk blocks/methods and invokes them. The same goes for accessing variables in the simulator such as framePointer, stackPointer, instructionPointer etc. These are Smalltalk objects that are instanced variables of the CoInterpreter. They are mapped to illegal addresses in machine code and attempts to access them cause traps and the trap handler maps these to fetch/store the relevant inst var. In the real VM the actual addresses of the variables are used directly. > Ah, so its an 'inappropriate operation' from Bochs' perspective, but > from the Simulator's perspective the primitiveFail is a useful > condition like the #ensure: "Primitive 198 always fails. The VM uses > prim 198 in a context's method as the mark for an ensure:/ifCurtailed: > activation." ? > Right. Andreas realised specific primitives that did nothing could be used to mark methods for the VM's benefit, without needing a bit in the method header. Very clever, very economical. A nice idea. > cheers -ben > > btw, I bumped into a bit of history... > http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/ > :-) -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160612/dc2d7a3a/attachment-0001.htm From bera.clement at gmail.com Sun Jun 12 18:16:05 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Sun Jun 12 18:16:27 2016 Subject: [Vm-dev] Exploring the simulator (was Re: REPL image for simulation) In-Reply-To: References: Message-ID: On Sun, Jun 12, 2016 at 7:36 PM, Ben Coman wrote: > > On Sun, Jun 12, 2016 at 10:59 PM, Cl?ment Bera > wrote: > > > > Hi again, > > > > On Sun, Jun 12, 2016 at 10:44 AM, Cl?ment Bera > wrote: > >> > >> Hi Ben, > >> > >> I'm glad you're now looking into the JIT. If you have some blog or > something, please write an experience report about you looking into the > simulator. It's helpful for us to have noise around the VM. > > Cool. I'll have a go. > > >> > >> On Sun, Jun 12, 2016 at 8:35 AM, Ben Coman wrote: > >>> > >>> > >>> I am stepping for the first time through the CogVM, having [set break > >>> selector...] forkAt: > >>> After stepping in a few times I get to #activateCoggedNewMethod. > >>> CogVMSimulatorLSB(CoInterpreter)>>dispatchOn:in: > >>> CogVMSimulatorLSB(CoInterpreter)>>sendLiteralSelector1ArgBytecode > >>> CogVMSimulatorLSB(CoInterpreter)>>commonSendOrdinary > >>> CogVMSimulatorLSB(CoInterpreter)>>insternalExecuteNewMethod > >>> CogVMSimulatorLSB(CoInterpreter)>>activateCoggedNewMethod > >>> > >>> Here from the code at the top. > >>> methodHeader := self rawHeaderOf: newMethod. > >>> self assert: (self isCogMethodReference: methodHeader). > >>> cogMethod := self cCoerceSimple: methodHeader to: #'CogMethod *'. > >>> methodHeader := cogMethod methodHeader. > >>> > >>> I guess methodHeader's double assignment above is related to the > >>> machine code frame having two addresses as Clement described... > >> > >> > >> Errr... I don't really fancy the way you say it but I think yes that's > it. > >> > >> A method can have 2 addresses, the address of the bytecoded version in > the heap and the address of its jitted version in the machine code zone. In > the machine code frame printing, the simulator displays the 2 addresses. > But the frame has a single pointer to the method. > >> > >> So what you're looking at is the dispatch logic from the bytecoded > method to the jitted method. When the JIT compiles a bytecoded method to > machine code, it replaces the bytecoded method compiled method header > (first literal) by a pointer to the jitted version. The machine code > version of the method keeps the compiled method header, so accessing it is > different in methods compiled to machine code and methods not compiled to > machine code. > >> > >> #rawHeaderOf: answers the first literal of the bytecoded method which > is a pointer to the jitted version of the method if the method has a jitted > version, else is the compiled method header. In the code you show, the VM > ensures the method has a jitted version with the assertion, hence the > compiled method header is fetched from the jitted version. > > I think I've got it. So upon JITing, CompiledMethod and its literals > and bytecodes don't move. > Only its bytecodeHeader is manipulated and re-purposed. > > Before JIT... > compiledMethod := { bytecodeHeader, literals, bytecodes }. > byteCodeHeader := compiledMethod at: 1 > > After JIT something like... > cogMethod := { cogMethodHeader, bytecodeHeader, machineCode } > compiledMethod := { pointerTo_cogMethod, literals, bytecodes }. > rawHeader := compiledMethod at: 1 > cogMethodHeader := dereferenced(rawHeader) at: 1. > > > I guess we could say that. A compiled method is more like, before JIT: object's header (64 bits) compiled method header (1 word) literals (several words) bytecodes (several bytes) compiled method trailer (several bytes) After jitting, the compiled method header is replaced by a pointer to the cog method. The cog method has (assuming it has no blocks): - header - native instructions - map and the cog method header includes the compiled method header. > >> > >>> > >>> >> On Mon, May 30, 2016 at 4:12 PM, Cl?ment Bera < > bera.clement@gmail.com> wrote: > >>> >>> Now that you've print the frame, you can see the method addresses > in this line: > >>> >>> 16r103144: method: 16r51578 16r102BDD0 16r102BDD0: a(n) > CompiledMethod. > >>> >>> This is a machine code frame, so the method has two addresses: > >>> >>> 16r51578 => in generated method, so you need to use > [disassembleMethod/trampoline...] and write down the hex to see the > disassembly. > >>> >>> 16r102BDD0 => in the heap. This is the bytecode version of the > method. You can print it using [print oop...] > >>> > >>> This time... > >>> [print ext head frame] ==> > >>> 16r101214 M BlockClosure>forkAt: 16r2FC420: a(n) BlockClosure > >>> 16r101210: method: 16rBBF0 16rC4E948 16rC4E948: a(n) > CompiledMethod > >>> > >>> self rawHeaderOf: newMethod ==> 16rBBF0 > >>> So the "raw header" is the cogged method. > >>> > >>> Looking at the output below, the space ship operator <-> seems to link > >>> between cogged method headers like a call stack, except #forkAt: > >>> calls #newProcess which calls #asContext > >>> > >>> [print cog method for...] 16rBBF0 ==> > >>> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: > >>> > >>> [print cog method for...] 16rBC80 ==> > >>> 16rBC80 <-> 16rBEA8: method: 16rC51970 prim 19 selector: 16r6D1620 > newProcess > >>> > >>> [print cog method for...] 16rBEA8 ==> > >>> 16rBEA8 <-> 16rBF28: method: 16rC518C0 selector: 16r76A600 > asContext > >>> > >>> However the links don't seem to go back up the call stack but forward, > >>> to statements to be executed in the future. So I am confused? > >> > >> > >> Yeah it's the jitted version of the method header address, then <->, > then the jitted method entry point address, the bytecode version address, > selector address. > >> > >> The cogMethod header is used to store the bytecoded compiled method > header (because it was replaced with a pointer to the cogMethod) and > various flags. > >> > >>> > >>> > >>> ------------- > >>> > >>> Considering further [print cog method for...] 16rBBF0 ==> > >>> 16rBBF0 <-> 16rBC80: method: 16rC4E948 selector: 16r6CC798 forkAt: > >>> > >>> [print oop...] 16r6CC798 ==> > >>> a(n) ByteSymbol nbytes 7 forkAt: > >>> > >>> Clement early advised is the bytecode version of the method is this... > >>> [print oop...] 16rC4E948 ==> > >>> 16rC4E948: a(n) CompiledMethod nbytes 37 > >>> 16rBBF0 is in generated methods > >>> 16r6D1620 #newProcess 16r6CC650 #priority: 16r6CC690 #resume > >>> 16r6CC798 #forkAt: 16rAE5490 a ClassBinding #BlockClosure -> > 16r0088D618 > >>> 16rC4E968: 70/112 D0/208 88/136 10/16 E1/225 87/135 D2/210 7C/124 > >>> 16rC4E970: 28/40 AF/175 BA/186 F3/243 20/32 > >>> > >>> Now I've been a bit slow on the uptake and only just realised, but to > confirm... > >>> the line 16r6CC798 is the one specifying the method as > BlockClosure>>forkAt: > >> > >> 16r6CC798 is the address of the selector #forkAt: > > Sorry I wasn't clear. I wasn't referring to the address itself of the > selector - that was just a line reference. My insight I wanted to > confirm was that the last oop before the bytecode was... > a ClassBinding #BlockClosure -> 16r0088D618 > and the next last before that was... > #forkAt: 16rAE5490 > indicating the output of [print oop...] was method BlockClosure>>forkAt: , > while above that line are the methods called by #forkAt: and below it > is the bytecode. > > Ahhh, actually I just saw this relevant comment in CompiledMethod... > "The last literal in a CompiledMethod must be its > methodClassAssociation, a binding whose value is the class the method > is installed in. The methodClassAssociation is used to implement > super sends. If a method contains no super send then its > methodClassAssociation may be nil (as would be the case for example of > methods providing a pool of inst var accessors). By convention the > penultimate literal of a method is either its selector or an instance > of AdditionalMethodState. " > > So it seems it won't always show the Class>>method, but often will. > Well... By convention the bytecode compiler always put the class binding as the last literal except if there is not enough room in the literal frame, which in practice happens on average 1 methods out of 100.000 in my experience, and which will never happen once we've switched to the new bytecode set... But if the method has no super sends, it does not need the class as the last literal, and one could compile an image like that to save some memory. If one removes both the selector (last but one literal) and the class binding, one could save 150kb in the base Pharo image out of ~47Mb. Currently there is no setting to do that, but one could do it. > > >> > >>> > >>> For the last two lines, I notice the numbers before the slash (70, 88, > >>> 10...) are the method bytecode, but what are the numbers after the > >>> slash? > >> > >> > >> The bytecode in decimal instead of hexa I think. > > I checked. You are right. Obvious in hindsight. > > >>> ---------------- > >>> > >>> In #activeCoggedNewMethod: the second assignment to methodHeader > >>> ==> 16r208000B > >>> > >>> which matches the mthhdr field of the raw header > >>> [print cog method header for...] 16rBBF0 ==> > >>> BBF0 > >>> objhdr: 8000000A000035 > >>> nArgs: 1 type: 2 > >>> blksiz: 90 > >>> method: C4E948 > >>> mthhdr: 208000B > >>> selctr: 6CC798=#forkAt: > >>> blkentry: 0 > >>> stackCheckOffset: 5E/BC4E > >>> cmRefersToYoung: no cmIsFullBlock: no > >>> > >>> What is "type: 2" ? > >> > >> > >> Haha. > >> > >> Well when you iterate over the machine code zone you need to know what > the current element you iterate on is. In the machine code zone there can > be: > >> - cog method > >> - closed PICS > >> - open PICS > >> - free space > >> And now we're adding cog full block method but it's sharing the index > with cog method and have a separated flag :-) > >> > >> The type tells you what it is. Look at the Literal variables CMFree, > CMClosedPIC, CMOpenPIC, etc . > >> > >> 2 is CMMethod with is a constant. You can improve the printing there > and commit the changes if you feel so. > > > > > > What did I write here I don't understand myself ? I mean CMMethod = 2, > so type = 2 means the struct you're looking at in the machine code zone is > a method and not free space or a PIC. > >> > >> > >> Ok I have to go I will look at the rest of your mail later. > > > > > > Let's do this... > >> > >> > >>> > >>> > >>> -------------------------- > >>> > >>> Stepping through to Cogit>>ceEnterCogCodePopReceiverReg > >>> I notice its protocol is "simulation only" > >>> and it calls "simulateEnilopmart:numArgs: > ceEnterCogCodePopReceiverReg" > >>> but I don't see any other implementors of > #ceEnterCogCodePopReceiverReg. > >>> Also there is a pragma . > >>> > >>> Obviously the real non-simulated VM works differently, but I can't > >>> determine how. > >>> > >>> btw, I have noticed that ceEnterCogCodePopReceiverReg > >>> ==> 16r10B8 > >>> and [print cog method for...] 16r10B8 > >>> ==> trampoline ceEnterCogCodePopReceiverReg > >>> > >>> Is ceEnterCogCodePopReceiverReg provided by the platform C code? > > > > > > Well it's in cogitIA32.c. I don't remember where it comes from. > > Cool. I had a peek. > > > > > Basically in Cog you have specific machine code routines, called > trampolines, that switch from machine code to C code. When trampoline is > written backward (Enilopmart) it means that the routine is meant to switch > from C code to machine code. > > > > The real VM calls in ceEnterCogCodePopReceiverReg a machine code routine > that does the right thing (register remapped, maybe fp and sp saved, etc) > to switch from the C runtime from the C compiler to the machine code > runtime executing code generated by the JIT. > > I see its a function pointer... > void (*ceEnterCogCodePopReceiverReg)(void) > > set by... > ceEnterCogCodePopReceiverReg = > genEnilopmartForandandforCallcalled(ReceiverResultReg, NoReg, NoReg, > 0, "ceEnterCogCodePopReceiverReg"); > > which is beyond my current level need-to-know. Still useful to fill > in the background architecture. This comment comparing > trampoline/enilopmart to system-call-like transition was > enlightening... > > /* An enilopmart (the reverse of a trampoline) is a piece of code > that makes > the system-call-like transition from the C runtime into > generated machine > code. The desired arguments and entry-point are pushed on a > stackPage's > stack. The enilopmart pops off the values to be loaded into > registers and > then executes a return instruction to pop off the entry-point > and jump to > it. > BEFORE AFTER > (stacks grow down) > whatever stackPointer -> whatever > target address => reg1 = reg1val, etc > reg1val pc = target address > reg2val > stackPointer -> reg3val */ > > /* Cogit>>#genEnilopmartFor:and:and:forCall:called: */ > > > > > In simulation, the C code is simulated by executing Slang as Smalltalk > code and the machine code is simulated using the processor simulator (Bochs > for IA32). So it has to be done differently as there is no C stack with > register state and stuff. Both trampolines and enilmoparts are simulated > with specific code. > > > > >>> > >>> > >>> --------------------------- > >>> Stepping through to simulateCogCodeAt: > >>> it called processor singleStepIn:minimumAddress:readOnlyBelow: > >>> which called > BochsIA32Alien>>primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: > >>> >>> module: 'BochsIA32Plugin' > >>> error: ec> > >>> ^ec == #'inappropriate operation' > >>> ifTrue: [self handleExecutionPrimitiveFailureIn: memoryArray > >>> minimumAddress: minimumAddress] > >>> ifFalse: [self reportPrimitiveFailure] > >>> > >>> and the debugger cursor was inside the ifTrue: statement. I found I > >>> didn't have bochs installed, but after installing bochs-2.6-2, I go > >>> the same result. So could I get some background around this.. > >>> > >>> Also I'm curious how the simulator seemed to be running a CogVM before > >>> bochs was installed. Perhaps since I was not debugging through it, the > >>> machine code ran for real rather than being simulated. > >>> > > > > No the machine code is always simulated. Bochs was working for sure if > you successfully simulated the image on top of the cog simulator until the > display was shown. > > > > If you have a VM from one of Eliot's build (from the Cog blog) the > processor simulators are present as plugins by default. On Mac you can do > [show package contents...] and then look at the file inside to check the > Bochs Plugin is there. It's not the case on the Pharo VMs so don't use them > for CogVM simulation. You don't need to install anything. > > Ahhh... I see them now. > ./lib/squeak/5.0-3692/BochsX64Plugin > ./lib/squeak/5.0-3692/BochsIA32Plugin > > The clears my misconception - a lack of understanding the purpose of > the primitive failure and a red herring when I saw the Boch's system > package wasn't installed. > > > > > On normal simulation the simulator goes often in the branch you've just > shown. It means it reached a simulation trap. As for enilmopart that can't > be properly simulated, trampolines can't be simulated. So to simulate a > trampoline the processor simulator fails a call and the trampoline is done > in the simulation code. Look at #handleCallOrJumpSimulationTrap: for > example. > > Ah, so its an 'inappropriate operation' from Bochs' perspective, but > from the Simulator's perspective the primitiveFail is a useful > condition like the #ensure: "Primitive 198 always fails. The VM uses > prim 198 in a context's method as the mark for an ensure:/ifCurtailed: > activation." ? > Err... I think it's a bit different. The processor simulator keeps running machine code until it traps, in which case the simulation figures out why it traps, and likely it trapped because it needed to switch from machine code to C code hence to the Smalltalk runtime in simulation. The normal behavior is that most of the time processor simulator primitives succeed, sometimes they fail. Primitive 198 and 199 always fail. If you want to try you can alternatively use the MIPS back-end to simulate machine code which is done fully in Smalltalk instead of Bochs. The back-ends for x86, x64 and ARM are simulated using external processor simulator frameworks, while the MIPS simulator is written entirely in Smalltalk. The settings to use MIPS is (ISA MIPSEL). Don't hesitate to use other back-ends, it's fun, (IA32 X64 ARMv5 MIPSEL) settings. > cheers -ben > > btw, I bumped into a bit of history... > http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/ Yeah this is a good post. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160612/30b28921/attachment-0001.htm From lists at fniephaus.com Sun Jun 12 19:59:10 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Sun Jun 12 19:59:22 2016 Subject: [Vm-dev] Re: Errors in AQMEIO.cpp/AudioQueueObject.cpp on OS X 10.9.5 In-Reply-To: References: Message-ID: Bumping this up. Any pointers would be helpful... -- On Tue, Jun 7, 2016 at 10:42 PM Fabio Niephaus wrote: > Hi all, > > There seems to be a problem with the SoundPlugin when starting a recent > vm on OS X > 10.9.5 (see [1] and [2]). Is it possible that this it is related to [3]? > > [0K2016-06-07 19:34:13.465 Pharo[531:507] 19:34:13.464 ERROR: [0xa116d1a8] AQMEIO.cpp:377: _FindIOUnit: error -66680 > 2016-06-07 19:34:13.467 Pharo[531:507] 19:34:13.467 ERROR: [0xa116d1a8] >aq> AudioQueueObject.cpp:1590: Prime: failed (-66680); will stop (5512/0 frames) > 2016-06-07 19:34:13.469 Pharo[531:507] 19:34:13.469 ERROR: [0xa116d1a8] AQMEIO.cpp:377: _FindIOUnit: error -66680 > 2016-06-07 19:34:13.471 Pharo[531:507] 19:34:13.470 ERROR: [0xa116d1a8] >aq> AudioQueueObject.cpp:1590: Prime: failed (-66680); will stop (33075/0 frames) > > > Best, > Fabio > > [1] https://github.com/hpi-swa/smalltalkCI/issues/151 > [2] https://travis-ci.org/Uko/QualityAssistant/jobs/135961674#L70 > [3] > http://stackoverflow.com/questions/31342042/avaudiorecorder-doesnt-record-on-os-x-mavericks/31447794 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160612/c26a1aae/attachment.htm From btc at openinworld.com Mon Jun 13 13:24:40 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 13 13:25:05 2016 Subject: [Vm-dev] CogVM Execution Flow Message-ID: In trying to understand the flow of execution (and in particular the jumps in the jitted VM, I made a first rough pass to map it in the attached chart. I am trying to colourize it to distinguish between paths that can return to the interpreter, those that circulate in jitted code, and the transitions. I'm sure I've missed the mark a bit but its a start. Of course corrections welcome, even scanned pen sketches. cheer -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: CogVM-Execution-Flow (2016.06.13c).png Type: image/png Size: 139885 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160613/e6754a4b/CogVM-Execution-Flow2016.06.13c-0001.png From btc at openinworld.com Mon Jun 13 13:25:29 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 13 13:25:53 2016 Subject: [Vm-dev] Re: CogVM Execution Flow In-Reply-To: References: Message-ID: On Mon, Jun 13, 2016 at 9:24 PM, Ben Coman wrote: > In trying to understand the flow of execution (and in particular the > jumps in the jitted VM, I made a first rough pass to map it in the > attached chart. > > I am trying to colourize it to distinguish between paths that can > return to the interpreter, those that circulate in jitted code, and > the transitions. I'm sure I've missed the mark a bit but its a start. > Of course corrections welcome, even scanned pen sketches. If anyone wants to open the original, I used yEd - downloaded and first used it today. I found it quite good for the task after trying Freemind and Inkscape. Quick Tips: Drag background in right-click. Left-drag a from a node starts a connector. To move a node you need to first select it so the mouse pointer changes to a hand. http://www.yworks.com/products/yed cheers -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: CogVM-Execution-Flow (2016.06.13c).graphml Type: application/octet-stream Size: 96930 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160613/f554321c/CogVM-Execution-Flow2016.06.13c-0001.obj From btc at openinworld.com Mon Jun 13 16:03:55 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 13 16:04:21 2016 Subject: [Vm-dev] Re: CogVM Execution Flow In-Reply-To: References: Message-ID: On Mon, Jun 13, 2016 at 9:25 PM, Ben Coman wrote: > On Mon, Jun 13, 2016 at 9:24 PM, Ben Coman wrote: >> In trying to understand the flow of execution (and in particular the >> jumps in the jitted VM, I made a first rough pass to map it in the >> attached chart. >> >> I am trying to colourize it to distinguish between paths that can >> return to the interpreter, those that circulate in jitted code, and >> the transitions. I'm sure I've missed the mark a bit but its a start. >> Of course corrections welcome, even scanned pen sketches. > > If anyone wants to open the original, I used yEd - downloaded and > first used it today. I found it quite good for the task after trying > Freemind and Inkscape. > Quick Tips: Drag background in right-click. Left-drag a from a node > starts a connector. To move a node you need to first select it so the > mouse pointer changes to a hand. > http://www.yworks.com/products/yed A few updates... I'm not sure how big a file the mail list handles. The PNG is 350k. So I just post the graphml for now. cheers -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: CogVM-Execution-Flow (2016.06.13d).zip Type: application/zip Size: 11069 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/32d10865/CogVM-Execution-Flow2016.06.13d.zip From eliot.miranda at gmail.com Mon Jun 13 16:36:38 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 13 16:36:44 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: <691E8DF5-C3F7-404A-989B-FBF4EFC689E4@gmail.com> Ben, this looks fabulous. I've just skimmed on my phone and will look in more depth later but this is an extremely valuable and illuminating approach, visualizing something I have in my head but that is difficult to describe. Thanks for doing this!! One thing I would love for you to do (and I can help) is to create two diagrams, one for the simulator and one for the real VM, and relate the two, for example by colour-coding the common activities, and hence identifying simulator-only "distractions". _,,,^..^,,,_ (phone) > On Jun 13, 2016, at 6:24 AM, Ben Coman wrote: > > In trying to understand the flow of execution (and in particular the > jumps in the jitted VM, I made a first rough pass to map it in the > attached chart. > > I am trying to colourize it to distinguish between paths that can > return to the interpreter, those that circulate in jitted code, and > the transitions. I'm sure I've missed the mark a bit but its a start. > Of course corrections welcome, even scanned pen sketches. > > cheer -ben > From tim at rowledge.org Mon Jun 13 16:59:07 2016 From: tim at rowledge.org (tim Rowledge) Date: Mon Jun 13 16:58:58 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: > On 13-06-2016, at 6:24 AM, Ben Coman wrote: > > In trying to understand the flow of execution (and in particular the > jumps in the jitted VM, I made a first rough pass to map it in the > attached chart. To paraphrase that great philosopher Billious O?Liarly, ?code goes in, code goes out - you can?t explain that!" tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- "Body by Fisher -- brains by Mattel." From timfelgentreff at gmail.com Mon Jun 13 18:00:01 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Mon Jun 13 18:00:04 2016 Subject: [Vm-dev] Migration to github status? In-Reply-To: <806A15B1-7FF1-4C92-B96C-6DE6CCFACE04@gmail.com> References: <7D19D997-3EBD-4A60-A89C-0F548BB7A6D4@gmail.com> <806A15B1-7FF1-4C92-B96C-6DE6CCFACE04@gmail.com> Message-ID: Hi Esteban, Eliot is looking at the patch for moving to Github, if he thinks its alright, we can switch over pretty much immediately. cheers, Tim Am 10.06.2016 3:01 nachm. schrieb "Esteban Lorenzano" : > > Hi, > > Sorry for urging on this, but as I said, I need to start working in this? > Fabio just told me that he is ready for the migration and this mails from > Tim confirmes it? > Can we schedule the migration? > > Let?s say some day next week? (Thursday, as Fabio suggested)? > > Can we have a ?good to go?? > > thanks! > Esteban > > On 07 Jun 2016, at 20:13, Tim Felgentreff > wrote: > > Fabio and I have finished integrating the changes to move to Github with a > minimal patch against the current Cog branch. All scripts and build files > have been migrated and we are building VMs for Newspeak, Squeak, and Pharo > in the available flavor combinations (stack, cog, sista, spur, v3) on (what > we think are) the most important platforms (linux, mac, windows) and the > most used architectures (x86, x86_64, ARM). > > The patch ist currently on github.com/timfel/squeakvm and can be rebased > onto the current SVN easily. I have currently disabled uploading the build > artifacts. I was thinking maybe we could still use Eliot's webspace or else > Bintray, but whatever the community thinks works best. > > As soon as everyone is happy with it the patch, we need to find a time > when we switch the SVN to read-only and I rebase the patch one last time > and then we go live on OpenSmalltalk/vm > > Best, > Tim > Am 03.06.2016 15:25 schrieb "Esteban Lorenzano" : > >> >> Hi, >> >> Last week (with help of Clement) I put online the 64bits image generation >> for Pharo. >> Our CI now is producing regularly 64bits for both: >> >> - Pharo 5: >> https://ci.inria.fr/pharo/view/5.0/job/Pharo-5.0-Update-Step-3.1-64bits/ >> - Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.1-64bits >> >> Now? I would like to start testing it, and for that I need to build also >> PharoVM 64bits? I do not wan to reproduce all the work already done for >> running 64bits in current so I?m urging you to complete the migration, so >> I can start to merge my changes into the master, instead the opposite :) >> >> cheers, >> Esteban >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160613/30589d1b/attachment-0001.htm From btc at openinworld.com Mon Jun 13 18:21:36 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 13 18:21:59 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: <691E8DF5-C3F7-404A-989B-FBF4EFC689E4@gmail.com> References: <691E8DF5-C3F7-404A-989B-FBF4EFC689E4@gmail.com> Message-ID: On Tue, Jun 14, 2016 at 12:36 AM, Eliot Miranda wrote: > > Ben, > > this looks fabulous. I've just skimmed on my phone and will look in more depth later but this is an extremely valuable and illuminating approach, visualizing something I have in my head but that is difficult to describe. Thanks for doing this!! One thing I would love for you to do (and I can help) is to create two diagrams, one for the simulator and one for the real VM, and relate the two, for example by colour-coding the common activities, and hence identifying simulator-only "distractions". > > _,,,^..^,,,_ (phone) > >> On Jun 13, 2016, at 6:24 AM, Ben Coman wrote: >> >> In trying to understand the flow of execution (and in particular the >> jumps in the jitted VM, I made a first rough pass to map it in the >> attached chart. >> >> I am trying to colourize it to distinguish between paths that can >> return to the interpreter, those that circulate in jitted code, and >> the transitions. I'm sure I've missed the mark a bit but its a start. >> Of course corrections welcome, even scanned pen sketches. >> >> cheer -ben >> I consolidated a few boxes and aligned common tasks, particularly the returnToExecutive one. cheers -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: CogVM-Execution-Flow-2016.06.13f.zip Type: application/zip Size: 10787 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/546be089/CogVM-Execution-Flow-2016.06.13f.zip From eliot.miranda at gmail.com Mon Jun 13 18:41:31 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 13 18:41:35 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: Hi Ben, the diagram below shows the trees, but the wood is arguably more important. The diagram below is focussing on the transitions, but doesn't clearly show what is being transitioned between. I imagine a diagram which shows the structures and has what you have in the yellow boxes as transitions. So... The essential structures are six-fold, three execution state structures, and three bodies of code, and in fact there is overlap of one of each. These are the execution state structures: 1. the C stack. 2. the Smalltalk stack zone. 3. the Smalltalk heap (which includes contexts that overflow the Smalltalk stack zone). These are the bodies of code: 4. the run-time, the code comprising the VM interpreter, JIT, garbage collector, and primitives 5. the jitted code living in the machine code zone, comprising methods, polymorphic in line caches, and the glue routines (trampolines and enilopmarts) between that machine code and the run-time 6. Smalltalk "source" code, the classes and methods in the Smalltalk heap that constitute the "program" under execution So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack zone is a "cache", keeping the most recent activations in the most efficient form for execution. Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. (the jitted code) runs only on 2. (the stack zone), and also, code in 6. executed (interpreted) by the interpreter and primitives in 4. runs on 2. (the stack zone) Your diagram names some of the surface transitions, but not the deeper when and why. Here they are: a) execution begins on the C stack as the program is launched. Once the heap is loaded, swizzling pointers as required, the interpreter is entered. On first entry it a1) allocates space for the stack zone on the C stack a2) "marries" the context in the image that invoked the snapshot primitive (a stack frame in the stack zone is built for the context, and the context is changed to become a proxy for that stack frame). a3) captures the top of the C stack (CStackPointer & CFramePointer) as interpret is about to be invoked, including creating a "landing pad" for jumping back into the interpreter a3 vm) the landing pad is a jmpbuf created via setjmp, and jumped to via longjmp a3 sim) the landing pad is an exception handler for the ReenterInterpreter notification a4) calls interpret to start interpreting the method that executed the snapshot primitive Invoking the run-time: Machine code calls into the run-time for several facilities: adding an object to the remembered table if a store check indicates this must happen, running a primitive in the run-time, entering the run-time to lookup and bind a machine code send, or a linked send that has missed. To invoke the run-time, the machine code saves the native stack and frame pointers (those of the current Smalltalk stack frame) in stackPointer and framePointer, sets the native stack and frame pointers to CStackPointer and CFramePointer, passes parameters (pushing x86, loading registers ARM, x64) and calls the run-time routine. Simple routines (adding element to the remembered set) simply perform the operation and return. The code returned to then switches back to the Smalltalk stack pointers and continues. Routines that change the Smalltalk frame (send-linking routines, complex primitives such as perform:) reenter via an enilopmart. Transition to the interpreter: So any time the machine code wants to transition to the interpreter (not simply call a routine in the run-time, but to interpret an as-yet-unjitted/unjittable method, either via send or return, the machine code switches the frame and stack pointers to those captured in a3) and longjmps (raises the ReenterInterpreter exception). It does this by calling a run-time routine (as in "Invoking the run-time") that actually performs the longjmp. Any intervening state on the C stack will be discarded, and execution will be in the same state as when the interpret routine was entered immediately after initialising the stack zone. *N.B.* Note that if the interpreter merely called the machine-code, and the machine-code merely called the run-time, instead of substituting the stack and frame pointers with CStackPointer and CFramePointer set up on initial invocation of interpret, then the C stack would grow on each transition between machine code execution and interpreter/run-time execution and the C stack would soon overflow. Call-backs: The C stack /can/ grow however. If a call-out calls back then the call-back executes lower down the C stack. A call out will have been made from some primitive invoked either from the interpreter or machine-code, and that primitive will run on the C stack. On calling back, the VM saves the current CStackPointer, CFramePointer and "landing-pad" jmpbuf in state associated with the call-back, and then reenters the interpreter, saving new values for the CStackPointer, CFramePointer and "landing-pad" jmpbuf. Execution now continues in this new part of the C stack below the original. On the call-back returning (again via a primitive), the CStackPointer, CFramePointer and "landing-pad" jmpbuf are restored before returning to the C code that invoked the call-back. Once this C code returns, the stack is unwound back to the state before the call-out was invoked. Transition to machine-code: The interpreter uses the simple policy of jitting a method if it is found in the first-level method lookup cache, effectively hitting methods that are used more than once. If the jitter method contains a primitive, that primitive routine will be invoked just as if it were an interpreted method. If the method doesn't have a primitive, the interpreter will jump into machine code immediately. t jumps into machine code by pushing any parameters (the state of the machine code registers, such as ReceiverResultReg, and the machine code address to begin execution) onto the top of the Smalltalk stack, and calling an enilopmart that switches from the C to the Smalltalk stack, loads the registers and jumps to the machine code address via a return instruction that pops the entry point off the Smalltalk stack. Simulating these transitions in the Simulator: In the Simulator, the C run-time (4.) are Smalltalk objects, and 1., 2., 3., 5., & 6. live in the memory inst var of the object memory, a large ByteArray. The machine code lives in the bottom of this memory byte array (MBA), and has no direct access to the Smalltalk objects. In the real VM, the correlates of these objects all exist at specific addresses and may be accessed directly from machine code. In the simulator this is not possible. Instead, these objects are all assigned out-of-bounds addresses, and a dictionary maps from the specific out-of-bounds address to the specific object being accessed, e.g. stackPointer, an inst var of InterpreterPrimitives, the superclass of StackInterpreter, has an address in simulatedAddresses that maps to a block that does a perform to access stackPointer's value. See CoInterpreter>>stackPointerAddress. Machine code is executed by one of the processor aliens via the primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: primitives. These primitives will fail when they encounter an illegal instruction, including an instruction that tried to fetch or store or jump to an out-of-bounds address. The primitive failure code analyses the instruction that failed and (when appropriate, the instruction may actually be illegal, the result of some bug in the system, but is typically an intended access of some run-time object) creates an instance of the ProcessorSimulationTrap exception and raises it. The handler then handles the exception to either fetch, store or invoke Smalltalk objects in the simulation, and once handled execution can continue. Hence in the simulator primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: (actually their wrappers singleStepIn:minimumAddress:readOnlyBelow: & runInMemory:minimumAddress:readOnlyBelow: are always invoked in the context of Cogit>>simulateCogCodeAt:, which provides the handler, and tests for machine code break-points using the breakBlock. In the same way that the VM must avoid C stack growth when transitioning between machine code and the interpreter/run-time above, so the simulator must avoid uncontrolled stack growth when the simulated machine code invokes Smalltalk code which again invokes simulated machine code. So the code that invokes the run-time from simulateCogCodeAt: (Cogit>>#handleCallOrJumpSimulationTrap:) includes a handler for the ReenterMachineCode notification. Whenever the Smalltalk run-time wants to reenter machine code via an enilopmart it sends Cogit>>#simulateEnilopmart:numArgs: which raises the notification before sending Cogit>>simulateCogCodeAt:. So the first entry into machine code via an enilopmart starts Cogit>>simulateCogCodeAt:, but subsequent ones end up returning to that first Cogit>>simulateCogCodeAt: to continue execution. Ben, given the above, can you now see how your yellow boxes name specific transitions amongst the structures explained below? I hope I've encouraged you, not discouraged you, to revise and bifurcate your diagram into two state transition diagrams for the real and simulated VM. It would be great to have really good diagrammatic representations of the above. And once we have that, we can build the relatively simple extension that allows the interpreter and machine code to interleave interpreted and machine code frames on the Smalltalk stack (2.) that allow the VM to freely switch between interpreted and jitter code, and to fall back on the interpreter whenever convenient. On Mon, Jun 13, 2016 at 6:24 AM, Ben Coman wrote: > > In trying to understand the flow of execution (and in particular the > jumps in the jitted VM, I made a first rough pass to map it in the > attached chart. > > I am trying to colourize it to distinguish between paths that can > return to the interpreter, those that circulate in jitted code, and > the transitions. I'm sure I've missed the mark a bit but its a start. > Of course corrections welcome, even scanned pen sketches. > > cheer -ben > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160613/453759dd/attachment-0001.htm From btc at openinworld.com Mon Jun 13 18:44:48 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 13 18:45:11 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: <691E8DF5-C3F7-404A-989B-FBF4EFC689E4@gmail.com> Message-ID: On Tue, Jun 14, 2016 at 2:21 AM, Ben Coman wrote: > On Tue, Jun 14, 2016 at 12:36 AM, Eliot Miranda wrote: >> >> Ben, >> >> this looks fabulous. I've just skimmed on my phone and will look in more depth later but this is an extremely valuable and illuminating approach, visualizing something I have in my head but that is difficult to describe. Thanks for doing this!! One thing I would love for you to do (and I can help) is to create two diagrams, one for the simulator and one for the real VM, and relate the two, for example by colour-coding the common activities, and hence identifying simulator-only "distractions". >> >> _,,,^..^,,,_ (phone) >> >>> On Jun 13, 2016, at 6:24 AM, Ben Coman wrote: >>> >>> In trying to understand the flow of execution (and in particular the >>> jumps in the jitted VM, I made a first rough pass to map it in the >>> attached chart. >>> >>> I am trying to colourize it to distinguish between paths that can >>> return to the interpreter, those that circulate in jitted code, and >>> the transitions. I'm sure I've missed the mark a bit but its a start. >>> Of course corrections welcome, even scanned pen sketches. >>> >>> cheer -ben >>> > > I consolidated a few boxes and aligned common tasks, particularly the > returnToExecutive one. > cheers -ben Two initial comments: * It would be nice if the two "(stackPointer >= stackLimit)" and "(localSP < stackLimit)" were not inverted * Is the "siglong: /reenterInterpreter/ jmp: ReturnToInterpreter" at the end of #interpretMethodFromMachineCode required? It executes after activateNewMethod and returnToExecutive:postContextSwitch which has a siglong:jump anyway. And it messes with the diagram :) cheers -ben From btc at openinworld.com Mon Jun 13 18:51:13 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 13 18:51:40 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: It will take me a while to digest this, but I'll happy to give it a go. cheers -ben On Tue, Jun 14, 2016 at 2:41 AM, Eliot Miranda wrote: > > Hi Ben, > > the diagram below shows the trees, but the wood is arguably more important. The diagram below is focussing on the transitions, but doesn't clearly show what is being transitioned between. I imagine a diagram which shows the structures and has what you have in the yellow boxes as transitions. So... > > The essential structures are six-fold, three execution state structures, and three bodies of code, and in fact there is overlap of one of each. > > These are the execution state structures: > > 1. the C stack. > 2. the Smalltalk stack zone. > 3. the Smalltalk heap (which includes contexts that overflow the Smalltalk stack zone). > > These are the bodies of code: > 4. the run-time, the code comprising the VM interpreter, JIT, garbage collector, and primitives > 5. the jitted code living in the machine code zone, comprising methods, polymorphic in line caches, and the glue routines (trampolines and enilopmarts) between that machine code and the run-time > 6. Smalltalk "source" code, the classes and methods in the Smalltalk heap that constitute the "program" under execution > > So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack zone is a "cache", keeping the most recent activations in the most efficient form for execution. > Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. (the jitted code) runs only on 2. (the stack zone), and also, code in 6. executed (interpreted) by the interpreter and primitives in 4. runs on 2. (the stack zone) > > Your diagram names some of the surface transitions, but not the deeper when and why. Here they are: > > a) execution begins on the C stack as the program is launched. Once the heap is loaded, swizzling pointers as required, the interpreter is entered. On first entry it > a1) allocates space for the stack zone on the C stack > a2) "marries" the context in the image that invoked the snapshot primitive (a stack frame in the stack zone is built for the context, and the context is changed to become a proxy for that stack frame). > a3) captures the top of the C stack (CStackPointer & CFramePointer) as interpret is about to be invoked, including creating a "landing pad" for jumping back into the interpreter > a3 vm) the landing pad is a jmpbuf created via setjmp, and jumped to via longjmp > a3 sim) the landing pad is an exception handler for the ReenterInterpreter notification > a4) calls interpret to start interpreting the method that executed the snapshot primitive > > > Invoking the run-time: > Machine code calls into the run-time for several facilities: adding an object to the remembered table if a store check indicates this must happen, running a primitive in the run-time, entering the run-time to lookup and bind a machine code send, or a linked send that has missed. To invoke the run-time, the machine code saves the native stack and frame pointers (those of the current Smalltalk stack frame) in stackPointer and framePointer, sets the native stack and frame pointers to CStackPointer and CFramePointer, passes parameters (pushing x86, loading registers ARM, x64) and calls the run-time routine. Simple routines (adding element to the remembered set) simply perform the operation and return. The code returned to then switches back to the Smalltalk stack pointers and continues. Routines that change the Smalltalk frame (send-linking routines, complex primitives such as perform:) reenter via an enilopmart. > > > Transition to the interpreter: > So any time the machine code wants to transition to the interpreter (not simply call a routine in the run-time, but to interpret an as-yet-unjitted/unjittable method, either via send or return, the machine code switches the frame and stack pointers to those captured in a3) and longjmps (raises the ReenterInterpreter exception). It does this by calling a run-time routine (as in "Invoking the run-time") that actually performs the longjmp. Any intervening state on the C stack will be discarded, and execution will be in the same state as when the interpret routine was entered immediately after initialising the stack zone. > > > N.B. Note that if the interpreter merely called the machine-code, and the machine-code merely called the run-time, instead of substituting the stack and frame pointers with CStackPointer and CFramePointer set up on initial invocation of interpret, then the C stack would grow on each transition between machine code execution and interpreter/run-time execution and the C stack would soon overflow. > > > Call-backs: > > The C stack /can/ grow however. If a call-out calls back then the call-back executes lower down the C stack. A call out will have been made from some primitive invoked either from the interpreter or machine-code, and that primitive will run on the C stack. On calling back, the VM saves the current CStackPointer, CFramePointer and "landing-pad" jmpbuf in state associated with the call-back, and then reenters the interpreter, saving new values for the CStackPointer, CFramePointer and "landing-pad" jmpbuf. Execution now continues in this new part of the C stack below the original. On the call-back returning (again via a primitive), the CStackPointer, CFramePointer and "landing-pad" jmpbuf are restored before returning to the C code that invoked the call-back. Once this C code returns, the stack is unwound back to the state before the call-out was invoked. > > > Transition to machine-code: > The interpreter uses the simple policy of jitting a method if it is found in the first-level method lookup cache, effectively hitting methods that are used more than once. If the jitter method contains a primitive, that primitive routine will be invoked just as if it were an interpreted method. If the method doesn't have a primitive, the interpreter will jump into machine code immediately. t jumps into machine code by pushing any parameters (the state of the machine code registers, such as ReceiverResultReg, and the machine code address to begin execution) onto the top of the Smalltalk stack, and calling an enilopmart that switches from the C to the Smalltalk stack, loads the registers and jumps to the machine code address via a return instruction that pops the entry point off the Smalltalk stack. > > > Simulating these transitions in the Simulator: > In the Simulator, the C run-time (4.) are Smalltalk objects, and 1., 2., 3., 5., & 6. live in the memory inst var of the object memory, a large ByteArray. The machine code lives in the bottom of this memory byte array (MBA), and has no direct access to the Smalltalk objects. In the real VM, the correlates of these objects all exist at specific addresses and may be accessed directly from machine code. In the simulator this is not possible. Instead, these objects are all assigned out-of-bounds addresses, and a dictionary maps from the specific out-of-bounds address to the specific object being accessed, e.g. stackPointer, an inst var of InterpreterPrimitives, the superclass of StackInterpreter, has an address in simulatedAddresses that maps to a block that does a perform to access stackPointer's value. See CoInterpreter>>stackPointerAddress. > > Machine code is executed by one of the processor aliens via the primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: primitives. These primitives will fail when they encounter an illegal instruction, including an instruction that tried to fetch or store or jump to an out-of-bounds address. The primitive failure code analyses the instruction that failed and (when appropriate, the instruction may actually be illegal, the result of some bug in the system, but is typically an intended access of some run-time object) creates an instance of the ProcessorSimulationTrap exception and raises it. The handler then handles the exception to either fetch, store or invoke Smalltalk objects in the simulation, and once handled execution can continue. > > Hence in the simulator primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: (actually their wrappers singleStepIn:minimumAddress:readOnlyBelow: & runInMemory:minimumAddress:readOnlyBelow: are always invoked in the context of Cogit>>simulateCogCodeAt:, which provides the handler, and tests for machine code break-points using the breakBlock. > > In the same way that the VM must avoid C stack growth when transitioning between machine code and the interpreter/run-time above, so the simulator must avoid uncontrolled stack growth when the simulated machine code invokes Smalltalk code which again invokes simulated machine code. So the code that invokes the run-time from simulateCogCodeAt: (Cogit>>#handleCallOrJumpSimulationTrap:) includes a handler for the ReenterMachineCode notification. Whenever the Smalltalk run-time wants to reenter machine code via an enilopmart it sends Cogit>>#simulateEnilopmart:numArgs: which raises the notification before sending Cogit>>simulateCogCodeAt:. So the first entry into machine code via an enilopmart starts Cogit>>simulateCogCodeAt:, but subsequent ones end up returning to that first Cogit>>simulateCogCodeAt: to continue execution. > > > Ben, given the above, can you now see how your yellow boxes name specific transitions amongst the structures explained below? I hope I've encouraged you, not discouraged you, to revise and bifurcate your diagram into two state transition diagrams for the real and simulated VM. It would be great to have really good diagrammatic representations of the above. > > And once we have that, we can build the relatively simple extension that allows the interpreter and machine code to interleave interpreted and machine code frames on the Smalltalk stack (2.) that allow the VM to freely switch between interpreted and jitter code, and to fall back on the interpreter whenever convenient. > > On Mon, Jun 13, 2016 at 6:24 AM, Ben Coman wrote: >> >> >> In trying to understand the flow of execution (and in particular the >> jumps in the jitted VM, I made a first rough pass to map it in the >> attached chart. >> >> I am trying to colourize it to distinguish between paths that can >> return to the interpreter, those that circulate in jitted code, and >> the transitions. I'm sure I've missed the mark a bit but its a start. >> Of course corrections welcome, even scanned pen sketches. >> >> cheer -ben >> > > > > -- > _,,,^..^,,,_ > best, Eliot > From btc at openinworld.com Tue Jun 14 01:49:52 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 14 01:50:15 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 2:41 AM, Eliot Miranda wrote: > > Hi Ben, > > the diagram below shows the trees, but the wood is arguably more important. The diagram below is focussing on the transitions, but doesn't clearly show what is being transitioned between. I imagine a diagram which shows the structures and has what you have in the yellow boxes as transitions. So... > > The essential structures are six-fold, three execution state structures, and three bodies of code, and in fact there is overlap of one of each. > > These are the execution state structures: > > 1. the C stack. > 2. the Smalltalk stack zone. > 3. the Smalltalk heap (which includes contexts that overflow the Smalltalk stack zone). > > These are the bodies of code: > 4. the run-time, the code comprising the VM interpreter, JIT, garbage collector, and primitives > 5. the jitted code living in the machine code zone, comprising methods, polymorphic in line caches, and the glue routines (trampolines and enilopmarts) between that machine code and the run-time > 6. Smalltalk "source" code, the classes and methods in the Smalltalk heap that constitute the "program" under execution > > So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack zone is a "cache", keeping the most recent activations in the most efficient form for execution. > Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. (the jitted code) runs only on 2. (the stack zone), and also, code in 6. executed (interpreted) by the interpreter and primitives in 4. runs on 2. (the stack zone) I don't have the charting tool where I am atm, so I knocked up the above in Excel with a few embellishments that need checking. I am a bit confused by "primitives in 4. runs on 2. " when "4. (the run-time) executes solely on 1." and primitives are part of 4. Also I'm not clear on what a "linked-send" is? cheers -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: Cog-structure%code.png Type: image/png Size: 20117 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/164f86ed/Cog-structurecode-0001.png From eliot.miranda at gmail.com Tue Jun 14 02:21:22 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 14 02:21:28 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: <7FA6D93C-B37D-4C93-8C4B-A1B1291CB8F1@gmail.com> Hi Ben, > On Jun 13, 2016, at 6:49 PM, Ben Coman wrote: > >> On Tue, Jun 14, 2016 at 2:41 AM, Eliot Miranda wrote: >> >> Hi Ben, >> >> the diagram below shows the trees, but the wood is arguably more important. The diagram below is focussing on the transitions, but doesn't clearly show what is being transitioned between. I imagine a diagram which shows the structures and has what you have in the yellow boxes as transitions. So... >> >> The essential structures are six-fold, three execution state structures, and three bodies of code, and in fact there is overlap of one of each. >> >> These are the execution state structures: >> >> 1. the C stack. >> 2. the Smalltalk stack zone. >> 3. the Smalltalk heap (which includes contexts that overflow the Smalltalk stack zone). >> >> These are the bodies of code: >> 4. the run-time, the code comprising the VM interpreter, JIT, garbage collector, and primitives >> 5. the jitted code living in the machine code zone, comprising methods, polymorphic in line caches, and the glue routines (trampolines and enilopmarts) between that machine code and the run-time >> 6. Smalltalk "source" code, the classes and methods in the Smalltalk heap that constitute the "program" under execution >> >> So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack zone is a "cache", keeping the most recent activations in the most efficient form for execution. >> Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. (the jitted code) runs only on 2. (the stack zone), and also, code in 6. executed (interpreted) by the interpreter and primitives in 4. runs on 2. (the stack zone) > > I don't have the charting tool where I am atm, so I knocked up the > above in Excel with a few embellishments that need checking. I am a > bit confused by "primitives in 4. runs on 2. " when "4. (the > run-time) executes solely on 1." and primitives are part of 4. All primitives are implemented either in the interpreter, or in plugins, and some of the core primitives (arithmetic, comparison, object access and instantiation, block evaluation and perform) are also implemented by the JIT in machine code versions. Taking the former first, all primitives in the interpreter and plugins are C functions that get called either from the interpreter (slowPrimitiveResponse) or from a cogged (machine code) method containing a primitive. When running these primitives are running on the C stack, even though they take their parameters from the Smalltalk stack. So they are 4. (part of the run-time) running on 1. (the C stack). The machine code versions of primitives are compiled into the start of cogged methods that include one of the vote primitives the JIT is able to generate machine code for. This code gets executed directly when a cogged method is invoked. [Tangent: since 0,1 & 2 argument sends use a register based calling convention, most machine code primitives (the only exception being perform:with:with:) take their arguments from registers and answer their result in a register. So they're much much faster: direct access to arguments instead of indirecting through stackPointer, no stack-switching call/return from Smalltalk stack to C stack and back, but they have to be written in the JIT's assembler language.] > Also I'm not clear on what a "linked-send" is? This is another tangent, but key to how the JIT speeds up normal Smalltalk sends. A linked send is how the JIT speeds up sends; it is the implementation of an inline per-send-site send cache. In machine code, sends get compiled as a register load (of a selector) followed by a call (of a trampoline that calls ceSend:super:numArgs:). When first executed, the send of the selector to the current receiver gets looked up and the instruction sequence gets rewritten into a register load (of the class index if the current receiver) followed by a call (to the method that ceSend:super:numArgs: looked up and jitted). This latter form is a linked send because it is linked to the entry point of some target method. That target method's entry code checks that the class index of the current receiver matches that in the register load, and continues executing the method if they match or calling code to rebound the send to a PIC if they don't. So once the send is linked subsequent executions call the target method directly and perform a relatively cheap class check that succeeds in most cases. If ever it misses, the send site will get bound to a "closed" PIC, a little jump table created specific to that send site, that can hold up to 6 class index comparison, jump pairs (it can dispatch up to 6 classes of receiver) and if there are more than 6, will get rewritten to an "open" PIC specific to the selector, that probes the first level method lookup cache. So in practice all sends except about 1% of megamorphic sends such as the sends of basicNew and initialize in Behavior>>#new settle down into calls, with no relinking occurring until either the program changes flow (introducing polymorphism) or the code zone fills up, methods are discarded and sends unlinked and later reexecuted, which doesn't happen very often. > cheers -ben > _,,,^..^,,,_ (phone) From tim at rowledge.org Tue Jun 14 03:41:01 2016 From: tim at rowledge.org (tim Rowledge) Date: Tue Jun 14 03:40:52 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: <7FA6D93C-B37D-4C93-8C4B-A1B1291CB8F1@gmail.com> References: <7FA6D93C-B37D-4C93-8C4B-A1B1291CB8F1@gmail.com> Message-ID: > On 13-06-2016, at 7:21 PM, Eliot Miranda wrote: > If ever it misses, the send site will get bound to a "closed" PIC, a little jump table created specific to that send site, that can hold up to 6 class index comparison, jump pairs (it can dispatch up to 6 classes of receiver) and if there are more than 6, will get rewritten to an "open" PIC specific to the selector, that probes the first level method lookup cache. Whilst reading that a strange thought leaped up from somewhere and landed in my head; might it be useful to just replace the final pic-miss jump with a jump instead to the open lookup but keep the other six previously carefully built cases? It?s not like they?ve gone away in any sense. Might need to change the use of the ClassReg there too? After all, the open lookup is really just a pic-miss that doesn?t build a new cpic entry... tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Thinks E=MC^2 is a rap star. From leves at caesar.elte.hu Tue Jun 14 11:26:44 2016 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Tue Jun 14 11:26:47 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: <7FA6D93C-B37D-4C93-8C4B-A1B1291CB8F1@gmail.com> Message-ID: That would make sense if the six entries were the among the most commonly used ones. We had a discussion recently about adaptive PICs, which would reorder the entries based on some statistics, and the conclusion was that the overhead would be way higher than the potential benefit. I did some measurements at that time about what the ideal size of a PIC would be. On my machine 12 had the same worst(?) case lookup time as the open PIC. Don't ask me how I measured it. :) Levente On Mon, 13 Jun 2016, tim Rowledge wrote: > > >> On 13-06-2016, at 7:21 PM, Eliot Miranda wrote: >> If ever it misses, the send site will get bound to a "closed" PIC, a little jump table created specific to that send site, that can hold up to 6 class index comparison, jump pairs (it can dispatch up to 6 classes of receiver) and if there are more than 6, will get rewritten to an "open" PIC specific to the selector, that probes the first level method lookup cache. > > Whilst reading that a strange thought leaped up from somewhere and landed in my head; might it be useful to just replace the final pic-miss jump with a jump instead to the open lookup but keep the other six previously carefully built cases? It?s not like they?ve gone away in any sense. Might need to change the use of the ClassReg there too? After all, the open lookup is really just a pic-miss that doesn?t build a new cpic entry... > > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Useful random insult:- Thinks E=MC^2 is a rap star. > > > From brasspen at gmail.com Tue Jun 14 13:23:50 2016 From: brasspen at gmail.com (Chris Cunnington) Date: Tue Jun 14 13:23:53 2016 Subject: [Vm-dev] CogVMExecution Flow Message-ID: <553ffebf-c503-778e-6efe-c629655af4fa@gmail.com> > a2) "marries" the context in the image that invoked the snapshot > primitive (a stack frame in the stack zone is built for the context, and > the context is changed to become a proxy for that stack frame). When saving to disk, does the stack state of a married frame inside a CogStackPage bitmap get saved back to the stack of a MethodContext instance? The CompiledMethod of a MethodContext is not changed in an image. It is compiled by the StackToRegisterMappingCogit and stored in a frame in the CogStackPage as a copy. This is not saved when the image is saved to disk. The machine code is thrown away. It only existed in RAM. That's fine, because you have the original CompiledMethod untouched with its bytecodes. But if in the process of execution the state of a stack under a MethodContext changes, and it will, and the entire content of the CogStackPages bitmaps will be nulled out and not saved to disk in the image as new, extra memory, then does the married frame shiv its content back into every MethodContext instance on snapshot and quit? The frame has a header that can point to the CompiledMethod with bytecodes or to a machine code compiled version next door in the CogStackPage bitmap. But if you copy the stack of a MethodContext into its married frame, then the stack in the MethodContext is out of date, while the CoInterpreter spins everything it needs in the separate world in CogStackPages; then, when you save to disk, are you, as a last effort, saving state back from every married frame to its original MethodContext instance? Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/9b199b2e/attachment.htm From btc at openinworld.com Tue Jun 14 14:28:01 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 14 14:28:28 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 2:41 AM, Eliot Miranda wrote: > > Hi Ben, > > the diagram below shows the trees, but the wood is arguably more important. The diagram below is focussing on the transitions, but doesn't clearly show what is being transitioned between. I imagine a diagram which shows the structures and has what you have in the yellow boxes as transitions. So... > > The essential structures are six-fold, three execution state structures, and three bodies of code, and in fact there is overlap of one of each. > > These are the execution state structures: > > 1. the C stack. > 2. the Smalltalk stack zone. > 3. the Smalltalk heap (which includes contexts that overflow the Smalltalk stack zone). > > These are the bodies of code: > 4. the run-time, the code comprising the VM interpreter, JIT, garbage collector, and primitives > 5. the jitted code living in the machine code zone, comprising methods, polymorphic in line caches, and the glue routines (trampolines and enilopmarts) between that machine code and the run-time > 6. Smalltalk "source" code, the classes and methods in the Smalltalk heap that constitute the "program" under execution > > So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack zone is a "cache", keeping the most recent activations in the most efficient form for execution. > Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. (the jitted code) runs only on 2. (the stack zone), and also, code in 6. executed (interpreted) by the interpreter and primitives in 4. runs on 2. (the stack zone) > > Your diagram names some of the surface transitions, but not the deeper when and why. Here they are: > > a) execution begins on the C stack as the program is launched. Once the heap is loaded, swizzling pointers as required, the interpreter is entered. On first entry it > a1) allocates space for the stack zone on the C stack > a2) "marries" the context in the image that invoked the snapshot primitive (a stack frame in the stack zone is built for the context, and the context is changed to become a proxy for that stack frame). > a3) captures the top of the C stack (CStackPointer & CFramePointer) as interpret is about to be invoked, including creating a "landing pad" for jumping back into the interpreter > a3 vm) the landing pad is a jmpbuf created via setjmp, and jumped to via longjmp > a3 sim) the landing pad is an exception handler for the ReenterInterpreter notification > a4) calls interpret to start interpreting the method that executed the snapshot primitive > > > Invoking the run-time: > Machine code calls into the run-time for several facilities: adding an object to the remembered table if a store check indicates this must happen, running a primitive in the run-time, entering the run-time to lookup and bind a machine code send, or a linked send that has missed. To invoke the run-time, the machine code saves the native stack and frame pointers (those of the current Smalltalk stack frame) in stackPointer and framePointer, sets the native stack and frame pointers to CStackPointer and CFramePointer, passes parameters (pushing x86, loading registers ARM, x64) and calls the run-time routine. Simple routines (adding element to the remembered set) simply perform the operation and return. The code returned to then switches back to the Smalltalk stack pointers and continues. Routines that change the Smalltalk frame (send-linking routines, complex primitives such as perform:) reenter via an enilopmart. > > > Transition to the interpreter: > So any time the machine code wants to transition to the interpreter (not simply call a routine in the run-time, but to interpret an as-yet-unjitted/unjittable method, either via send or return, the machine code switches the frame and stack pointers to those captured in a3) and longjmps (raises the ReenterInterpreter exception). It does this by calling a run-time routine (as in "Invoking the run-time") that actually performs the longjmp. Any intervening state on the C stack will be discarded, and execution will be in the same state as when the interpret routine was entered immediately after initialising the stack zone. > > > N.B. Note that if the interpreter merely called the machine-code, and the machine-code merely called the run-time, instead of substituting the stack and frame pointers with CStackPointer and CFramePointer set up on initial invocation of interpret, then the C stack would grow on each transition between machine code execution and interpreter/run-time execution and the C stack would soon overflow. > > > Call-backs: > > The C stack /can/ grow however. If a call-out calls back then the call-back executes lower down the C stack. A call out will have been made from some primitive invoked either from the interpreter or machine-code, and that primitive will run on the C stack. On calling back, the VM saves the current CStackPointer, CFramePointer and "landing-pad" jmpbuf in state associated with the call-back, and then reenters the interpreter, saving new values for the CStackPointer, CFramePointer and "landing-pad" jmpbuf. Execution now continues in this new part of the C stack below the original. On the call-back returning (again via a primitive), the CStackPointer, CFramePointer and "landing-pad" jmpbuf are restored before returning to the C code that invoked the call-back. Once this C code returns, the stack is unwound back to the state before the call-out was invoked. > > > Transition to machine-code: > The interpreter uses the simple policy of jitting a method if it is found in the first-level method lookup cache, effectively hitting methods that are used more than once. If the jitter method contains a primitive, that primitive routine will be invoked just as if it were an interpreted method. If the method doesn't have a primitive, the interpreter will jump into machine code immediately. t jumps into machine code by pushing any parameters (the state of the machine code registers, such as ReceiverResultReg, and the machine code address to begin execution) onto the top of the Smalltalk stack, and calling an enilopmart that switches from the C to the Smalltalk stack, loads the registers and jumps to the machine code address via a return instruction that pops the entry point off the Smalltalk stack. > > > Simulating these transitions in the Simulator: > In the Simulator, the C run-time (4.) are Smalltalk objects, and 1., 2., 3., 5., & 6. live in the memory inst var of the object memory, a large ByteArray. The machine code lives in the bottom of this memory byte array (MBA), and has no direct access to the Smalltalk objects. In the real VM, the correlates of these objects all exist at specific addresses and may be accessed directly from machine code. In the simulator this is not possible. Instead, these objects are all assigned out-of-bounds addresses, and a dictionary maps from the specific out-of-bounds address to the specific object being accessed, e.g. stackPointer, an inst var of InterpreterPrimitives, the superclass of StackInterpreter, has an address in simulatedAddresses that maps to a block that does a perform to access stackPointer's value. See CoInterpreter>>stackPointerAddress. > > Machine code is executed by one of the processor aliens via the primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: primitives. These primitives will fail when they encounter an illegal instruction, including an instruction that tried to fetch or store or jump to an out-of-bounds address. The primitive failure code analyses the instruction that failed and (when appropriate, the instruction may actually be illegal, the result of some bug in the system, but is typically an intended access of some run-time object) creates an instance of the ProcessorSimulationTrap exception and raises it. The handler then handles the exception to either fetch, store or invoke Smalltalk objects in the simulation, and once handled execution can continue. > > Hence in the simulator primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: (actually their wrappers singleStepIn:minimumAddress:readOnlyBelow: & runInMemory:minimumAddress:readOnlyBelow: are always invoked in the context of Cogit>>simulateCogCodeAt:, which provides the handler, and tests for machine code break-points using the breakBlock. > > In the same way that the VM must avoid C stack growth when transitioning between machine code and the interpreter/run-time above, so the simulator must avoid uncontrolled stack growth when the simulated machine code invokes Smalltalk code which again invokes simulated machine code. So the code that invokes the run-time from simulateCogCodeAt: (Cogit>>#handleCallOrJumpSimulationTrap:) includes a handler for the ReenterMachineCode notification. Whenever the Smalltalk run-time wants to reenter machine code via an enilopmart it sends Cogit>>#simulateEnilopmart:numArgs: which raises the notification before sending Cogit>>simulateCogCodeAt:. So the first entry into machine code via an enilopmart starts Cogit>>simulateCogCodeAt:, but subsequent ones end up returning to that first Cogit>>simulateCogCodeAt: to continue execution. > > > Ben, given the above, can you now see how your yellow boxes name specific transitions amongst the structures explained below? I hope I've encouraged you, not discouraged you, to revise and bifurcate your diagram into two state transition diagrams for the real and simulated VM. Thats cool. Just another good reason to spend time soaking up details as goal directed learning. Now what I found easiest was to start from scratch to convert your prose verbatim into a diagram, rather than referring to the code as I was before. Now I feel the result somewhat butchered what you said, but at least it provides another perspective as a point of discussion to build my understanding. Then try to merging it into the one I was deriving from the code. I've not considered the simulation part yet. Thought it best to get some feedback. Its been a looong time since I've done any formal diagramming and the symbology is poor. Can anyone suggest a useful type of diagram for this circumstance I could look up and give a try. Attached: CogVM-Transitions-2016.06.14a.zip cheers -ben > It would be great to have really good diagrammatic representations of the above. > > And once we have that, we can build the relatively simple extension that allows the interpreter and machine code to interleave interpreted and machine code frames on the Smalltalk stack (2.) that allow the VM to freely switch between interpreted and jitter code, and to fall back on the interpreter whenever convenient. > > On Mon, Jun 13, 2016 at 6:24 AM, Ben Coman wrote: >> >> >> In trying to understand the flow of execution (and in particular the >> jumps in the jitted VM, I made a first rough pass to map it in the >> attached chart. >> >> I am trying to colourize it to distinguish between paths that can >> return to the interpreter, those that circulate in jitted code, and >> the transitions. I'm sure I've missed the mark a bit but its a start. >> Of course corrections welcome, even scanned pen sketches. -------------- next part -------------- A non-text attachment was scrubbed... Name: CogVM-Transitions-2016.06.14a.zip Type: application/zip Size: 165489 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/e0d24987/CogVM-Transitions-2016.06.14a-0001.zip From btc at openinworld.com Tue Jun 14 16:26:50 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 14 16:27:13 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 2:41 AM, Eliot Miranda wrote: > > Hi Ben, > > the diagram below shows the trees, but the wood is arguably more important. The diagram below is focussing on the transitions, but doesn't clearly show what is being transitioned between. I imagine a diagram which shows the structures and has what you have in the yellow boxes as transitions. By transitions do you mean graph edges? That actually turns out a little difficult because I can't attach multiple edges together like I can attached multiple edges to a shape - but I'll keep trying. btw, Are externalizeIPandSP and internalizeIPandSP big hints as to the transitions between those main structures? If so, could you spell out which is which. Also do stackPointer, framePointer, instructionPointer, localSP, localFP, etc belong to certain of those structures? cheers -ben > So... > The essential structures are six-fold, three execution state structures, and three bodies of code, and in fact there is overlap of one of each. > > These are the execution state structures: > > 1. the C stack. > 2. the Smalltalk stack zone. > 3. the Smalltalk heap (which includes contexts that overflow the Smalltalk stack zone). > > These are the bodies of code: > 4. the run-time, the code comprising the VM interpreter, JIT, garbage collector, and primitives > 5. the jitted code living in the machine code zone, comprising methods, polymorphic in line caches, and the glue routines (trampolines and enilopmarts) between that machine code and the run-time > 6. Smalltalk "source" code, the classes and methods in the Smalltalk heap that constitute the "program" under execution > > So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack zone is a "cache", keeping the most recent activations in the most efficient form for execution. > Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. (the jitted code) runs only on 2. (the stack zone), and also, code in 6. executed (interpreted) by the interpreter and primitives in 4. runs on 2. (the stack zone) > > Your diagram names some of the surface transitions, but not the deeper when and why. Here they are: > > a) execution begins on the C stack as the program is launched. Once the heap is loaded, swizzling pointers as required, the interpreter is entered. On first entry it > a1) allocates space for the stack zone on the C stack > a2) "marries" the context in the image that invoked the snapshot primitive (a stack frame in the stack zone is built for the context, and the context is changed to become a proxy for that stack frame). > a3) captures the top of the C stack (CStackPointer & CFramePointer) as interpret is about to be invoked, including creating a "landing pad" for jumping back into the interpreter > a3 vm) the landing pad is a jmpbuf created via setjmp, and jumped to via longjmp > a3 sim) the landing pad is an exception handler for the ReenterInterpreter notification > a4) calls interpret to start interpreting the method that executed the snapshot primitive > > > Invoking the run-time: > Machine code calls into the run-time for several facilities: adding an object to the remembered table if a store check indicates this must happen, running a primitive in the run-time, entering the run-time to lookup and bind a machine code send, or a linked send that has missed. To invoke the run-time, the machine code saves the native stack and frame pointers (those of the current Smalltalk stack frame) in stackPointer and framePointer, sets the native stack and frame pointers to CStackPointer and CFramePointer, passes parameters (pushing x86, loading registers ARM, x64) and calls the run-time routine. Simple routines (adding element to the remembered set) simply perform the operation and return. The code returned to then switches back to the Smalltalk stack pointers and continues. Routines that change the Smalltalk frame (send-linking routines, complex primitives such as perform:) reenter via an enilopmart. > > > Transition to the interpreter: > So any time the machine code wants to transition to the interpreter (not simply call a routine in the run-time, but to interpret an as-yet-unjitted/unjittable method, either via send or return, the machine code switches the frame and stack pointers to those captured in a3) and longjmps (raises the ReenterInterpreter exception). It does this by calling a run-time routine (as in "Invoking the run-time") that actually performs the longjmp. Any intervening state on the C stack will be discarded, and execution will be in the same state as when the interpret routine was entered immediately after initialising the stack zone. > > > N.B. Note that if the interpreter merely called the machine-code, and the machine-code merely called the run-time, instead of substituting the stack and frame pointers with CStackPointer and CFramePointer set up on initial invocation of interpret, then the C stack would grow on each transition between machine code execution and interpreter/run-time execution and the C stack would soon overflow. > > > Call-backs: > > The C stack /can/ grow however. If a call-out calls back then the call-back executes lower down the C stack. A call out will have been made from some primitive invoked either from the interpreter or machine-code, and that primitive will run on the C stack. On calling back, the VM saves the current CStackPointer, CFramePointer and "landing-pad" jmpbuf in state associated with the call-back, and then reenters the interpreter, saving new values for the CStackPointer, CFramePointer and "landing-pad" jmpbuf. Execution now continues in this new part of the C stack below the original. On the call-back returning (again via a primitive), the CStackPointer, CFramePointer and "landing-pad" jmpbuf are restored before returning to the C code that invoked the call-back. Once this C code returns, the stack is unwound back to the state before the call-out was invoked. > > > Transition to machine-code: > The interpreter uses the simple policy of jitting a method if it is found in the first-level method lookup cache, effectively hitting methods that are used more than once. If the jitter method contains a primitive, that primitive routine will be invoked just as if it were an interpreted method. If the method doesn't have a primitive, the interpreter will jump into machine code immediately. t jumps into machine code by pushing any parameters (the state of the machine code registers, such as ReceiverResultReg, and the machine code address to begin execution) onto the top of the Smalltalk stack, and calling an enilopmart that switches from the C to the Smalltalk stack, loads the registers and jumps to the machine code address via a return instruction that pops the entry point off the Smalltalk stack. > > > Simulating these transitions in the Simulator: > In the Simulator, the C run-time (4.) are Smalltalk objects, and 1., 2., 3., 5., & 6. live in the memory inst var of the object memory, a large ByteArray. The machine code lives in the bottom of this memory byte array (MBA), and has no direct access to the Smalltalk objects. In the real VM, the correlates of these objects all exist at specific addresses and may be accessed directly from machine code. In the simulator this is not possible. Instead, these objects are all assigned out-of-bounds addresses, and a dictionary maps from the specific out-of-bounds address to the specific object being accessed, e.g. stackPointer, an inst var of InterpreterPrimitives, the superclass of StackInterpreter, has an address in simulatedAddresses that maps to a block that does a perform to access stackPointer's value. See CoInterpreter>>stackPointerAddress. > > Machine code is executed by one of the processor aliens via the primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: primitives. These primitives will fail when they encounter an illegal instruction, including an instruction that tried to fetch or store or jump to an out-of-bounds address. The primitive failure code analyses the instruction that failed and (when appropriate, the instruction may actually be illegal, the result of some bug in the system, but is typically an intended access of some run-time object) creates an instance of the ProcessorSimulationTrap exception and raises it. The handler then handles the exception to either fetch, store or invoke Smalltalk objects in the simulation, and once handled execution can continue. > > Hence in the simulator primitiveRunInMemory:minimumAddress:readOnlyBelow: or primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: (actually their wrappers singleStepIn:minimumAddress:readOnlyBelow: & runInMemory:minimumAddress:readOnlyBelow: are always invoked in the context of Cogit>>simulateCogCodeAt:, which provides the handler, and tests for machine code break-points using the breakBlock. > > In the same way that the VM must avoid C stack growth when transitioning between machine code and the interpreter/run-time above, so the simulator must avoid uncontrolled stack growth when the simulated machine code invokes Smalltalk code which again invokes simulated machine code. So the code that invokes the run-time from simulateCogCodeAt: (Cogit>>#handleCallOrJumpSimulationTrap:) includes a handler for the ReenterMachineCode notification. Whenever the Smalltalk run-time wants to reenter machine code via an enilopmart it sends Cogit>>#simulateEnilopmart:numArgs: which raises the notification before sending Cogit>>simulateCogCodeAt:. So the first entry into machine code via an enilopmart starts Cogit>>simulateCogCodeAt:, but subsequent ones end up returning to that first Cogit>>simulateCogCodeAt: to continue execution. > > > Ben, given the above, can you now see how your yellow boxes name specific transitions amongst the structures explained below? I hope I've encouraged you, not discouraged you, to revise and bifurcate your diagram into two state transition diagrams for the real and simulated VM. It would be great to have really good diagrammatic representations of the above. > > And once we have that, we can build the relatively simple extension that allows the interpreter and machine code to interleave interpreted and machine code frames on the Smalltalk stack (2.) that allow the VM to freely switch between interpreted and jitter code, and to fall back on the interpreter whenever convenient. > > On Mon, Jun 13, 2016 at 6:24 AM, Ben Coman wrote: >> >> >> In trying to understand the flow of execution (and in particular the >> jumps in the jitted VM, I made a first rough pass to map it in the >> attached chart. >> >> I am trying to colourize it to distinguish between paths that can >> return to the interpreter, those that circulate in jitted code, and >> the transitions. I'm sure I've missed the mark a bit but its a start. >> Of course corrections welcome, even scanned pen sketches. >> >> cheer -ben >> > > > > -- > _,,,^..^,,,_ > best, Eliot > From btc at openinworld.com Tue Jun 14 16:30:39 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 14 16:31:02 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: btw, what does the "ce" stand for in all the methods... CI>> ceDynamicSuperSend:receiver: CI>> ceImplictRecevierSend:receiver: CI>> ceOuterSend:receiver: CI>> ceSelfSend: cheers -ben From btc at openinworld.com Tue Jun 14 16:43:48 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 14 16:44:12 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: Some other possible hints of transitions between structures is that only some methods have pragmas?? (Like . I notice a function... convertToMachineCodeFrame: cogMethod bcpc: cheers- ben From eliot.miranda at gmail.com Tue Jun 14 17:48:06 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 14 17:48:10 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: Hi Ben, On Tuesday, June 14, 2016, Ben Coman wrote: > > On Tue, Jun 14, 2016 at 2:41 AM, Eliot Miranda > wrote: > > > > Hi Ben, > > > > the diagram below shows the trees, but the wood is arguably more > important. The diagram below is focussing on the transitions, but doesn't > clearly show what is being transitioned between. I imagine a diagram which > shows the structures and has what you have in the yellow boxes as > transitions. > > By transitions do you mean graph edges? Yes. For example ceSend: is a transition from machine code to the run-time. > That actually turns out a > little difficult because I can't attach multiple edges together like I > can attached multiple edges to a shape - but I'll keep trying. > > btw, Are externalizeIPandSP and internalizeIPandSP big hints as to the > transitions between those main structures? No :-(. This is actually a milli-optimisation to the interpreter. If one wants an interpreter to go fast one needs as many of the key interpreter variables (stack pointer, frame pointer, instruction pointer) in registers. Compilers such as gcc allow global register variables (in part due to my work in BrouHaHa where I achieved this by nefarious means and then requested the facility of Richard Stallman). But that's non-portable. The approach taken in the Squeak VM is to inline much of the interpreter into one function and have localSP, localFP & localIP as local variables, and rely on the C compiler's optimiser to put these in registers. That means they have to be written to stackPointer, framePointer and instructionPointer before calling a primitive (externalize) and read back afterwards (internalize). Good idea, adds complexity, doesn't add much to the Cog VM, essential to the Stack & Interpreter VMs. > > If so, could you spell out > which is which. Also do stackPointer, framePointer, > instructionPointer, localSP, localFP, etc belong to certain of those > structures? Yes. You can see now that they belong to the interpreter and hence to the C runtime. They point to the current frame in the stack zone for the interpreter. In machine code we use the native sp, fp & pc and so every trampoline does an externalize, a call, and an internalize (which may not be reached if the call doesn't return), and every enilipmart does an internalize, but of the native sp, fp & pc rather than localSP, localFP, etc. Sorry about the font sizes. Using the gmail app for the first time and it mucks things up when copy/pasting. cheers -ben > > So... > > The essential structures are six-fold, three execution state structures, > and three bodies of code, and in fact there is overlap of one of each. > > > > These are the execution state structures: > > > > 1. the C stack. > > 2. the Smalltalk stack zone. > > 3. the Smalltalk heap (which includes contexts that overflow the > Smalltalk stack zone). > > > > These are the bodies of code: > > 4. the run-time, the code comprising the VM interpreter, JIT, garbage > collector, and primitives > > 5. the jitted code living in the machine code zone, comprising methods, > polymorphic in line caches, and the glue routines (trampolines and > enilopmarts) between that machine code and the run-time > > 6. Smalltalk "source" code, the classes and methods in the Smalltalk > heap that constitute the "program" under execution > > > > So 3. and 6. overlap; code is data, and 2. overflows into 3., the stack > zone is a "cache", keeping the most recent activations in the most > efficient form for execution. > > Further, 4. (the run-time) executes solely on 1. (the C stack), and 5. > (the jitted code) runs only on 2. (the stack zone), and also, code in 6. > executed (interpreted) by the interpreter and primitives in 4. runs on 2. > (the stack zone) > > > > Your diagram names some of the surface transitions, but not the deeper > when and why. Here they are: > > > > a) execution begins on the C stack as the program is launched. Once the > heap is loaded, swizzling pointers as required, the interpreter is > entered. On first entry it > > a1) allocates space for the stack zone on the C stack > > a2) "marries" the context in the image that invoked the snapshot > primitive (a stack frame in the stack zone is built for the context, and > the context is changed to become a proxy for that stack frame). > > a3) captures the top of the C stack (CStackPointer & CFramePointer) as > interpret is about to be invoked, including creating a "landing pad" for > jumping back into the interpreter > > a3 vm) the landing pad is a jmpbuf created via setjmp, and jumped to > via longjmp > > a3 sim) the landing pad is an exception handler for the > ReenterInterpreter notification > > a4) calls interpret to start interpreting the method that executed the > snapshot primitive > > > > > > Invoking the run-time: > > Machine code calls into the run-time for several facilities: adding an > object to the remembered table if a store check indicates this must happen, > running a primitive in the run-time, entering the run-time to lookup and > bind a machine code send, or a linked send that has missed. To invoke the > run-time, the machine code saves the native stack and frame pointers (those > of the current Smalltalk stack frame) in stackPointer and framePointer, > sets the native stack and frame pointers to CStackPointer and > CFramePointer, passes parameters (pushing x86, loading registers ARM, x64) > and calls the run-time routine. Simple routines (adding element to the > remembered set) simply perform the operation and return. The code returned > to then switches back to the Smalltalk stack pointers and continues. > Routines that change the Smalltalk frame (send-linking routines, complex > primitives such as perform:) reenter via an enilopmart. > > > > > > Transition to the interpreter: > > So any time the machine code wants to transition to the interpreter (not > simply call a routine in the run-time, but to interpret an > as-yet-unjitted/unjittable method, either via send or return, the machine > code switches the frame and stack pointers to those captured in a3) and > longjmps (raises the ReenterInterpreter exception). It does this by > calling a run-time routine (as in "Invoking the run-time") that actually > performs the longjmp. Any intervening state on the C stack will be > discarded, and execution will be in the same state as when the interpret > routine was entered immediately after initialising the stack zone. > > > > > > N.B. Note that if the interpreter merely called the machine-code, and > the machine-code merely called the run-time, instead of substituting the > stack and frame pointers with CStackPointer and CFramePointer set up on > initial invocation of interpret, then the C stack would grow on each > transition between machine code execution and interpreter/run-time > execution and the C stack would soon overflow. > > > > > > Call-backs: > > > > The C stack /can/ grow however. If a call-out calls back then the > call-back executes lower down the C stack. A call out will have been made > from some primitive invoked either from the interpreter or machine-code, > and that primitive will run on the C stack. On calling back, the VM saves > the current CStackPointer, CFramePointer and "landing-pad" jmpbuf in state > associated with the call-back, and then reenters the interpreter, saving > new values for the CStackPointer, CFramePointer and "landing-pad" jmpbuf. > Execution now continues in this new part of the C stack below the > original. On the call-back returning (again via a primitive), the > CStackPointer, CFramePointer and "landing-pad" jmpbuf are restored before > returning to the C code that invoked the call-back. Once this C code > returns, the stack is unwound back to the state before the call-out was > invoked. > > > > > > Transition to machine-code: > > The interpreter uses the simple policy of jitting a method if it is > found in the first-level method lookup cache, effectively hitting methods > that are used more than once. If the jitter method contains a primitive, > that primitive routine will be invoked just as if it were an interpreted > method. If the method doesn't have a primitive, the interpreter will jump > into machine code immediately. t jumps into machine code by pushing any > parameters (the state of the machine code registers, such as > ReceiverResultReg, and the machine code address to begin execution) onto > the top of the Smalltalk stack, and calling an enilopmart that switches > from the C to the Smalltalk stack, loads the registers and jumps to the > machine code address via a return instruction that pops the entry point off > the Smalltalk stack. > > > > > > Simulating these transitions in the Simulator: > > In the Simulator, the C run-time (4.) are Smalltalk objects, and 1., 2., > 3., 5., & 6. live in the memory inst var of the object memory, a large > ByteArray. The machine code lives in the bottom of this memory byte array > (MBA), and has no direct access to the Smalltalk objects. In the real VM, > the correlates of these objects all exist at specific addresses and may be > accessed directly from machine code. In the simulator this is not > possible. Instead, these objects are all assigned out-of-bounds addresses, > and a dictionary maps from the specific out-of-bounds address to the > specific object being accessed, e.g. stackPointer, an inst var of > InterpreterPrimitives, the superclass of StackInterpreter, has an address > in simulatedAddresses that maps to a block that does a perform to access > stackPointer's value. See CoInterpreter>>stackPointerAddress. > > > > Machine code is executed by one of the processor aliens via the > primitiveRunInMemory:minimumAddress:readOnlyBelow: or > primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: primitives. These > primitives will fail when they encounter an illegal instruction, including > an instruction that tried to fetch or store or jump to an out-of-bounds > address. The primitive failure code analyses the instruction that failed > and (when appropriate, the instruction may actually be illegal, the result > of some bug in the system, but is typically an intended access of some > run-time object) creates an instance of the ProcessorSimulationTrap > exception and raises it. The handler then handles the exception to either > fetch, store or invoke Smalltalk objects in the simulation, and once > handled execution can continue. > > > > Hence in the simulator > primitiveRunInMemory:minimumAddress:readOnlyBelow: or > primitiveSingleStepInMemory:minimumAddress:readOnlyBelow: (actually their > wrappers singleStepIn:minimumAddress:readOnlyBelow: & > runInMemory:minimumAddress:readOnlyBelow: are always invoked in the context > of Cogit>>simulateCogCodeAt:, which provides the handler, and tests for > machine code break-points using the breakBlock. > > > > In the same way that the VM must avoid C stack growth when transitioning > between machine code and the interpreter/run-time above, so the simulator > must avoid uncontrolled stack growth when the simulated machine code > invokes Smalltalk code which again invokes simulated machine code. So the > code that invokes the run-time from simulateCogCodeAt: > (Cogit>>#handleCallOrJumpSimulationTrap:) includes a handler for the > ReenterMachineCode notification. Whenever the Smalltalk run-time wants to > reenter machine code via an enilopmart it sends > Cogit>>#simulateEnilopmart:numArgs: which raises the notification before > sending Cogit>>simulateCogCodeAt:. So the first entry into machine code > via an enilopmart starts Cogit>>simulateCogCodeAt:, but subsequent ones end > up returning to that first Cogit>>simulateCogCodeAt: to continue execution. > > > > > > Ben, given the above, can you now see how your yellow boxes name > specific transitions amongst the structures explained below? I hope I've > encouraged you, not discouraged you, to revise and bifurcate your diagram > into two state transition diagrams for the real and simulated VM. It would > be great to have really good diagrammatic representations of the above. > > > > And once we have that, we can build the relatively simple extension that > allows the interpreter and machine code to interleave interpreted and > machine code frames on the Smalltalk stack (2.) that allow the VM to freely > switch between interpreted and jitter code, and to fall back on the > interpreter whenever convenient. > > > > On Mon, Jun 13, 2016 at 6:24 AM, Ben Coman > wrote: > >> > >> > >> In trying to understand the flow of execution (and in particular the > >> jumps in the jitted VM, I made a first rough pass to map it in the > >> attached chart. > >> > >> I am trying to colourize it to distinguish between paths that can > >> return to the interpreter, those that circulate in jitted code, and > >> the transitions. I'm sure I've missed the mark a bit but its a start. > >> Of course corrections welcome, even scanned pen sketches. > >> > >> cheer -ben > >> > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/3e3f58e4/attachment-0001.htm From eliot.miranda at gmail.com Tue Jun 14 17:49:25 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 14 17:49:26 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: On Tuesday, June 14, 2016, Ben Coman wrote: > > btw, what does the "ce" stand for in all the methods... > CI>> ceDynamicSuperSend:receiver: > CI>> ceImplictRecevierSend:receiver: > CI>> ceOuterSend:receiver: > CI>> ceSelfSend: Cog entry. A weak term, but groups all the code that machine code calls together. > cheers -ben > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/8f0c5d4f/attachment.htm From tim at rowledge.org Tue Jun 14 17:51:38 2016 From: tim at rowledge.org (tim Rowledge) Date: Tue Jun 14 17:51:28 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: <7FA6D93C-B37D-4C93-8C4B-A1B1291CB8F1@gmail.com> Message-ID: <2C66F8D8-578D-4A82-872B-6BD3E9F483AE@rowledge.org> Well overflowing a CPIC to an openPIC is rare enough that it probably doesn?t matter much anyway. > On 14-06-2016, at 4:26 AM, Levente Uzonyi wrote: > > That would make sense if the six entries were the among the most commonly used ones. That would be a good trick to manage! Clement might be able to provide some input from Sista to help us get closer I guess? But the important bit is that whilst they may very well not be the most commonly used methods, they are the most recently called ones, which means they have some importance in the current context. Making use of them isn?t likely to be a bad idea so far as I can see. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer Science: solving today's problems tomorrow. From eliot.miranda at gmail.com Tue Jun 14 17:52:43 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 14 17:52:45 2016 Subject: [Vm-dev] CogVM Execution Flow In-Reply-To: References: Message-ID: Hi Ben, On Tuesday, June 14, 2016, Ben Coman wrote: > > Some other possible hints of transitions between structures is that > only some methods have pragmas?? (Like > Only some methods are marked for . Right. Some methods must be inlined, some are inlined automatically. It's a bit chaotic, but us unrelated to the transitions. > > I notice a function... convertToMachineCodeFrame: cogMethod bcpc: Now you're talking :-). The interpreter jits an interpreted method that contains a loop by counting backward branches and jitting by default on the 20th iteration. > > cheers- ben > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/eb2ee2f2/attachment.htm From eliot.miranda at gmail.com Tue Jun 14 21:15:26 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 14 21:15:30 2016 Subject: [Vm-dev] CogVMExecution Flow In-Reply-To: <553ffebf-c503-778e-6efe-c629655af4fa@gmail.com> References: <553ffebf-c503-778e-6efe-c629655af4fa@gmail.com> Message-ID: Hi Chris, On Tue, Jun 14, 2016 at 6:23 AM, Chris Cunnington wrote: > > > a2) "marries" the context in the image that invoked the snapshot > primitive (a stack frame in the stack zone is built for the context, and > the context is changed to become a proxy for that stack frame). > > > When saving to disk, does the stack state of a married frame inside a > CogStackPage bitmap get saved back to the stack of a MethodContext instance? > Yes. And this happens also whenever a stack page must be evacuated to make room for new frames; the state of the frames on that poage are written back to contexts on the heap. > > The CompiledMethod of a MethodContext is not changed in an image. It is > compiled by the StackToRegisterMappingCogit and stored in a frame in the > CogStackPage as a copy. This is not saved when the image is saved to disk. > The machine code is thrown away. It only existed in RAM. > But it /is/ changed. The slot holding the method header pointer is replaced y a pointer to the cogged method. So again when a snapshot is made, the machine code is thrown away and all the compiled methods with machine code are converted back to their normal form. So in an image file there's no remnant of the fact that it was saved on the Cog VM and it can start up just as well on any other kind of VM using the same object representation (except that we only have Interpreter VMs for the V3 object representation). That's fine, because you have the original CompiledMethod untouched with > its bytecodes. > Untouched except for its header which has been copied to a slot in the start of the cogged method, the header having been overwritten by a pointer to the cogged method. > But if in the process of execution the state of a stack under a > MethodContext changes, and it will, and the entire content of the > CogStackPages bitmaps will be nulled out and not saved to disk in the image > as new, extra memory, then does the married frame shiv its content back > into every MethodContext instance on snapshot and quit? > I don't understand. Stack pages hold some number of activations, approximately 40 per page, and there are typically 80 pages. When a fresh page is needed, all the frame state on the oldest page get written to the heap as a chain of contexts. When a snapshot is made, all the pages get written to the heap as contexts, leaving an empty stack zone. So the image file contains vanilla context objects that retain no vestige of them having once existed on a stack page. So again the image file can be resumed on any suitable VM. > The frame has a header that can point to the CompiledMethod with bytecodes > or to a machine code compiled version next door in the CogStackPage bitmap. > But if you copy the stack of a MethodContext into its married frame, then > the stack in the MethodContext is out of date, while the CoInterpreter > spins everything it needs in the separate world in CogStackPages; then, > when you save to disk, are you, as a last effort, saving state back from > every married frame to its original MethodContext instance? > OK, you should read http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ fir the details but... No, there's no out-of-date problem. First, a context that is married has its sender inst var replaced by a pointer to the frame. You can't see this; the VM hides it from you, but /all/ accesses to context objects first check the sender field. If the sender field is a pointer to a frame then the VM computers the state being accessed from the context (its sender, pc, stack pointer, stack contents) from the frame. To avoid the out-of-date problem, when the context is married the receiver and arguments of the method are copied into the context, and these are are read-only. If a widowed context is accessed, then the sender and pc are nil, the stack pointer is the same as the argument count, method, receiver and arguments are unchanged, so there is no out-of-date problem. Where the "out-of-date" problem /usually/ rears its ugly head in Smalltalk VMs is when a block wants to access the outer temporaries of its home context. If the home context could be either a proxy for a frame or a context object, and so to keep the context object's temporaries up-to-date we would have to copy the state of the frame to the context whenever a farm was returned to, which causes slow clunky returns that require complex tricks to optimise. Except that our closure design /doesn't/ access the outer temporaries of the home context. Instead any temporaries that a block and a home context share that each might write to after the block is created are kept in an Array on the heap (a temp var indirection vector) and other values of temps that aren't written to after a block is created are copied into the block, so block activations are completely independent of their home context (and any other block in the method). That's the while point of the closure design. It is why temporaries are represented as they are; it soles the out-of-date problem by making it impossible to /have/ an out-of-date problem. > Chris > HTH _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/264dc7a9/attachment-0001.htm From btc at openinworld.com Wed Jun 15 11:17:10 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 15 11:17:33 2016 Subject: [Vm-dev] comp= ioFindExternalFunctionIn("j_interpret", handle); Message-ID: I was looking at main() in platforms/unix/vm/sqUNixMain.c for my chart, and was just curious what is... comp= ioFindExternalFunctionIn("j_interpret", handle); In the Pharo cog root directory I do... $ find . -type f -exec grep -n j_interpret {} \; and only get a few lines like the same, but no definition. cheers -ben From brasspen at gmail.com Wed Jun 15 11:35:49 2016 From: brasspen at gmail.com (Chris Cunnington) Date: Wed Jun 15 11:35:55 2016 Subject: [Vm-dev] CogVMExecution Flow Message-ID: > ------------------------------------------------------------------------ > Hi Chris, > > On Tue, Jun 14, 2016 at 6:23 AM, Chris Cunnington > > wrote: > > >//>//>/a2) "marries" the context in the image that invoked the snapshot />/primitive (a stack frame in the stack zone is built for the context, and />/the context is changed to become a proxy for that stack frame). />//>//>/When saving to disk, does the stack state of a married frame inside a />/CogStackPage bitmap get saved back to the stack of a MethodContext > instance? />// > Yes. And this happens also whenever a stack page must be evacuated to make > room for new frames; the state of the frames on that poage are written back > to contexts on the heap. > > > >//>/The CompiledMethod of a MethodContext is not changed in an image. It is />/compiled by the StackToRegisterMappingCogit and stored in a frame in the />/CogStackPage as a copy. This is not saved when the image is saved to > disk. />/The machine code is thrown away. It only existed in RAM. />// > But it /is/ changed. The slot holding the method header pointer is > replaced y a pointer to the cogged method. So again when a snapshot is > made, the machine code is thrown away and all the compiled methods with > machine code are converted back to their normal form. > > So in an image file there's no remnant of the fact that it was saved on the > Cog VM and it can start up just as well on any other kind of VM using the > same object representation (except that we only have Interpreter VMs for > the V3 object representation). > > That's fine, because you have the original CompiledMethod untouched with > >/its bytecodes. />// > Untouched except for its header which has been copied to a slot in the > start of the cogged method, the header having been overwritten by a pointer > to the cogged method. > > > >/But if in the process of execution the state of a stack under a />/MethodContext changes, and it will, and the entire content of the />/CogStackPages bitmaps will be nulled out and not saved to disk in the > image />/as new, extra memory, then does the married frame shiv its content back />/into every MethodContext instance on snapshot and quit? />// > I don't understand. Stack pages hold some number of activations, > approximately 40 per page, and there are typically 80 pages. When a fresh > page is needed, all the frame state on the oldest page get written to the > heap as a chain of contexts. When a snapshot is made, all the pages get > written to the heap as contexts, leaving an empty stack zone. So the image > file contains vanilla context objects that retain no vestige of them having > once existed on a stack page. So again the image file can be resumed on > any suitable VM. > > > >/The frame has a header that can point to the CompiledMethod with > bytecodes />/or to a machine code compiled version next door in the CogStackPage > bitmap. />/But if you copy the stack of a MethodContext into its married frame, > then />/the stack in the MethodContext is out of date, while the CoInterpreter />/spins everything it needs in the separate world in CogStackPages; then, />/when you save to disk, are you, as a last effort, saving state back from />/every married frame to its original MethodContext instance? />// > OK, you should read > http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ > fir the details but... Thanks you for looking at these questions. These answers make me better able to read the post again and get a stronger grip on Context/Frame marriages. Chris > No, there's no out-of-date problem. First, a > context that is married has its sender inst var replaced by a pointer to > the frame. You can't see this; the VM hides it from you, but /all/ > accesses to context objects first check the sender field. If the sender > field is a pointer to a frame then the VM computers the state being > accessed from the context (its sender, pc, stack pointer, stack contents) > from the frame. To avoid the out-of-date problem, when the context is > married the receiver and arguments of the method are copied into the > context, and these are are read-only. If a widowed context is accessed, > then the sender and pc are nil, the stack pointer is the same as the > argument count, method, receiver and arguments are unchanged, so there is > no out-of-date problem. > > Where the "out-of-date" problem /usually/ rears its ugly head in Smalltalk > VMs is when a block wants to access the outer temporaries of its home > context. If the home context could be either a proxy for a frame or a > context object, and so to keep the context object's temporaries up-to-date > we would have to copy the state of the frame to the context whenever a farm > was returned to, which causes slow clunky returns that require complex > tricks to optimise. Except that our closure design /doesn't/ access the > outer temporaries of the home context. Instead any temporaries that a > block and a home context share that each might write to after the block is > created are kept in an Array on the heap (a temp var indirection vector) > and other values of temps that aren't written to after a block is created > are copied into the block, so block activations are completely independent > of their home context (and any other block in the method). That's the > while point of the closure design. It is why temporaries are represented > as they are; it soles the out-of-date problem by making it impossible to > /have/ an out-of-date problem. > > > >/Chris />// > HTH > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160614/264dc7a9/attachment-0001.htm > ------------------------------------------------------------------------ > > * Previous message:[Vm-dev] CogVMExecution Flow > > * Next message:[Vm-dev] comp= > ioFindExternalFunctionIn("j_interpret", handle); > > * *Messages sorted by:*[ date ] > [ > thread ] > [ > subject ] > [ > author ] > > > ------------------------------------------------------------------------ > More information about the Vm-dev mailing list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/4283ee7b/attachment.htm From bert at freudenbergs.de Wed Jun 15 11:44:15 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 15 11:44:18 2016 Subject: [Vm-dev] comp= ioFindExternalFunctionIn("j_interpret", handle); In-Reply-To: References: Message-ID: On Wed, Jun 15, 2016 at 1:17 PM, Ben Coman wrote: > comp= ioFindExternalFunctionIn("j_interpret", handle); > This is a remnant of Ian's old JIT experiment, which was implemented as a plugin to the interpreter VM. It predates Cog by several years but was never finished. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/c8c62f57/attachment.htm From btc at openinworld.com Wed Jun 15 11:49:08 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 15 11:49:30 2016 Subject: [Vm-dev] comp= ioFindExternalFunctionIn("j_interpret", handle); In-Reply-To: References: Message-ID: On Wed, Jun 15, 2016 at 7:44 PM, Bert Freudenberg wrote: > > On Wed, Jun 15, 2016 at 1:17 PM, Ben Coman wrote: >> >> comp= ioFindExternalFunctionIn("j_interpret", handle); > > > This is a remnant of Ian's old JIT experiment, which was implemented as a plugin to the interpreter VM. It predates Cog by several years but was never finished. Thanks Bert. So worth a clean up then? (I'm gathering up little mods I might contribute once the git workflow is in place) cheers -ben From bert at freudenbergs.de Wed Jun 15 11:52:53 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 15 11:52:54 2016 Subject: [Vm-dev] CogVMExecution Flow In-Reply-To: References: <553ffebf-c503-778e-6efe-c629655af4fa@gmail.com> Message-ID: On Tue, Jun 14, 2016 at 11:15 PM, Eliot Miranda wrote: > > So in an image file there's no remnant of the fact that it was saved on > the Cog VM and it can start up just as well on any other kind of VM using > the same object representation > ... which is a very nice design. > (except that we only have Interpreter VMs for the V3 object > representation). > Actually, we do. SqueakJS is a pure context interpreter and can run Cog images just fine :) - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/920e1b91/attachment.htm From btc at openinworld.com Wed Jun 15 13:08:44 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 15 13:09:08 2016 Subject: [Vm-dev] de-dup refactoring, readImageFromFile:HeapSize:StartingAt: Message-ID: Just an observation while I was comparing StackIntepreter and CoIntepreter implementations of #readImageFromFile:HeapSize:StartingAt: here.... https://www.diffchecker.com/ojepiwfn These methods are long and have a lot of duplicated code. Would it be worthwhile to... in CoInterpreter>>readImageFromFile:HeapSize:StartingAt: rename variable /cogCodeSize/ to /extraHeapSize/ and then copy the method to... StackInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize ExtraHeapSize: extraHeapSize StartingAt: imageOffset Then the duplication might(?) be eliminated by... StackInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset ^self readImageFromFile: f HeapSize: desiredHeapSize ExtraHeapSize: 0 StartingAt: imageOffset CoInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset | hdrCogCodeSize dataSize | hdrCogCodeSize := (self getShortFromFile: f swap: swapBytes) * 1024. cogCodeSize := desiredCogCodeSize ~= 0 ifTrue: [desiredCogCodeSize] ifFalse: [hdrCogCodeSize = 0 ifTrue: [cogit defaultCogCodeSize] ifFalse: [hdrCogCodeSize]]. ^dataSize := self readImageFromFile: f HeapSize: desiredHeapSize ExtraHeapSize: cogCodeSize StartingAt: imageOffset. self initializeCodeGenerator. ^dataSize ?? cheers -ben From lauraperezcerrato at gmail.com Wed Jun 15 14:28:57 2016 From: lauraperezcerrato at gmail.com (Laura Perez Cerrato) Date: Wed Jun 15 14:29:18 2016 Subject: [Vm-dev] JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: JPEGReadWriter2Plugin.1.cs Type: text/x-csharp Size: 5041 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/d6e30e9a/JPEGReadWriter2Plugin.1.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: BitBltSimulation.1.cs Type: text/x-csharp Size: 3132 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/d6e30e9a/BitBltSimulation.1.bin From eliot.miranda at gmail.com Wed Jun 15 15:18:27 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 15 15:18:33 2016 Subject: [Vm-dev] CogVMExecution Flow In-Reply-To: References: <553ffebf-c503-778e-6efe-c629655af4fa@gmail.com> Message-ID: <37D53BCC-FA5D-4389-A8B2-1DAF40D2578D@gmail.com> Hi Bert, > On Jun 15, 2016, at 4:52 AM, Bert Freudenberg wrote: > >> On Tue, Jun 14, 2016 at 11:15 PM, Eliot Miranda wrote: >> >> So in an image file there's no remnant of the fact that it was saved on the Cog VM and it can start up just as well on any other kind of VM using the same object representation > > ... which is a very nice design. > >> (except that we only have Interpreter VMs for the V3 object representation). > > Actually, we do. SqueakJS is a pure context interpreter and can run Cog images just fine :) What I meant was that we don't have Spur Interpreter VMs. Does SqueakJS run Spur images? If so I'm delighted and stand corrected. _,,,^..^,,,_ (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/9d91ddcd/attachment-0001.htm From eliot.miranda at gmail.com Wed Jun 15 15:24:14 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 15 15:24:19 2016 Subject: [Vm-dev] de-dup refactoring, readImageFromFile:HeapSize:StartingAt: In-Reply-To: References: Message-ID: Hi Ben, if you have energy for this go for it. I'm happy to integrate. For the moment let's stick to change sets. _,,,^..^,,,_ (phone) > On Jun 15, 2016, at 6:08 AM, Ben Coman wrote: > > > Just an observation while I was comparing StackIntepreter and CoIntepreter > implementations of #readImageFromFile:HeapSize:StartingAt: > here.... https://www.diffchecker.com/ojepiwfn > > These methods are long and have a lot of duplicated code. > Would it be worthwhile to... > in CoInterpreter>>readImageFromFile:HeapSize:StartingAt: > rename variable /cogCodeSize/ to /extraHeapSize/ > and then copy the method to... > StackInterpreter>>readImageFromFile: f HeapSize: > desiredHeapSize ExtraHeapSize: extraHeapSize StartingAt: > imageOffset > > > Then the duplication might(?) be eliminated by... > > StackInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize > StartingAt: imageOffset > ^self readImageFromFile: f > HeapSize: desiredHeapSize > ExtraHeapSize: 0 > StartingAt: imageOffset > > > CoInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize > StartingAt: imageOffset > | hdrCogCodeSize dataSize | > hdrCogCodeSize := (self getShortFromFile: f swap: swapBytes) * 1024. > cogCodeSize := desiredCogCodeSize ~= 0 > ifTrue: [desiredCogCodeSize] > ifFalse: > [hdrCogCodeSize = 0 > ifTrue: [cogit defaultCogCodeSize] > ifFalse: [hdrCogCodeSize]]. > ^dataSize := self readImageFromFile: f > HeapSize: desiredHeapSize > ExtraHeapSize: cogCodeSize > StartingAt: imageOffset. > self initializeCodeGenerator. > ^dataSize > > ?? > cheers -ben From commits at source.squeak.org Wed Jun 15 16:36:54 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 15 16:36:55 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1888.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1888.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1888 Author: eem Time: 15 June 2016, 9:34:25.090332 am UUID: 26b2e5b1-5819-45e5-9340-559278c9712c Ancestors: VMMaker.oscog-eem.1887 Integrate changes proposed by Laura Perez Cerrato "Working on JPEGReadWriter2 I noticed that both reading and writing primitives include a sanity check that ensures that the source/destination Smalltalk bitmap has the exact size in bytes needed, instead of checking that its size is at least that needed. Some BitBlt primitives perform the same check, thus not allowing operations with forms with associated bitmaps with a size greater than needed. When performing operations with images, and specially when such images are large in size, actually processing the images takes a small fraction of the time it takes to perform the whole operation, while allocating and deallocating correctly sized bitmaps takes much longer. If one would wish to process a series of similarly sized images (with a definite maximum size), it would be desirable to allocate a bitmap big enough to hold any of them only once and then reuse it, thus avoiding the aforementioned cost. Checking that source and destination bitmaps are big enough instead of checking that their size is exactly that which is expected would allow that optimization. A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied with some experimenting of what would happen if such sanity checks were modified as proposed, has lead me to thinking that these changes would be benefitial. I haven't observed any undesirable side effects (meaning, nothing seems to have blown up :))....." In 1888 in London, Annie Besant organizes the matchgirls strike of 1888, Handel's Israel in Egypt is recorded onto wax cylinder at The Crystal Palace, the earliest known recording of classical music, and the Oaths Act permits the oath of allegiance taken to the Sovereign by Members of Parliament to be affirmed rather than sworn to God, thus confirming the ability of atheists to sit in the House of Commons. =============== Diff against VMMaker.oscog-eem.1887 =============== Item was changed: ----- Method: BitBltSimulation>>loadBitBltDestForm (in category 'interpreter interface') ----- loadBitBltDestForm "Load the dest form for BitBlt. Return false if anything is wrong, true otherwise." | destBitsSize | destBits := interpreterProxy fetchPointer: FormBitsIndex ofObject: destForm. destWidth := interpreterProxy fetchInteger: FormWidthIndex ofObject: destForm. destHeight := interpreterProxy fetchInteger: FormHeightIndex ofObject: destForm. (destWidth >= 0 and: [destHeight >= 0]) ifFalse: [^ false]. destDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: destForm. destMSB := destDepth > 0. destDepth < 0 ifTrue:[destDepth := 0 - destDepth]. "Ignore an integer bits handle for Display in which case the appropriate values will be obtained by calling ioLockSurfaceBits()." (interpreterProxy isIntegerObject: destBits) ifTrue:[ "Query for actual surface dimensions" (self queryDestSurface: (interpreterProxy integerValueOf: destBits)) ifFalse:[^false]. destPPW := 32 // destDepth. destBits := destPitch := 0. ] ifFalse:[ destPPW := 32 // destDepth. destPitch := destWidth + (destPPW-1) // destPPW * 4. destBitsSize := interpreterProxy byteSizeOf: destBits. ((interpreterProxy isWordsOrBytes: destBits) + and: [destBitsSize >= (destPitch * destHeight)]) - and: [destBitsSize = (destPitch * destHeight)]) ifFalse: [^ false]. "Skip header since external bits don't have one" destBits := self oopForPointer: (interpreterProxy firstIndexableField: destBits). ]. ^true! Item was changed: ----- Method: BitBltSimulation>>loadBitBltSourceForm (in category 'interpreter interface') ----- loadBitBltSourceForm "Load the source form for BitBlt. Return false if anything is wrong, true otherwise." | sourceBitsSize | sourceBits := interpreterProxy fetchPointer: FormBitsIndex ofObject: sourceForm. sourceWidth := self fetchIntOrFloat: FormWidthIndex ofObject: sourceForm. sourceHeight := self fetchIntOrFloat: FormHeightIndex ofObject: sourceForm. (sourceWidth >= 0 and: [sourceHeight >= 0]) ifFalse: [^ false]. sourceDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: sourceForm. sourceMSB := sourceDepth > 0. sourceDepth < 0 ifTrue:[sourceDepth := 0 - sourceDepth]. "Ignore an integer bits handle for Display in which case the appropriate values will be obtained by calling ioLockSurfaceBits()." (interpreterProxy isIntegerObject: sourceBits) ifTrue:[ "Query for actual surface dimensions" (self querySourceSurface: (interpreterProxy integerValueOf: sourceBits)) ifFalse:[^false]. sourcePPW := 32 // sourceDepth. sourceBits := sourcePitch := 0. ] ifFalse:[ sourcePPW := 32 // sourceDepth. sourcePitch := sourceWidth + (sourcePPW-1) // sourcePPW * 4. sourceBitsSize := interpreterProxy byteSizeOf: sourceBits. ((interpreterProxy isWordsOrBytes: sourceBits) + and: [sourceBitsSize >= (sourcePitch * sourceHeight)]) - and: [sourceBitsSize = (sourcePitch * sourceHeight)]) ifFalse: [^ false]. "Skip header since external bits don't have one" sourceBits := self oopForPointer: (interpreterProxy firstIndexableField: sourceBits). ]. ^true! Item was changed: ----- Method: JPEGReadWriter2Plugin>>primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr: (in category 'primitives') ----- primJPEGReadImage: aJPEGDecompressStruct fromByteArray: source onForm: form doDithering: ditherFlag errorMgr: aJPEGErrorMgr2Struct | formBitmap formNativeDepth formDepth formWidth formHeight pixelsPerWord formPitch formBitmapSizeInBytes sourceSize formBitmapOOP formComponentBitSize formComponents wordsPerRow | self primitive: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr' parameters: #(ByteArray ByteArray Form Boolean ByteArray). formBitmapOOP := interpreterProxy fetchPointer: 0 ofObject: form. formNativeDepth := interpreterProxy fetchInteger: 3 ofObject: form. formWidth := interpreterProxy fetchInteger: 1 ofObject: form. formHeight := interpreterProxy fetchInteger: 2 ofObject: form. formDepth := formNativeDepth abs. "Various parameter checks" interpreterProxy success: (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(4)) >= (sizeof(struct jpeg_decompress_struct))' inSmalltalk: []). interpreterProxy success: (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))' inSmalltalk: []). interpreterProxy failed ifTrue: [ ^ nil ]. formComponents := formDepth ~= 8 ifTrue: [4] ifFalse: [1]. formComponentBitSize := formDepth ~= 16 ifTrue: [8] ifFalse: [4]. pixelsPerWord := 32 // (formComponents * formComponentBitSize). wordsPerRow := (formWidth + pixelsPerWord - 1) // pixelsPerWord. formPitch := formWidth + (pixelsPerWord-1) // pixelsPerWord * 4. formBitmapSizeInBytes := interpreterProxy byteSizeOf: formBitmapOOP. interpreterProxy success: ((interpreterProxy isWordsOrBytes: formBitmapOOP) and: + [formBitmapSizeInBytes >= (formPitch * formHeight)]). - [formBitmapSizeInBytes = (formPitch * formHeight)]). interpreterProxy failed ifTrue: [^ nil]. sourceSize := interpreterProxy stSizeOf: (interpreterProxy stackValue: 3). interpreterProxy success: (sourceSize ~= 0). interpreterProxy failed ifTrue: [ ^ nil ]. formBitmap := interpreterProxy firstIndexableField: formBitmapOOP. self cCode: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgrReadScanlines( aJPEGDecompressStruct, aJPEGErrorMgr2Struct, source, sourceSize, ditherFlag, formBitmap, pixelsPerWord, wordsPerRow, formNativeDepth);' inSmalltalk: [].! Item was changed: ----- Method: JPEGReadWriter2Plugin>>primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr: (in category 'primitives') ----- primJPEGWriteImage: aJPEGCompressStruct onByteArray: destination form: form quality: quality progressiveJPEG: progressiveFlag errorMgr: aJPEGErrorMgr2Struct | formBitmap formWidth formHeight formNativeDepth formDepth destinationSize pixelsPerWord wordsPerRow formPitch formBitmapSizeInBytes formBitmapOOP formComponentBitSize formComponents | self primitive: 'primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgr' parameters: #(ByteArray ByteArray Form SmallInteger Boolean ByteArray). formBitmapOOP := interpreterProxy fetchPointer: 0 ofObject: form. formWidth := interpreterProxy fetchInteger: 1 ofObject: form. formHeight := interpreterProxy fetchInteger: 2 ofObject: form. formNativeDepth := interpreterProxy fetchInteger: 3 ofObject: form. formDepth := formNativeDepth abs. "Various parameter checks" interpreterProxy success: (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(5)) >= (sizeof(struct jpeg_compress_struct))' inSmalltalk: []). interpreterProxy success: (self cCode: 'interpreterProxy->stSizeOf(interpreterProxy->stackValue(0)) >= (sizeof(struct error_mgr2))' inSmalltalk: []). interpreterProxy failed ifTrue: [ ^ nil ]. formComponents := formDepth ~= 8 ifTrue: [4] ifFalse: [1]. formComponentBitSize := formDepth ~= 16 ifTrue: [8] ifFalse: [4]. pixelsPerWord := 32 // (formComponents * formComponentBitSize). wordsPerRow := (formWidth + pixelsPerWord - 1) // pixelsPerWord. formPitch := wordsPerRow * 4. formBitmapSizeInBytes := interpreterProxy byteSizeOf: formBitmapOOP. interpreterProxy success: ((interpreterProxy isWordsOrBytes: formBitmapOOP) and: + [formBitmapSizeInBytes >= (formPitch * formHeight)]). - [formBitmapSizeInBytes = (formPitch * formHeight)]). interpreterProxy failed ifTrue: [ ^ nil ]. formBitmap := interpreterProxy firstIndexableField: formBitmapOOP. destinationSize := interpreterProxy stSizeOf: (interpreterProxy stackValue: 4). (destinationSize = 0) ifFalse: [ self cCode: ' primJPEGWriteImageonByteArrayformqualityprogressiveJPEGerrorMgrWriteScanlines( formWidth, formHeight, formNativeDepth, formBitmap, aJPEGCompressStruct, aJPEGErrorMgr2Struct, quality, progressiveFlag, pixelsPerWord, wordsPerRow, destination, &destinationSize);' inSmalltalk: []]. ^(self cCode: 'destinationSize' inSmalltalk: [0]) asOop: SmallInteger! From eliot.miranda at gmail.com Wed Jun 15 16:37:05 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 15 16:37:09 2016 Subject: [Vm-dev] JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps In-Reply-To: References: Message-ID: Hi David, Hi All, I'd like Laura to be added as a committer to source.squeak.org/VMMaker. On Wed, Jun 15, 2016 at 7:28 AM, Laura Perez Cerrato < lauraperezcerrato@gmail.com> wrote: > > Hello everyone, > > Working on JPEGReadWriter2 I noticed that both reading and writing > primitives include a sanity check that ensures that the source/destination > Smalltalk bitmap has the exact size in bytes needed, instead of checking > that its size is at least that needed. Some BitBlt primitives perform the > same check, thus not allowing operations with forms with associated bitmaps > with a size greater than needed. > > When performing operations with images, and specially when such images are > large in size, actually processing the images takes a small fraction of the > time it takes to perform the whole operation, while allocating and > deallocating correctly sized bitmaps takes much longer. If one would wish > to process a series of similarly sized images (with a definite maximum > size), it would be desirable to allocate a bitmap big enough to hold any of > them only once and then reuse it, thus avoiding the aforementioned cost. > Checking that source and destination bitmaps are big enough instead of > checking that their size is exactly that which is expected would allow that > optimization. > > A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied with > some experimenting of what would happen if such sanity checks were modified > as proposed, has lead me to thinking that these changes would be > benefitial. I haven't observed any undesirable side effects (meaning, > nothing seems to have blown up :)). However, I'm inexperienced in working > with the VM, so it's rather expectable that I miss something :) Your input > on the topic would be extremely appreciated. > > The attached changesets contain the proposed set of changes. > > Cheers! > > -Laura Perez Cerrato > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/9de6802a/attachment.htm From johnmci at smalltalkconsulting.com Wed Jun 15 16:48:03 2016 From: johnmci at smalltalkconsulting.com (John McIntosh) Date: Wed Jun 15 16:48:10 2016 Subject: [Vm-dev] JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps In-Reply-To: References: Message-ID: <4CDB7A7F-AF96-42C6-B8EB-DF7C4BFC9614@smalltalkconsulting.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2647 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/5f09643f/smime-0001.bin From bert at freudenbergs.de Wed Jun 15 16:49:20 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 15 16:49:23 2016 Subject: [Vm-dev] CogVMExecution Flow In-Reply-To: <37D53BCC-FA5D-4389-A8B2-1DAF40D2578D@gmail.com> References: <553ffebf-c503-778e-6efe-c629655af4fa@gmail.com> <37D53BCC-FA5D-4389-A8B2-1DAF40D2578D@gmail.com> Message-ID: On Wed, Jun 15, 2016 at 5:18 PM, Eliot Miranda wrote: > > Hi Bert, > > On Jun 15, 2016, at 4:52 AM, Bert Freudenberg > wrote: > > On Tue, Jun 14, 2016 at 11:15 PM, Eliot Miranda > wrote: > >> >> So in an image file there's no remnant of the fact that it was saved on >> the Cog VM and it can start up just as well on any other kind of VM using >> the same object representation >> > > ... which is a very nice design. > > >> (except that we only have Interpreter VMs for the V3 object >> representation). >> > > Actually, we do. SqueakJS is a pure context interpreter and can run Cog > images just fine :) > > > What I meant was that we don't have Spur Interpreter VMs. > Right. The discussion was about the machine code frames and I was just confirming that the stored image doesn't have those. > Does SqueakJS run Spur images? If so I'm delighted and stand corrected. > No Spur image support yet. I need to find a free minute ... - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/c71c853e/attachment.htm From eliot.miranda at gmail.com Wed Jun 15 17:26:09 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 15 17:26:12 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC Message-ID: Hi all, we are all finished importing the VM repository to Github, migrating the scripts, and setting up automatic builds and hosting of binaries. We want to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and Fabio will merge any remaining commits on the SVN repository between now and that time and any further development will take place on Github. If possible, you may refrain from committing to SVN, as this will mean less work for Tim and Fabio. The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch is the new default branch and is still called Cog, this is the main focus of development. The old trunk branch has been renamed to "oldTrunk". The master branch will track the Cog branch and will be the repository integrated into for releases. To get started, please refer to the updated README that is shown on the Github page. _,,,^..^,,,_ best, Eliot, Tim & Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/38fe897d/attachment.htm From estebanlm at gmail.com Wed Jun 15 17:27:47 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Wed Jun 15 17:27:54 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: <935F476F-0215-41A8-89D2-EEA2A1A23081@gmail.com> whoohoo! thank you very much :) Esteban > On 15 Jun 2016, at 19:26, Eliot Miranda wrote: > > Hi all, > > we are all finished importing the VM repository to Github, migrating the scripts, and setting up automatic builds and hosting of binaries. We want to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and Fabio will merge any remaining commits on the SVN repository between now and that time and any further development will take place on Github. If possible, you may refrain from committing to SVN, as this will mean less work for Tim and Fabio. > > The new repository is at https://github.com/OpenSmalltalk/vm . The Cog branch is the new default branch and is still called Cog, this is the main focus of development. The old trunk branch has been renamed to "oldTrunk". The master branch will track the Cog branch and will be the repository integrated into for releases. > > To get started, please refer to the updated README that is shown on the Github page. > > _,,,^..^,,,_ > best, Eliot, Tim & Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/dcb67187/attachment.htm From tudor at tudorgirba.com Wed Jun 15 18:30:58 2016 From: tudor at tudorgirba.com (Tudor Girba) Date: Wed Jun 15 18:31:07 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: <935F476F-0215-41A8-89D2-EEA2A1A23081@gmail.com> References: <935F476F-0215-41A8-89D2-EEA2A1A23081@gmail.com> Message-ID: <533C2B81-99CE-4E0F-A2A3-6DA63EAB706C@tudorgirba.com> Thanks a lot! Doru > On Jun 15, 2016, at 7:27 PM, Esteban Lorenzano wrote: > > whoohoo! > > thank you very much :) > > Esteban > >> On 15 Jun 2016, at 19:26, Eliot Miranda wrote: >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the scripts, and setting up automatic builds and hosting of binaries. We want to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and Fabio will merge any remaining commits on the SVN repository between now and that time and any further development will take place on Github. If possible, you may refrain from committing to SVN, as this will mean less work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch is the new default branch and is still called Cog, this is the main focus of development. The old trunk branch has been renamed to "oldTrunk". The master branch will track the Cog branch and will be the repository integrated into for releases. >> >> To get started, please refer to the updated README that is shown on the Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow." From lewis at mail.msen.com Wed Jun 15 18:56:11 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Jun 15 18:56:13 2016 Subject: [Vm-dev] JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps In-Reply-To: References: Message-ID: <4464.136.1.1.166.1466016971.squirrel@webmail.msen.com> Done. Thanks Laura! Dave > Hi David, Hi All, > > I'd like Laura to be added as a committer to source.squeak.org/VMMaker. > > On Wed, Jun 15, 2016 at 7:28 AM, Laura Perez Cerrato < > lauraperezcerrato@gmail.com> wrote: > >> >> Hello everyone, >> >> Working on JPEGReadWriter2 I noticed that both reading and writing >> primitives include a sanity check that ensures that the >> source/destination >> Smalltalk bitmap has the exact size in bytes needed, instead of checking >> that its size is at least that needed. Some BitBlt primitives perform >> the >> same check, thus not allowing operations with forms with associated >> bitmaps >> with a size greater than needed. >> >> When performing operations with images, and specially when such images >> are >> large in size, actually processing the images takes a small fraction of >> the >> time it takes to perform the whole operation, while allocating and >> deallocating correctly sized bitmaps takes much longer. If one would >> wish >> to process a series of similarly sized images (with a definite maximum >> size), it would be desirable to allocate a bitmap big enough to hold any >> of >> them only once and then reuse it, thus avoiding the aforementioned cost. >> Checking that source and destination bitmaps are big enough instead of >> checking that their size is exactly that which is expected would allow >> that >> optimization. >> >> A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied >> with >> some experimenting of what would happen if such sanity checks were >> modified >> as proposed, has lead me to thinking that these changes would be >> benefitial. I haven't observed any undesirable side effects (meaning, >> nothing seems to have blown up :)). However, I'm inexperienced in >> working >> with the VM, so it's rather expectable that I miss something :) Your >> input >> on the topic would be extremely appreciated. >> >> The attached changesets contain the proposed set of changes. >> >> Cheers! >> >> -Laura Perez Cerrato >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > From lauraperezcerrato at gmail.com Wed Jun 15 18:57:29 2016 From: lauraperezcerrato at gmail.com (Laura Perez Cerrato) Date: Wed Jun 15 18:57:50 2016 Subject: [Vm-dev] JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps In-Reply-To: <4464.136.1.1.166.1466016971.squirrel@webmail.msen.com> References: <4464.136.1.1.166.1466016971.squirrel@webmail.msen.com> Message-ID: Thanks to you all :) Should I commit those? -Laura Perez Cerrato On 15 June 2016 at 15:56, David T. Lewis wrote: > Done. > > Thanks Laura! > > Dave > > > > Hi David, Hi All, > > > > I'd like Laura to be added as a committer to > source.squeak.org/VMMaker. > > > > On Wed, Jun 15, 2016 at 7:28 AM, Laura Perez Cerrato < > > lauraperezcerrato@gmail.com> wrote: > > > >> > >> Hello everyone, > >> > >> Working on JPEGReadWriter2 I noticed that both reading and writing > >> primitives include a sanity check that ensures that the > >> source/destination > >> Smalltalk bitmap has the exact size in bytes needed, instead of checking > >> that its size is at least that needed. Some BitBlt primitives perform > >> the > >> same check, thus not allowing operations with forms with associated > >> bitmaps > >> with a size greater than needed. > >> > >> When performing operations with images, and specially when such images > >> are > >> large in size, actually processing the images takes a small fraction of > >> the > >> time it takes to perform the whole operation, while allocating and > >> deallocating correctly sized bitmaps takes much longer. If one would > >> wish > >> to process a series of similarly sized images (with a definite maximum > >> size), it would be desirable to allocate a bitmap big enough to hold any > >> of > >> them only once and then reuse it, thus avoiding the aforementioned cost. > >> Checking that source and destination bitmaps are big enough instead of > >> checking that their size is exactly that which is expected would allow > >> that > >> optimization. > >> > >> A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied > >> with > >> some experimenting of what would happen if such sanity checks were > >> modified > >> as proposed, has lead me to thinking that these changes would be > >> benefitial. I haven't observed any undesirable side effects (meaning, > >> nothing seems to have blown up :)). However, I'm inexperienced in > >> working > >> with the VM, so it's rather expectable that I miss something :) Your > >> input > >> on the topic would be extremely appreciated. > >> > >> The attached changesets contain the proposed set of changes. > >> > >> Cheers! > >> > >> -Laura Perez Cerrato > >> > >> > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/3a2d74e0/attachment.htm From eliot.miranda at gmail.com Wed Jun 15 19:06:54 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 15 19:06:57 2016 Subject: [Vm-dev] JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps In-Reply-To: References: <4464.136.1.1.166.1466016971.squirrel@webmail.msen.com> Message-ID: On Wed, Jun 15, 2016 at 11:57 AM, Laura Perez Cerrato < lauraperezcerrato@gmail.com> wrote: > > Thanks to you all :) Should I commit those? > I did already I think. But next time it'll be up to you ;-) > > -Laura Perez Cerrato > > On 15 June 2016 at 15:56, David T. Lewis wrote: > >> Done. >> >> Thanks Laura! >> >> Dave >> >> >> > Hi David, Hi All, >> > >> > I'd like Laura to be added as a committer to >> source.squeak.org/VMMaker. >> > >> > On Wed, Jun 15, 2016 at 7:28 AM, Laura Perez Cerrato < >> > lauraperezcerrato@gmail.com> wrote: >> > >> >> >> >> Hello everyone, >> >> >> >> Working on JPEGReadWriter2 I noticed that both reading and writing >> >> primitives include a sanity check that ensures that the >> >> source/destination >> >> Smalltalk bitmap has the exact size in bytes needed, instead of >> checking >> >> that its size is at least that needed. Some BitBlt primitives perform >> >> the >> >> same check, thus not allowing operations with forms with associated >> >> bitmaps >> >> with a size greater than needed. >> >> >> >> When performing operations with images, and specially when such images >> >> are >> >> large in size, actually processing the images takes a small fraction of >> >> the >> >> time it takes to perform the whole operation, while allocating and >> >> deallocating correctly sized bitmaps takes much longer. If one would >> >> wish >> >> to process a series of similarly sized images (with a definite maximum >> >> size), it would be desirable to allocate a bitmap big enough to hold >> any >> >> of >> >> them only once and then reuse it, thus avoiding the aforementioned >> cost. >> >> Checking that source and destination bitmaps are big enough instead of >> >> checking that their size is exactly that which is expected would allow >> >> that >> >> optimization. >> >> >> >> A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied >> >> with >> >> some experimenting of what would happen if such sanity checks were >> >> modified >> >> as proposed, has lead me to thinking that these changes would be >> >> benefitial. I haven't observed any undesirable side effects (meaning, >> >> nothing seems to have blown up :)). However, I'm inexperienced in >> >> working >> >> with the VM, so it's rather expectable that I miss something :) Your >> >> input >> >> on the topic would be extremely appreciated. >> >> >> >> The attached changesets contain the proposed set of changes. >> >> >> >> Cheers! >> >> >> >> -Laura Perez Cerrato >> >> >> >> >> > >> > >> > -- >> > _,,,^..^,,,_ >> > best, Eliot >> > >> >> >> > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160615/09d5014c/attachment.htm From commits at source.squeak.org Wed Jun 15 21:40:25 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 15 21:40:25 2016 Subject: [Vm-dev] VM Maker: BytecodeSets.spur-eem.54.mcz Message-ID: Eliot Miranda uploaded a new version of BytecodeSets to project VM Maker: http://source.squeak.org/VMMaker/BytecodeSets.spur-eem.54.mcz ==================== Summary ==================== Name: BytecodeSets.spur-eem.54 Author: eem Time: 15 June 2016, 2:39:35.207556 pm UUID: ff813806-d8f8-473b-bacc-b0bc62f10c40 Ancestors: BytecodeSets.spur-cb.53 In Squeak the compiler checks for exceeding the number of available literals at compile time. So encoders must implement maxIndexableLiterals. The default form the Blue Book bytecode set is only 63. EncoderForV3 answers 256. Both NewspeakV4 and SistaV1 should answer 65536. =============== Diff against BytecodeSets.spur-cb.53 =============== Item was added: + ----- Method: EncoderForNewsqueakV4>>maxIndexableLiterals (in category 'accessing') ----- + maxIndexableLiterals + "Answer the maximum number of literals supported by the receiver's + bytecode set." + ^65536! Item was added: + ----- Method: EncoderForSistaV1>>maxIndexableLiterals (in category 'accessing') ----- + maxIndexableLiterals + "Answer the maximum number of literals supported by the receiver's + bytecode set." + ^65536! From btc at openinworld.com Wed Jun 15 23:19:27 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 15 23:19:50 2016 Subject: [Vm-dev] de-dup refactoring, readImageFromFile:HeapSize:StartingAt: In-Reply-To: References: Message-ID: On Wed, Jun 15, 2016 at 11:24 PM, Eliot Miranda wrote: > > Hi Ben, > > if you have energy for this go for it. I'm happy to integrate. Okay. I'll have a go. cheers -ben > For the moment let's stick to change sets. > > _,,,^..^,,,_ (phone) > >> On Jun 15, 2016, at 6:08 AM, Ben Coman wrote: >> >> >> Just an observation while I was comparing StackIntepreter and CoIntepreter >> implementations of #readImageFromFile:HeapSize:StartingAt: >> here.... https://www.diffchecker.com/ojepiwfn >> >> These methods are long and have a lot of duplicated code. >> Would it be worthwhile to... >> in CoInterpreter>>readImageFromFile:HeapSize:StartingAt: >> rename variable /cogCodeSize/ to /extraHeapSize/ >> and then copy the method to... >> StackInterpreter>>readImageFromFile: f HeapSize: >> desiredHeapSize ExtraHeapSize: extraHeapSize StartingAt: >> imageOffset >> >> >> Then the duplication might(?) be eliminated by... >> >> StackInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize >> StartingAt: imageOffset >> ^self readImageFromFile: f >> HeapSize: desiredHeapSize >> ExtraHeapSize: 0 >> StartingAt: imageOffset >> >> >> CoInterpreter>>readImageFromFile: f HeapSize: desiredHeapSize >> StartingAt: imageOffset >> | hdrCogCodeSize dataSize | >> hdrCogCodeSize := (self getShortFromFile: f swap: swapBytes) * 1024. >> cogCodeSize := desiredCogCodeSize ~= 0 >> ifTrue: [desiredCogCodeSize] >> ifFalse: >> [hdrCogCodeSize = 0 >> ifTrue: [cogit defaultCogCodeSize] >> ifFalse: [hdrCogCodeSize]]. >> ^dataSize := self readImageFromFile: f >> HeapSize: desiredHeapSize >> ExtraHeapSize: cogCodeSize >> StartingAt: imageOffset. >> self initializeCodeGenerator. >> ^dataSize >> >> ?? >> cheers -ben From bera.clement at gmail.com Thu Jun 16 06:10:24 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Thu Jun 16 06:10:47 2016 Subject: [Vm-dev] Methods with more than 15 args sketch Message-ID: Hi everyone. It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks. I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change. The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments. The normal calling convention in the Smalltalk bytecode is as follows: push receiver push arg 1 push arg 2 .... push arg N send selector N is limited to 15 arguments due compiled method header & bytecode encoding. In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors. The convention will look like that: push receiver push arg 1 push arg 2 .... push arg N popIntoArray N-15 values send selector The compilation of a method with more than 15 arguments is then changed: - As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg. - the compiled method header is still marked with 15 arguments In addition one needs to change CompiledMethod to: - allow larger frames (instead of 56 we could allow 128 or 256) - have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon. And to change the fall-back of a couple primitives, such as: - Object>>perform: withArgs: - Object>>perform: withArgs:inSupedClass: - BlockClosure>>valueWithArgs: This design would allow methods to up to 141 arguments. What do you guys think ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/f0210c65/attachment-0001.htm From bera.clement at gmail.com Thu Jun 16 06:12:59 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Thu Jun 16 06:13:20 2016 Subject: [Vm-dev] VM Maker: BytecodeSets.spur-eem.54.mcz In-Reply-To: <5761cb4b.5041370a.7754a.321dSMTPIN_ADDED_MISSING@mx.google.com> References: <5761cb4b.5041370a.7754a.321dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Wed, Jun 15, 2016 at 11:40 PM, wrote: > > Eliot Miranda uploaded a new version of BytecodeSets to project VM Maker: > http://source.squeak.org/VMMaker/BytecodeSets.spur-eem.54.mcz > > ==================== Summary ==================== > > Name: BytecodeSets.spur-eem.54 > Author: eem > Time: 15 June 2016, 2:39:35.207556 pm > UUID: ff813806-d8f8-473b-bacc-b0bc62f10c40 > Ancestors: BytecodeSets.spur-cb.53 > > In Squeak the compiler checks for exceeding the number of available > literals at compile time. So encoders must implement > maxIndexableLiterals. The default form the Blue Book bytecode set is only > 63. EncoderForV3 answers 256. Both NewspeakV4 and SistaV1 should answer > 65536. > In SistaV1 there's a bit to mark if the method has counters or not. So 32.000. > > =============== Diff against BytecodeSets.spur-cb.53 =============== > > Item was added: > + ----- Method: EncoderForNewsqueakV4>>maxIndexableLiterals (in category > 'accessing') ----- > + maxIndexableLiterals > + "Answer the maximum number of literals supported by the receiver's > + bytecode set." > + ^65536! > > Item was added: > + ----- Method: EncoderForSistaV1>>maxIndexableLiterals (in category > 'accessing') ----- > + maxIndexableLiterals > + "Answer the maximum number of literals supported by the receiver's > + bytecode set." > + ^65536! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/058a95a2/attachment.htm From nicolas.cellier.aka.nice at gmail.com Thu Jun 16 06:36:57 2016 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Thu Jun 16 06:37:00 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: Message-ID: For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments. This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru. I don't know if it's the case for other 3rd party code, but it would be worth inquiring... https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html http://bugs.squeak.org/view.php?id=2918 The (Old) Compiler code is at http://www.squeaksource.com/Smallapack.html Smallapack-Compiler.trunk-nice.6.mcz 2016-06-16 8:10 GMT+02:00 Cl?ment Bera : > > Hi everyone. > > It seems that some people are struggling with the fact that methods in > Pharo (and other Smalltalk on top of Cog) cannot have more than 15 > arguments. Typically the problem arises while generating Smalltalk code or > porting code from other Smalltalks. > > I have been thinking for a while about this problem. In this mail I write > a small sketch to solve it, it's something that could go to production very > quickly and that requires almost only image-side changes. Eliot has already > reviewed and approved the sketch, but I''d like to know if someone is > strongly against that change. > > The generic idea is to change the send calling convention at the bytecode > level, using a temp vector to pass overflowing arguments. > > The normal calling convention in the Smalltalk bytecode is as follows: > > push receiver > push arg 1 > push arg 2 > .... > push arg N > send selector > > N is limited to 15 arguments due compiled method header & bytecode > encoding. > > In the new design, if the send has less than 15 arguments, the calling > convention remains the same. Over 15 arguments, the overflowing arguments > are passed in a temp vector in a similar way to the closure temp vectors. > > The convention will look like that: > > push receiver > push arg 1 > push arg 2 > .... > push arg N > popIntoArray N-15 values > send selector > > The compilation of a method with more than 15 arguments is then changed: > - As for temp vectors, the 15th arg array can't be become or read-only, > hence the temp vector instructions can be used to access the overflowing > arguments through the 15th arg. > - the compiled method header is still marked with 15 arguments > > In addition one needs to change CompiledMethod to: > - allow larger frames (instead of 56 we could allow 128 or 256) > - have numArgs answering the right number of methods with many arguments. > I think the number of arguments could be in the additional method state in > this case as it is very uncommon. > > And to change the fall-back of a couple primitives, such as: > - Object>>perform: withArgs: > - Object>>perform: withArgs:inSupedClass: > - BlockClosure>>valueWithArgs: > > This design would allow methods to up to 141 arguments. > > What do you guys think ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/76f0e987/attachment.htm From eliot.miranda at gmail.com Thu Jun 16 07:17:19 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 07:17:23 2016 Subject: [Vm-dev] VM Maker: BytecodeSets.spur-eem.54.mcz In-Reply-To: References: <5761cb4b.5041370a.7754a.321dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <3749862E-2CF7-44CC-869C-97D16AB42CF7@gmail.com> Hi Cl?ment, _,,,^..^,,,_ (phone) > On Jun 15, 2016, at 11:12 PM, Cl?ment Bera wrote: > > > >> On Wed, Jun 15, 2016 at 11:40 PM, wrote: >> >> Eliot Miranda uploaded a new version of BytecodeSets to project VM Maker: >> http://source.squeak.org/VMMaker/BytecodeSets.spur-eem.54.mcz >> >> ==================== Summary ==================== >> >> Name: BytecodeSets.spur-eem.54 >> Author: eem >> Time: 15 June 2016, 2:39:35.207556 pm >> UUID: ff813806-d8f8-473b-bacc-b0bc62f10c40 >> Ancestors: BytecodeSets.spur-cb.53 >> >> In Squeak the compiler checks for exceeding the number of available literals at compile time. So encoders must implement maxIndexableLiterals. The default form the Blue Book bytecode set is only 63. EncoderForV3 answers 256. Both NewspeakV4 and SistaV1 should answer 65536. > > In SistaV1 there's a bit to mark if the method has counters or not. So 32.000. I'm on my phone so I can't show you the code but the compiler uses encoder maxIndexableLiterals min: method maxIndexableLiterals and so method maxIndexableLiterals answers 32,767. The limitation in the bytecode set is indeed 64k, but the limit in the compiled method header is 32k. >> >> =============== Diff against BytecodeSets.spur-cb.53 =============== >> >> Item was added: >> + ----- Method: EncoderForNewsqueakV4>>maxIndexableLiterals (in category 'accessing') ----- >> + maxIndexableLiterals >> + "Answer the maximum number of literals supported by the receiver's >> + bytecode set." >> + ^65536! >> >> Item was added: >> + ----- Method: EncoderForSistaV1>>maxIndexableLiterals (in category 'accessing') ----- >> + maxIndexableLiterals >> + "Answer the maximum number of literals supported by the receiver's >> + bytecode set." >> + ^65536! _,,,^..^,,,_ (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/7cbb1511/attachment.htm From bera.clement at gmail.com Thu Jun 16 08:21:00 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Thu Jun 16 08:21:21 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: Message-ID: Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ? I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ? On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote: > > For my personal use which was essentially calling FFI with more than 15 > args, i used a single array for all arguments. > This was more simple, and no optimization of the first 15 was needed since > most of the time the long method is just a wrapper that passes parameters > thru. > I don't know if it's the case for other 3rd party code, but it would be > worth inquiring... > > > https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html > http://bugs.squeak.org/view.php?id=2918 > > The (Old) Compiler code is at > > http://www.squeaksource.com/Smallapack.html > Smallapack-Compiler.trunk-nice.6.mcz > > > > > 2016-06-16 8:10 GMT+02:00 Cl?ment Bera : > >> >> Hi everyone. >> >> It seems that some people are struggling with the fact that methods in >> Pharo (and other Smalltalk on top of Cog) cannot have more than 15 >> arguments. Typically the problem arises while generating Smalltalk code or >> porting code from other Smalltalks. >> >> I have been thinking for a while about this problem. In this mail I write >> a small sketch to solve it, it's something that could go to production very >> quickly and that requires almost only image-side changes. Eliot has already >> reviewed and approved the sketch, but I''d like to know if someone is >> strongly against that change. >> >> The generic idea is to change the send calling convention at the bytecode >> level, using a temp vector to pass overflowing arguments. >> >> The normal calling convention in the Smalltalk bytecode is as follows: >> >> push receiver >> push arg 1 >> push arg 2 >> .... >> push arg N >> send selector >> >> N is limited to 15 arguments due compiled method header & bytecode >> encoding. >> >> In the new design, if the send has less than 15 arguments, the calling >> convention remains the same. Over 15 arguments, the overflowing arguments >> are passed in a temp vector in a similar way to the closure temp vectors. >> >> The convention will look like that: >> >> push receiver >> push arg 1 >> push arg 2 >> .... >> push arg N >> popIntoArray N-15 values >> send selector >> >> The compilation of a method with more than 15 arguments is then changed: >> - As for temp vectors, the 15th arg array can't be become or read-only, >> hence the temp vector instructions can be used to access the overflowing >> arguments through the 15th arg. >> - the compiled method header is still marked with 15 arguments >> >> In addition one needs to change CompiledMethod to: >> - allow larger frames (instead of 56 we could allow 128 or 256) >> - have numArgs answering the right number of methods with many arguments. >> I think the number of arguments could be in the additional method state in >> this case as it is very uncommon. >> >> And to change the fall-back of a couple primitives, such as: >> - Object>>perform: withArgs: >> - Object>>perform: withArgs:inSupedClass: >> - BlockClosure>>valueWithArgs: >> >> This design would allow methods to up to 141 arguments. >> >> What do you guys think ? >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/03d98a41/attachment-0001.htm From timfelgentreff at gmail.com Thu Jun 16 08:24:12 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Thu Jun 16 08:24:34 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Hi all, as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was migrated to GitHub. Automatic builds are running ( https://ci.appveyor.com/project/timfel/vm/branch/Cog, https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded ( https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). Right now we have enabled all platform, object memory and bytecode set combinations that I found build scripts for - most work, but OS X 64-bit Sista is failing right now (32-bit works). At some point we'll have to decide which combinations to put into the CI config as "allowed failures" to get a green badge :) Another thing for those not familiar with Git: Right now the entire repository is 360MB, including all history. Most of that is old images that were at one point committed to SVN and that have been pulled into the repository. We could clean those out (removing them from the history) to make the repository smaller, but I felt ~400MB is still ok (albeit technically over the Github quota. We'll see of they complain). I would like to ask everyone to stop committing large binary files into the repository, however. Git is simply not very suited to dealing with binaries. If there is a need for that, Github has support for git-lfs, which offers 1GB of free storage with a 1GB bandwith limit per month. If we need more, we can look at the different billing levels. If you're familiar with Git, the only new thing to watch out for is the updateSCSSVersions script as described in the README. It's not relevant for the CI, but your own binaries will only show correct versions if this script runs at appropriate times. If you are not familiar with Git and don't care, there are scripts for committing that should take care of everything as described in the README. Again, let us know if anything doesn't work. The only difference vs SVN to watch out for for you will be that the old scripts/svnci would commit your changes to the server, whereas the scripts/gitci script only commits them locally. You'll have to run `git pull` and `git push` to get them up to the server. If you have any questions regarding the repository setup please don't hesitate to ask. You shouldn't be able to break anything, since we've disabled force pushes to both master and Cog (and thus any chance of destroying history). Thanks, Tim & Fabio On 15 June 2016 at 19:26, Eliot Miranda wrote: > > Hi all, > > we are all finished importing the VM repository to Github, migrating the > scripts, and setting up automatic builds and hosting of binaries. We > want to switch over from SVN tomorrow morning at 7am UTC. At that point, > Tim and Fabio will merge any remaining commits on the SVN repository between > now and that time and any further development will take place on Github. > If possible, you may refrain from committing to SVN, as this will mean > less work for Tim and Fabio. > > The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch > is the new default branch and is still called Cog, this is the main focus > of development. The old trunk branch has been renamed to "oldTrunk". The > master branch will track the Cog branch and will be the repository > integrated into for releases. > > To get started, please refer to the updated README > that is shown on the > Github page. > > _,,,^..^,,,_ > best, Eliot, Tim & Fabio > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/d9b776e8/attachment.htm From serge.stinckwich at gmail.com Thu Jun 16 09:10:38 2016 From: serge.stinckwich at gmail.com (Serge Stinckwich) Date: Thu Jun 16 09:11:20 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff wrote: > Hi all, Very impressive work, Tim&Fabio ! The power of full-automation ! > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > migrated to GitHub. Automatic builds are running > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). About uploading binary artifacts, this is something I asked and this nice that Fabio make it work :-) Apparently there is some problems with some artifacts that have a double .zip extension. > Right now we have enabled all platform, object memory and bytecode set > combinations that I found build scripts for - most work, but OS X 64-bit > Sista is failing right now (32-bit works). At some point we'll have to > decide which combinations to put into the CI config as "allowed failures" to > get a green badge :) > > Another thing for those not familiar with Git: Right now the entire > repository is 360MB, including all history. Most of that is old images that > were at one point committed to SVN and that have been pulled into the > repository. We could clean those out (removing them from the history) to > make the repository smaller, but I felt ~400MB is still ok (albeit > technically over the Github quota. We'll see of they complain). I would like > to ask everyone to stop committing large binary files into the repository, > however. Git is simply not very suited to dealing with binaries. If there is > a need for that, Github has support for git-lfs, which offers 1GB of free > storage with a 1GB bandwith limit per month. If we need more, we can look at > the different billing levels. > > If you're familiar with Git, the only new thing to watch out for is the > updateSCSSVersions script as described in the README. It's not relevant for > the CI, but your own binaries will only show correct versions if this script > runs at appropriate times. > > If you are not familiar with Git and don't care, there are scripts for > committing that should take care of everything as described in the README. > Again, let us know if anything doesn't work. The only difference vs SVN to > watch out for for you will be that the old scripts/svnci would commit your > changes to the server, whereas the scripts/gitci script only commits them > locally. You'll have to run `git pull` and `git push` to get them up to the > server. > > If you have any questions regarding the repository setup please don't > hesitate to ask. You shouldn't be able to break anything, since we've > disabled force pushes to both master and Cog (and thus any chance of > destroying history). What is favorite way of contributing for people outside the vm team ? pull-requests ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ From bert at freudenbergs.de Thu Jun 16 12:11:09 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Jun 16 12:11:12 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become Message-ID: I'm reading a 20MB text file. At some point it tries to convert the 20 MB ByteString into an 80 MB WideString using forward become. This fails resulting in an endless loop. The primitive failure code for elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' and it tries again after growing: ec == #'insufficient object memory' ifTrue: [Smalltalk garbageCollect < 1048576 ifTrue: [Smalltalk growMemoryByAtLeast: 1048576]. ^self elementsForwardIdentityTo: otherArray]. but the growMemoryByAtLeast: does not actually grow the memory: {Smalltalk garbageCollect. Smalltalk growMemoryByAtLeast: 1048576. Smalltalk garbageCollect.} ==> #(58576608 16777216 58576608) 58 MB are not enough, but it doesn't grow any further. The question is, why does it try to allocate a new object at all? The WideString exists already. I thought Spur would simply install a forwarder? To reproduce, execute (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) You probably want to follow that with a user interrupt (Cmd-period). This happens using the latest Spur VM from github (r201606160944) - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/432f74c0/attachment.htm From marianopeck at gmail.com Thu Jun 16 12:37:20 2016 From: marianopeck at gmail.com (Mariano Martinez Peck) Date: Thu Jun 16 12:37:29 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: This is very very cool. Thanks to all the people involved, and thanks Eliot for listening the "community's wishes". I honestly thought it would take much longer or never happened. I am so glad to have been proven wrong! Best, On Thu, Jun 16, 2016 at 5:24 AM, Tim Felgentreff wrote: > > Hi all, > > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > migrated to GitHub. Automatic builds are running ( > https://ci.appveyor.com/project/timfel/vm/branch/Cog, > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). > > Right now we have enabled all platform, object memory and bytecode set > combinations that I found build scripts for - most work, but OS X 64-bit > Sista is failing right now (32-bit works). At some point we'll have to > decide which combinations to put into the CI config as "allowed failures" > to get a green badge :) > > Another thing for those not familiar with Git: Right now the entire > repository is 360MB, including all history. Most of that is old images that > were at one point committed to SVN and that have been pulled into the > repository. We could clean those out (removing them from the history) to > make the repository smaller, but I felt ~400MB is still ok (albeit > technically over the Github quota. We'll see of they complain). I would > like to ask everyone to stop committing large binary files into the > repository, however. Git is simply not very suited to dealing with > binaries. If there is a need for that, Github has support for git-lfs, > which offers 1GB of free storage with a 1GB bandwith limit per month. If we > need more, we can look at the different billing levels. > > If you're familiar with Git, the only new thing to watch out for is the > updateSCSSVersions script as described in the README. It's not relevant for > the CI, but your own binaries will only show correct versions if this > script runs at appropriate times. > > If you are not familiar with Git and don't care, there are scripts for > committing that should take care of everything as described in the README. > Again, let us know if anything doesn't work. The only difference vs SVN to > watch out for for you will be that the old scripts/svnci would commit your > changes to the server, whereas the scripts/gitci script only commits them > locally. You'll have to run `git pull` and `git push` to get them up to the > server. > > If you have any questions regarding the repository setup please don't > hesitate to ask. You shouldn't be able to break anything, since we've > disabled force pushes to both master and Cog (and thus any chance of > destroying history). > > Thanks, > Tim & Fabio > > > > On 15 June 2016 at 19:26, Eliot Miranda wrote: > >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the >> scripts, and setting up automatic builds and hosting of binaries. We >> want to switch over from SVN tomorrow morning at 7am UTC. At that point, >> Tim and Fabio will merge any remaining commits on the SVN repository between >> now and that time and any further development will take place on >> Github. If possible, you may refrain from committing to SVN, as this >> will mean less work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch >> is the new default branch and is still called Cog, this is the main >> focus of development. The old trunk branch has been renamed to "oldTrunk". >> The master branch will track the Cog branch and will be the repository >> integrated into for releases. >> >> To get started, please refer to the updated README >> that is shown >> on the Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio >> >> > > -- Mariano http://marianopeck.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/9b4af4d3/attachment-0001.htm From kilon.alios at gmail.com Thu Jun 16 12:42:20 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Thu Jun 16 12:42:32 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: If I am not mistaken the GitHub upload limit is not longer there, it used to be around 400 MB but that is no longer the case, now its limitless, so I doubt you will get any complains from github. So how was the experience of porting to git overall ? Feels great to have Cog in Github thank you :) On Thu, Jun 16, 2016 at 11:24 AM Tim Felgentreff wrote: > > Hi all, > > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > migrated to GitHub. Automatic builds are running ( > https://ci.appveyor.com/project/timfel/vm/branch/Cog, > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). > > Right now we have enabled all platform, object memory and bytecode set > combinations that I found build scripts for - most work, but OS X 64-bit > Sista is failing right now (32-bit works). At some point we'll have to > decide which combinations to put into the CI config as "allowed failures" > to get a green badge :) > > Another thing for those not familiar with Git: Right now the entire > repository is 360MB, including all history. Most of that is old images that > were at one point committed to SVN and that have been pulled into the > repository. We could clean those out (removing them from the history) to > make the repository smaller, but I felt ~400MB is still ok (albeit > technically over the Github quota. We'll see of they complain). I would > like to ask everyone to stop committing large binary files into the > repository, however. Git is simply not very suited to dealing with > binaries. If there is a need for that, Github has support for git-lfs, > which offers 1GB of free storage with a 1GB bandwith limit per month. If we > need more, we can look at the different billing levels. > > If you're familiar with Git, the only new thing to watch out for is the > updateSCSSVersions script as described in the README. It's not relevant for > the CI, but your own binaries will only show correct versions if this > script runs at appropriate times. > > If you are not familiar with Git and don't care, there are scripts for > committing that should take care of everything as described in the README. > Again, let us know if anything doesn't work. The only difference vs SVN to > watch out for for you will be that the old scripts/svnci would commit your > changes to the server, whereas the scripts/gitci script only commits them > locally. You'll have to run `git pull` and `git push` to get them up to the > server. > > If you have any questions regarding the repository setup please don't > hesitate to ask. You shouldn't be able to break anything, since we've > disabled force pushes to both master and Cog (and thus any chance of > destroying history). > > Thanks, > Tim & Fabio > > > > On 15 June 2016 at 19:26, Eliot Miranda wrote: > >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the >> scripts, and setting up automatic builds and hosting of binaries. We >> want to switch over from SVN tomorrow morning at 7am UTC. At that point, >> Tim and Fabio will merge any remaining commits on the SVN repository between >> now and that time and any further development will take place on >> Github. If possible, you may refrain from committing to SVN, as this >> will mean less work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch >> is the new default branch and is still called Cog, this is the main >> focus of development. The old trunk branch has been renamed to "oldTrunk". >> The master branch will track the Cog branch and will be the repository >> integrated into for releases. >> >> To get started, please refer to the updated README >> that is shown >> on the Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/82ed8bc1/attachment.htm From tim at rowledge.org Thu Jun 16 15:57:09 2016 From: tim at rowledge.org (tim Rowledge) Date: Thu Jun 16 15:56:59 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: Message-ID: Regardless of any particular design ideas to implement this, I?d just like to say.. No. Nononono. Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Compromise, says Prof. Trefusis, is stalling between two fools From jan.vrany at fit.cvut.cz Thu Jun 16 16:11:16 2016 From: jan.vrany at fit.cvut.cz (Jan Vrany) Date: Thu Jun 16 16:11:35 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: Message-ID: <1466093476.2184.3@imap.fit.cvut.cz> On Thu, Jun 16, 2016 at 4:57 PM, tim Rowledge wrote: > > Regardless of any particular design ideas to implement this, I?d > just like to say.. No. > Nononono. > Bad design to use huge parameter lists. What next - allowing 1 > billion arguments for someone that thinks each pixel in a large > bitmap needs to be an argument? I say...Yes. Yesyesyesyes. Think of generated code. Think of interop. There are too many too low limits already (number of instance variables comes to mind) More recently designed architectures set limits a little higher. Something like 65535 :-) Jan > > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Compromise, says Prof. Trefusis, is stalling between two fools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/c56a4ca6/attachment.htm From eliot.miranda at gmail.com Thu Jun 16 16:18:09 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 16:18:13 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: Message-ID: <07555A90-6D23-4EAA-9161-D1592EE663DE@gmail.com> Hi Tim, > On Jun 16, 2016, at 8:57 AM, tim Rowledge wrote: > > > Regardless of any particular design ideas to implement this, I?d just like to say.. No. > Nononono. > Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument? This sometimes comes up in a porting project. It's not that one wants to support this its that one has to if the port is to proceed simply. Better to have a simple solution (look ma, no VM changes!!) than rewrite the daft automatic code generator that creates these monstrosities, or worse still complicate the VM (eg adding extension bytes to the method header so that all fetching of method numArgs is more complex). _,,,^..^,,,_ (phone) > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Compromise, says Prof. Trefusis, is stalling between two fools > From tim at rowledge.org Thu Jun 16 16:18:27 2016 From: tim at rowledge.org (tim Rowledge) Date: Thu Jun 16 16:18:15 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: <1466093476.2184.3@imap.fit.cvut.cz> References: <1466093476.2184.3@imap.fit.cvut.cz> Message-ID: <1092CE44-6D0A-4390-9C37-C43C50A95905@rowledge.org> > On 16-06-2016, at 9:11 AM, Jan Vrany wrote: > > > > On Thu, Jun 16, 2016 at 4:57 PM, tim Rowledge wrote: >> >> Regardless of any particular design ideas to implement this, I?d just like to say.. No. >> Nononono. >> Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument? >> > I say...Yes. > Yesyesyesyes. > > Think of generated code. Think of better quality designs for generated code. > Think of interop. Think of better designs for interoperation. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim You never finish a program, you just stop working on it. From eliot.miranda at gmail.com Thu Jun 16 16:28:57 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 16:29:02 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: Message-ID: <4C5040CF-6250-4D8C-92F1-81F7FFA386A0@gmail.com> Hi Cl?ment, > On Jun 16, 2016, at 1:21 AM, Cl?ment Bera wrote: > > Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ? Definitely only overflowing arguments. > > I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ? My analysis is that handling only overflow arguments provides more graceful degradation, why? When using this overflow scheme both the send, because of the creation of the argument vector, and argument access in the method, because arguments are indirectly accessed through the array, are slower. If all arguments are passed in the array then there is a big step down in performance from 14 to 15 arguments. But if only arguments greater than the 14th are passed in the array, fewer arguments have to be consed into the array, and arguments 1 through 14 can still be accessed directly. But the killer is disambiguating 1 argument methods. If all arguments are passed by the array then a 1 argument method may either by a 1 argument method or a greater than 14 argument method, and that must be disambiguated, slowing down or increasing the size of the very common case of a 1 argument method. If only arguments 25 and above are sent we only have to disambiguate the uncommon case of a 15 or more argument method. _,,,^..^,,,_ (phone) > >> On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier wrote: >> >> For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments. >> This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru. >> I don't know if it's the case for other 3rd party code, but it would be worth inquiring... >> >> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html >> http://bugs.squeak.org/view.php?id=2918 >> >> The (Old) Compiler code is at >> >> http://www.squeaksource.com/Smallapack.html >> Smallapack-Compiler.trunk-nice.6.mcz >> >> >> >> 2016-06-16 8:10 GMT+02:00 Cl?ment Bera : >>> >>> Hi everyone. >>> >>> It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks. >>> >>> I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change. >>> >>> The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments. >>> >>> The normal calling convention in the Smalltalk bytecode is as follows: >>> >>> push receiver >>> push arg 1 >>> push arg 2 >>> .... >>> push arg N >>> send selector >>> >>> N is limited to 15 arguments due compiled method header & bytecode encoding. >>> >>> In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors. >>> >>> The convention will look like that: >>> >>> push receiver >>> push arg 1 >>> push arg 2 >>> .... >>> push arg N >>> popIntoArray N-15 values >>> send selector >>> >>> The compilation of a method with more than 15 arguments is then changed: >>> - As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg. >>> - the compiled method header is still marked with 15 arguments >>> >>> In addition one needs to change CompiledMethod to: >>> - allow larger frames (instead of 56 we could allow 128 or 256) >>> - have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon. >>> >>> And to change the fall-back of a couple primitives, such as: >>> - Object>>perform: withArgs: >>> - Object>>perform: withArgs:inSupedClass: >>> - BlockClosure>>valueWithArgs: >>> >>> This design would allow methods to up to 141 arguments. >>> >>> What do you guys think ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/91a35ed0/attachment.htm From btc at openinworld.com Thu Jun 16 16:38:59 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 16 16:39:22 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: On Thu, Jun 16, 2016 at 5:10 PM, Serge Stinckwich wrote: > > On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff > wrote: >> Hi all, > > Very impressive work, Tim&Fabio ! The power of full-automation ! > >> as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was >> migrated to GitHub. Automatic builds are running >> (https://ci.appveyor.com/project/timfel/vm/branch/Cog, >> https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded >> (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). > > About uploading binary artifacts, this is something I asked and this > nice that Fabio make it work :-) What is the advantage of this? The 44 .image files stored in the repository take up 196MB, doubling the space. I guess thats not a big deal for a one time cost to clone the repository - for most of us with wide bandwidths in the modern world. But some places still have limited bandwidth. Also SSD are sometimes not so big, and maybe someone wants to compile on a smaller system like as RasPi (although it can handle reasonable sized storage cards.) > Apparently there is some problems with some artifacts that have a > double .zip extension. > >> Right now we have enabled all platform, object memory and bytecode set >> combinations that I found build scripts for - most work, but OS X 64-bit >> Sista is failing right now (32-bit works). At some point we'll have to >> decide which combinations to put into the CI config as "allowed failures" to >> get a green badge :) >> >> Another thing for those not familiar with Git: Right now the entire >> repository is 360MB, including all history. Most of that is old images that >> were at one point committed to SVN and that have been pulled into the >> repository. We could clean those out (removing them from the history) to >> make the repository smaller, but I felt ~400MB is still ok (albeit >> technically over the Github quota. We'll see of they complain). I would like >> to ask everyone to stop committing large binary files into the repository, >> however. Git is simply not very suited to dealing with binaries. >> If there is a need for that, Github has support for git-lfs, which offers 1GB of free >> storage with a 1GB bandwith limit per month. Initially I said... "Please, can we consider doing that. 1GB/1GB seems ample, and $5/mth provides 50GB/50GB [1] (and you'd expect those quotas to expand over time.) And a quick reference to how it works [2]. However enabling lfs doesn't automatically convert existing commits. The recommend migration tool seems to be git-lfs-migrate [3]. But history is rewritten, so any clones will need to be rebased - so now at the start is probably the best time to do it ! " But then I read lfs currently doesn't work properly with forked repos [4] [5] Also early lfs versions seem to have had a performance issue [6], but that may be recently solved [7]. btw, is anyone going to be using git-svn, or is everyone making the big jump pure git? In any case, I'm very glad to see the repo on git. Thanks all that helped make it happen, and Tim & Fabio for the work. cheers -ben [1] https://help.github.com/articles/billing-plans-for-git-large-file-storage/ [2] https://git-lfs.github.com/ [3] https://github.com/bozaro/git-lfs-migrate [4] https://medium.com/@megastep/github-s-large-file-storage-is-no-panacea-for-open-source-quite-the-opposite-12c0e16a9a91#.omrd0qw6n [5] https://github.com/github/git-lfs/issues/773 [6] https://www.bountysource.com/issues/21357625-git-lfs-is-unusable-slow-especially-on-windows [7] https://developer.atlassian.com/blog/2016/04/git-lfs-12-clone-faster/ >> If we need more, we can look at >> the different billing levels. >> >> If you're familiar with Git, the only new thing to watch out for is the >> updateSCSSVersions script as described in the README. It's not relevant for >> the CI, but your own binaries will only show correct versions if this script >> runs at appropriate times. >> >> If you are not familiar with Git and don't care, there are scripts for >> committing that should take care of everything as described in the README. >> Again, let us know if anything doesn't work. The only difference vs SVN to >> watch out for for you will be that the old scripts/svnci would commit your >> changes to the server, whereas the scripts/gitci script only commits them >> locally. You'll have to run `git pull` and `git push` to get them up to the >> server. >> >> If you have any questions regarding the repository setup please don't >> hesitate to ask. You shouldn't be able to break anything, since we've >> disabled force pushes to both master and Cog (and thus any chance of >> destroying history). > > What is favorite way of contributing for people outside the vm team ? > pull-requests ? > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ From jakob.reschke at student.hpi.de Thu Jun 16 16:45:24 2016 From: jakob.reschke at student.hpi.de (Jakob Reschke) Date: Thu Jun 16 16:45:46 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: 2016-06-16 18:38 GMT+02:00 Ben Coman : > > btw, is anyone going to be using git-svn, or is everyone making the > big jump pure git? Correct me, but I think there is no point to using git-svn here because the main repository will be the git one. git-svn allows one to use the git interface and play around with local branches where the main repository is svn. From btc at openinworld.com Thu Jun 16 16:51:26 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 16 16:51:48 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: On Fri, Jun 17, 2016 at 12:45 AM, Jakob Reschke wrote: > > 2016-06-16 18:38 GMT+02:00 Ben Coman : >> >> btw, is anyone going to be using git-svn, or is everyone making the >> big jump pure git? > > Correct me, but I think there is no point to using git-svn here > because the main repository will be the git one. git-svn allows one to > use the git interface and play around with local branches where the > main repository is svn. Thanks. I think I've misunderstood this the whole time, that you could use svn commands against the github repository. cheers -ben From eliot.miranda at gmail.com Thu Jun 16 16:56:56 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 16:57:00 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Hi All, > On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: > > > On Thu, Jun 16, 2016 at 5:10 PM, Serge Stinckwich > wrote: >> >> On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff >> wrote: >>> Hi all, >> >> Very impressive work, Tim&Fabio ! The power of full-automation ! >> >>> as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was >>> migrated to GitHub. Automatic builds are running >>> (https://ci.appveyor.com/project/timfel/vm/branch/Cog, >>> https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded >>> (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). >> >> About uploading binary artifacts, this is something I asked and this >> nice that Fabio make it work :-) > > What is the advantage of this? The 44 .image files stored in the > repository take up 196MB, doubling the space. What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. So please, list these image files here... > I guess thats not a > big deal for a one time cost to clone the repository - for most of us > with wide bandwidths in the modern world. But some places still have > limited bandwidth. > > Also SSD are sometimes not so big, and maybe someone wants to compile > on a smaller system like as RasPi (although it can handle reasonable > sized storage cards.) > >> Apparently there is some problems with some artifacts that have a >> double .zip extension. >> >>> Right now we have enabled all platform, object memory and bytecode set >>> combinations that I found build scripts for - most work, but OS X 64-bit >>> Sista is failing right now (32-bit works). At some point we'll have to >>> decide which combinations to put into the CI config as "allowed failures" to >>> get a green badge :) >>> >>> Another thing for those not familiar with Git: Right now the entire >>> repository is 360MB, including all history. Most of that is old images that >>> were at one point committed to SVN and that have been pulled into the >>> repository. We could clean those out (removing them from the history) to >>> make the repository smaller, but I felt ~400MB is still ok (albeit >>> technically over the Github quota. We'll see of they complain). I would like >>> to ask everyone to stop committing large binary files into the repository, >>> however. Git is simply not very suited to dealing with binaries. >>> If there is a need for that, Github has support for git-lfs, which offers 1GB of free >>> storage with a 1GB bandwith limit per month. > > Initially I said... "Please, can we consider doing that. 1GB/1GB > seems ample, and $5/mth provides 50GB/50GB [1] (and you'd expect those > quotas to expand over time.) And a quick reference to how it works > [2]. However enabling lfs doesn't automatically convert existing > commits. The recommend migration tool seems to be git-lfs-migrate > [3]. But history is rewritten, so any clones will need to be rebased > - so now at the start is probably the best time to do it ! " > > But then I read lfs currently doesn't work properly with forked repos [4] [5] > Also early lfs versions seem to have had a performance issue [6], > but that may be recently solved [7]. > > > btw, is anyone going to be using git-svn, or is everyone making the > big jump pure git? > > In any case, I'm very glad to see the repo on git. Thanks all that > helped make it happen, and Tim & Fabio for the work. > > cheers -ben > > [1] https://help.github.com/articles/billing-plans-for-git-large-file-storage/ > [2] https://git-lfs.github.com/ > [3] https://github.com/bozaro/git-lfs-migrate > [4] https://medium.com/@megastep/github-s-large-file-storage-is-no-panacea-for-open-source-quite-the-opposite-12c0e16a9a91#.omrd0qw6n > [5] https://github.com/github/git-lfs/issues/773 > [6] https://www.bountysource.com/issues/21357625-git-lfs-is-unusable-slow-especially-on-windows > [7] https://developer.atlassian.com/blog/2016/04/git-lfs-12-clone-faster/ > > > > > >>> If we need more, we can look at >>> the different billing levels. >>> >>> If you're familiar with Git, the only new thing to watch out for is the >>> updateSCSSVersions script as described in the README. It's not relevant for >>> the CI, but your own binaries will only show correct versions if this script >>> runs at appropriate times. >>> >>> If you are not familiar with Git and don't care, there are scripts for >>> committing that should take care of everything as described in the README. >>> Again, let us know if anything doesn't work. The only difference vs SVN to >>> watch out for for you will be that the old scripts/svnci would commit your >>> changes to the server, whereas the scripts/gitci script only commits them >>> locally. You'll have to run `git pull` and `git push` to get them up to the >>> server. >>> >>> If you have any questions regarding the repository setup please don't >>> hesitate to ask. You shouldn't be able to break anything, since we've >>> disabled force pushes to both master and Cog (and thus any chance of >>> destroying history). >> >> What is favorite way of contributing for people outside the vm team ? >> pull-requests ? >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ From lauraperezcerrato at gmail.com Thu Jun 16 17:09:45 2016 From: lauraperezcerrato at gmail.com (Laura Perez Cerrato) Date: Thu Jun 16 17:10:07 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Hi everyone, First of all, thanks a lot! Meaning to ask the same question as Serge, what's the preferred way of collaborating for anyone who's not a contributor? forking and then submitting a pull request? Cheers! -Laura Perez Cerrato On 16 June 2016 at 06:10, Serge Stinckwich wrote: > > On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff > wrote: > > Hi all, > > Very impressive work, Tim&Fabio ! The power of full-automation ! > > > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > > migrated to GitHub. Automatic builds are running > > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, > > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are > uploaded > > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). > > About uploading binary artifacts, this is something I asked and this > nice that Fabio > make it work :-) > > Apparently there is some problems with some artifacts that have a > double .zip extension. > > > Right now we have enabled all platform, object memory and bytecode set > > combinations that I found build scripts for - most work, but OS X 64-bit > > Sista is failing right now (32-bit works). At some point we'll have to > > decide which combinations to put into the CI config as "allowed > failures" to > > get a green badge :) > > > > Another thing for those not familiar with Git: Right now the entire > > repository is 360MB, including all history. Most of that is old images > that > > were at one point committed to SVN and that have been pulled into the > > repository. We could clean those out (removing them from the history) to > > make the repository smaller, but I felt ~400MB is still ok (albeit > > technically over the Github quota. We'll see of they complain). I would > like > > to ask everyone to stop committing large binary files into the > repository, > > however. Git is simply not very suited to dealing with binaries. If > there is > > a need for that, Github has support for git-lfs, which offers 1GB of free > > storage with a 1GB bandwith limit per month. If we need more, we can > look at > > the different billing levels. > > > > If you're familiar with Git, the only new thing to watch out for is the > > updateSCSSVersions script as described in the README. It's not relevant > for > > the CI, but your own binaries will only show correct versions if this > script > > runs at appropriate times. > > > > If you are not familiar with Git and don't care, there are scripts for > > committing that should take care of everything as described in the > README. > > Again, let us know if anything doesn't work. The only difference vs SVN > to > > watch out for for you will be that the old scripts/svnci would commit > your > > changes to the server, whereas the scripts/gitci script only commits them > > locally. You'll have to run `git pull` and `git push` to get them up to > the > > server. > > > > If you have any questions regarding the repository setup please don't > > hesitate to ask. You shouldn't be able to break anything, since we've > > disabled force pushes to both master and Cog (and thus any chance of > > destroying history). > > What is favorite way of contributing for people outside the vm team ? > pull-requests ? > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/ceda8a6b/attachment.htm From bera.clement at gmail.com Thu Jun 16 17:31:09 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Thu Jun 16 17:31:30 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: <4C5040CF-6250-4D8C-92F1-81F7FFA386A0@gmail.com> References: <4C5040CF-6250-4D8C-92F1-81F7FFA386A0@gmail.com> Message-ID: On Thu, Jun 16, 2016 at 6:28 PM, Eliot Miranda wrote: > > Hi Cl?ment, > > On Jun 16, 2016, at 1:21 AM, Cl?ment Bera wrote: > > Yeah I was wondering too, do we pass all arguments in an array or only the > overflowing arguments ? > > > Definitely only overflowing arguments. > > > I don't mind implementing either solution. I would like to know what are > the pros and cons. I understand that passing all arguments as an array is > simpler to implement and maintain. What are the other advantages and > disadvantages ? > > > My analysis is that handling only overflow arguments provides more > graceful degradation, why? > > When using this overflow scheme both the send, because of the creation of > the argument vector, and argument access in the method, because arguments > are indirectly accessed through the array, are slower. If all arguments > are passed in the array then there is a big step down in performance from > 14 to 15 arguments. But if only arguments greater than the 14th are passed > in the array, fewer arguments have to be consed into the array, and > arguments 1 through 14 can still be accessed directly. > > But the killer is disambiguating 1 argument methods. If all arguments are > passed by the array then a 1 argument method may either by a 1 argument > method or a greater than 14 argument method, and that must be > disambiguated, slowing down or increasing the size of the very common case > of a 1 argument method. If only arguments 25 and above are sent we only > have to disambiguate the uncommon case of a 15 or more argument method. > That second point convinced me. > > > _,,,^..^,,,_ (phone) > > > On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier < > nicolas.cellier.aka.nice@gmail.com> wrote: > >> >> For my personal use which was essentially calling FFI with more than 15 >> args, i used a single array for all arguments. >> This was more simple, and no optimization of the first 15 was needed >> since most of the time the long method is just a wrapper that passes >> parameters thru. >> I don't know if it's the case for other 3rd party code, but it would be >> worth inquiring... >> >> >> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html >> http://bugs.squeak.org/view.php?id=2918 >> >> The (Old) Compiler code is at >> >> http://www.squeaksource.com/Smallapack.html >> Smallapack-Compiler.trunk-nice.6.mcz >> >> >> >> >> 2016-06-16 8:10 GMT+02:00 Cl?ment Bera : >> >>> >>> Hi everyone. >>> >>> It seems that some people are struggling with the fact that methods in >>> Pharo (and other Smalltalk on top of Cog) cannot have more than 15 >>> arguments. Typically the problem arises while generating Smalltalk code or >>> porting code from other Smalltalks. >>> >>> I have been thinking for a while about this problem. In this mail I >>> write a small sketch to solve it, it's something that could go to >>> production very quickly and that requires almost only image-side changes. >>> Eliot has already reviewed and approved the sketch, but I''d like to know >>> if someone is strongly against that change. >>> >>> The generic idea is to change the send calling convention at the >>> bytecode level, using a temp vector to pass overflowing arguments. >>> >>> The normal calling convention in the Smalltalk bytecode is as follows: >>> >>> push receiver >>> push arg 1 >>> push arg 2 >>> .... >>> push arg N >>> send selector >>> >>> N is limited to 15 arguments due compiled method header & bytecode >>> encoding. >>> >>> In the new design, if the send has less than 15 arguments, the calling >>> convention remains the same. Over 15 arguments, the overflowing arguments >>> are passed in a temp vector in a similar way to the closure temp vectors. >>> >>> The convention will look like that: >>> >>> push receiver >>> push arg 1 >>> push arg 2 >>> .... >>> push arg N >>> popIntoArray N-15 values >>> send selector >>> >>> The compilation of a method with more than 15 arguments is then changed: >>> - As for temp vectors, the 15th arg array can't be become or read-only, >>> hence the temp vector instructions can be used to access the overflowing >>> arguments through the 15th arg. >>> - the compiled method header is still marked with 15 arguments >>> >>> In addition one needs to change CompiledMethod to: >>> - allow larger frames (instead of 56 we could allow 128 or 256) >>> - have numArgs answering the right number of methods with many >>> arguments. I think the number of arguments could be in the additional >>> method state in this case as it is very uncommon. >>> >>> And to change the fall-back of a couple primitives, such as: >>> - Object>>perform: withArgs: >>> - Object>>perform: withArgs:inSupedClass: >>> - BlockClosure>>valueWithArgs: >>> >>> This design would allow methods to up to 141 arguments. >>> >>> What do you guys think ? >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/5928c445/attachment-0001.htm From eliot.miranda at gmail.com Thu Jun 16 17:37:05 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 17:37:08 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Hi Laura, Hi Tim, On Thu, Jun 16, 2016 at 10:09 AM, Laura Perez Cerrato < lauraperezcerrato@gmail.com> wrote: > > Hi everyone, > > First of all, thanks a lot! > > Meaning to ask the same question as Serge, what's the preferred way of > collaborating for anyone who's not a contributor? forking and then > submitting a pull request? > thats on you, Tim, and I to update the README.md with a description of the contributor and change staging process. I'm going to be checking out the repository for the first time in a few minutes. I guess we can bat aroun drafts between us using git itself, but perhaps email would be more sensible ;-) > > Cheers! > > -Laura Perez Cerrato > > On 16 June 2016 at 06:10, Serge Stinckwich > wrote: > >> >> On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff >> wrote: >> > Hi all, >> >> Very impressive work, Tim&Fabio ! The power of full-automation ! >> >> > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was >> > migrated to GitHub. Automatic builds are running >> > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, >> > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are >> uploaded >> > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). >> >> About uploading binary artifacts, this is something I asked and this >> nice that Fabio >> make it work :-) >> >> Apparently there is some problems with some artifacts that have a >> double .zip extension. >> >> > Right now we have enabled all platform, object memory and bytecode set >> > combinations that I found build scripts for - most work, but OS X 64-bit >> > Sista is failing right now (32-bit works). At some point we'll have to >> > decide which combinations to put into the CI config as "allowed >> failures" to >> > get a green badge :) >> > >> > Another thing for those not familiar with Git: Right now the entire >> > repository is 360MB, including all history. Most of that is old images >> that >> > were at one point committed to SVN and that have been pulled into the >> > repository. We could clean those out (removing them from the history) to >> > make the repository smaller, but I felt ~400MB is still ok (albeit >> > technically over the Github quota. We'll see of they complain). I would >> like >> > to ask everyone to stop committing large binary files into the >> repository, >> > however. Git is simply not very suited to dealing with binaries. If >> there is >> > a need for that, Github has support for git-lfs, which offers 1GB of >> free >> > storage with a 1GB bandwith limit per month. If we need more, we can >> look at >> > the different billing levels. >> > >> > If you're familiar with Git, the only new thing to watch out for is the >> > updateSCSSVersions script as described in the README. It's not relevant >> for >> > the CI, but your own binaries will only show correct versions if this >> script >> > runs at appropriate times. >> > >> > If you are not familiar with Git and don't care, there are scripts for >> > committing that should take care of everything as described in the >> README. >> > Again, let us know if anything doesn't work. The only difference vs SVN >> to >> > watch out for for you will be that the old scripts/svnci would commit >> your >> > changes to the server, whereas the scripts/gitci script only commits >> them >> > locally. You'll have to run `git pull` and `git push` to get them up to >> the >> > server. >> > >> > If you have any questions regarding the repository setup please don't >> > hesitate to ask. You shouldn't be able to break anything, since we've >> > disabled force pushes to both master and Cog (and thus any chance of >> > destroying history). >> >> What is favorite way of contributing for people outside the vm team ? >> pull-requests ? >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/9e36801c/attachment.htm From johnmci at smalltalkconsulting.com Thu Jun 16 17:48:06 2016 From: johnmci at smalltalkconsulting.com (John McIntosh) Date: Thu Jun 16 17:50:55 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: <54F07109-67A6-4882-BC6F-E6FA9FD7ABB1@smalltalkconsulting.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2647 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/486a2260/smime-0001.bin From commits at source.squeak.org Thu Jun 16 18:04:47 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Jun 16 18:04:49 2016 Subject: [Vm-dev] VM Maker: Cog-eem.327.mcz Message-ID: Eliot Miranda uploaded a new version of Cog to project VM Maker: http://source.squeak.org/VMMaker/Cog-eem.327.mcz ==================== Summary ==================== Name: Cog-eem.327 Author: eem Time: 16 June 2016, 11:03:47.628185 am UUID: d8b78ff9-3baf-4217-9810-345304ce963a Ancestors: Cog-eem.326 Make sure all appropriate registers are smashed on ARM when enilopmarting into machine code. =============== Diff against Cog-eem.326 =============== Item was changed: ----- Method: GdbARMAlien>>smashRegisterAccessors (in category 'accessing-abstract') ----- smashRegisterAccessors + ^#(r0: r1: r2: r3: r4: r5: r6: r7: r8: r9: r10: "11=FP" r12: "13=SP, 14=LR, 15=PC")! - ^#(r0: r1: r2: r3: r4: r5: r6: r7: r8: r9: r10:)! From bert at freudenbergs.de Thu Jun 16 18:16:37 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Jun 16 18:17:01 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda wrote: > > Hi All, > > On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: > > What is the advantage of this? The 44 .image files stored in the > > repository take up 196MB, doubling the space. > > What are the images? IIRC there are no images in the svn repo. The only > big files are sources files for various key squeak and Pharo releases. > Did I check in images in the images directory by mistake? There should be > nine there; they're to be downloaded and built/converted, not checked into > the repository. > > So please, list these image files here... Here's a list of all the blobs larger than 1 MB: 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/e3bbc33f/attachment.htm From eliot.miranda at gmail.com Thu Jun 16 18:24:59 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 18:25:02 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: Hi Bert, On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg wrote: > > On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda > wrote: > >> >> Hi All, >> >> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >> > What is the advantage of this? The 44 .image files stored in the >> > repository take up 196MB, doubling the space. >> >> What are the images? IIRC there are no images in the svn repo. The only >> big files are sources files for various key squeak and Pharo releases. >> Did I check in images in the images directory by mistake? There should be >> nine there; they're to be downloaded and built/converted, not checked into >> the repository. >> >> So please, list these image files here... > > > Here's a list of all the blobs larger than 1 MB: > Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. To be clear image/VMMaker-Squeak4.1.image image/VMMaker-Squeak4.1.changes (if it exists) image/CogTrunk43.image image/CogTrunk43.changes should exist. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? > 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 > image/VMMaker-Squeak4.1.image > dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources > 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image > 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes > 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image > ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 > platforms/iOS/vm/iPhone/iPhone.image > 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 > image/VMMaker-Squeak4.1.image > 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 > image/VMMaker-Squeak4.1.image > 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 > image/VMMaker-Squeak4.1.image > b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 > FloatMathPlugin/testdata/log-large.dat > 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 > FloatMathPlugin/testdata/sqrt-large.dat > 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 > FloatMathPlugin/testdata/exp-large.dat > 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 > FloatMathPlugin/testdata/atan-large.dat > 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 > FloatMathPlugin/testdata/sin-large.dat > 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 > platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib > 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols > ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 > platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib > 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 > platforms/iOS/vm/iPhone/iPhone.changes > ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 > processors/ARM/gdb-7.10/opcodes/i386-tbl.h > 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 > processors/ARM/gdb-7.10/opcodes/m32c-desc.c > 8d66e7b3f3d10585846476ac343627852530647a 4287774 > platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser > 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 > processors/ARM/gdb-7.10/opcodes/m32c-opc.c > 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 > platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib > e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 > processors/ARM/gdb-7.10/sim/frv/model.c > 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 > platforms/win32/plugins/FT2Plugin/freetype.a > 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 > nsspur64src/vm/gcc3x-cointerp.c > dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c > de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 > spursistasrc/vm/gcc3x-cointerp.c > 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c > 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c > 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 > nsspurstack64src/vm/gcc3x-interp.c > 339e0fadfb07d7386e6940039c8c75904841795a 2538879 > nsspurstack64src/vm/interp.c > 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c > 408fd7522634a24e3100131466c9845c1e4aede5 2489223 > spursrc/vm/gcc3x-cointerp.c > 755e2901d955ee552537ba5257e37baa57026fbc 2467156 > platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib > 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols > 440955ce2200921b12153427645b8b191f8519be 2190822 > nsspurstacksrc/vm/gcc3x-interp.c > 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c > 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 > platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib > ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings > 34622fc8d020d258054f991209e02d300f51e4af 2097172 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control > 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c > 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 > spursrc/vm/gcc3x-cointerp.c > 92e95daf567930738b49a7ad87585c96623733fb 1884583 > nsspurstacksrc/vm/gcc3x-interp.c > 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm > 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 > nsspurstacksrc/vm/gcc3x-interp.c > 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c > 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c > 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c > 965a8b480996779d2345ca314707408c4471d808 1820909 > spursrc/vm/gcc3x-cointerp.c > c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 > spursrc/vm/gcc3x-cointerp.c > 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c > b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c > 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c > fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c > 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 > processors/ARM/gdb-7.10/Makefile.in > fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c > 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 > spurstacksrc/vm/gcc3x-interp.c > 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 > nscogsrc/vm/gcc3x-cointerp.c > e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c > 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c > b869bae1da98ed4f113b599569313384b618ba2f 1597168 > nscogsrc/vm/gcc3x-cointerp.c > 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S > 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 > processors/ARM/gdb-7.6/Makefile.in > b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c > 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S > 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c > 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c > 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c > 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c > 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c > 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 > platforms/win32/plugins/CameraPlugin/STRMBASE.lib > bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 > build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin > b10adc6f89039843e66c4b876bed9049e309ef04 1255450 > processors/IA32/bochs/build/macos/CWPro3_project.sit > e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 > processors/IA32/bochs/configure > b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 > build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp > bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac > d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 > spursistasrc/vm/cogitARMv5.c > ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 > processors/ARM/gdb-7.10/opcodes/i386-opc.tbl > 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 > processors/ARM/gdb-7.10/opcodes/m32c-opc.h > 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c > 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 > spursistasrc/vm/cogitIA32.c > 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree > c36cc19ee1658d23886d93a73289048128c4ba95 1048596 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control > 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 > spursistasrc/vm/cogitMIPSEL.c > f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 > spursistasrc/vm/cogitMIPSEL.c > d28406446edf029b9b389403d882c6ae581d1fb2 1043986 > platforms/unix/config/configure > e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac > 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c > 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 > processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s > > - Bert - > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/03c4f8ea/attachment-0001.htm From eliot.miranda at gmail.com Thu Jun 16 18:26:20 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 18:26:22 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: On Thu, Jun 16, 2016 at 11:24 AM, Eliot Miranda wrote: > Hi Bert, > > On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg > wrote: > >> >> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda >> wrote: >> >>> >>> Hi All, >>> >>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >>> > What is the advantage of this? The 44 .image files stored in the >>> > repository take up 196MB, doubling the space. >>> >>> What are the images? IIRC there are no images in the svn repo. The only >>> big files are sources files for various key squeak and Pharo releases. >>> Did I check in images in the images directory by mistake? There should be >>> nine there; they're to be downloaded and built/converted, not checked into >>> the repository. >>> >>> So please, list these image files here... >> >> >> Here's a list of all the blobs larger than 1 MB: >> > > Thanks. None of those image (or associated changes) files should exist in > image/. None of them exist in the svn repository. How did they creep in? > Some who's already up and running might like to nuke them and commit them > to the master asap. To be clear > > image/VMMaker-Squeak4.1.image > image/VMMaker-Squeak4.1.changes (if it exists) > image/CogTrunk43.image > image/CogTrunk43.changes > > should exist. Is this history pruning issue? Ah, that's what must have > happened. They were in svn at one time, and so have got copied in as part > of moving the entire history. So... anyone know enough git internals to > prune this part of the history? > http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository > > >> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 >> image/VMMaker-Squeak4.1.image >> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 >> sources/SqueakV46.sources >> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 >> platforms/iOS/vm/iPhone/iPhone.image >> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 >> image/VMMaker-Squeak4.1.image >> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 >> image/VMMaker-Squeak4.1.image >> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 >> image/VMMaker-Squeak4.1.image >> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 >> FloatMathPlugin/testdata/log-large.dat >> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 >> FloatMathPlugin/testdata/sqrt-large.dat >> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 >> FloatMathPlugin/testdata/exp-large.dat >> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 >> FloatMathPlugin/testdata/atan-large.dat >> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 >> FloatMathPlugin/testdata/sin-large.dat >> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 >> platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 >> platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 >> platforms/iOS/vm/iPhone/iPhone.changes >> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 >> processors/ARM/gdb-7.10/opcodes/i386-tbl.h >> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 >> processors/ARM/gdb-7.10/opcodes/m32c-desc.c >> 8d66e7b3f3d10585846476ac343627852530647a 4287774 >> platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 >> processors/ARM/gdb-7.10/opcodes/m32c-opc.c >> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 >> platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 >> processors/ARM/gdb-7.10/sim/frv/model.c >> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 >> platforms/win32/plugins/FT2Plugin/freetype.a >> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 >> nsspur64src/vm/gcc3x-cointerp.c >> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 >> spursistasrc/vm/gcc3x-cointerp.c >> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 >> nsspurstack64src/vm/gcc3x-interp.c >> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 >> nsspurstack64src/vm/interp.c >> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 >> nsspurstacksrc/vm/interp.c >> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 >> spursrc/vm/gcc3x-cointerp.c >> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 >> platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 >> build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >> 440955ce2200921b12153427645b8b191f8519be 2190822 >> nsspurstacksrc/vm/gcc3x-interp.c >> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 >> spursistasrc/vm/cointerp.c >> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 >> platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >> 34622fc8d020d258054f991209e02d300f51e4af 2097172 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 >> spursrc/vm/gcc3x-cointerp.c >> 92e95daf567930738b49a7ad87585c96623733fb 1884583 >> nsspurstacksrc/vm/gcc3x-interp.c >> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 >> nsspurstacksrc/vm/gcc3x-interp.c >> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >> 965a8b480996779d2345ca314707408c4471d808 1820909 >> spursrc/vm/gcc3x-cointerp.c >> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 >> spursrc/vm/gcc3x-cointerp.c >> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 >> processors/ARM/gdb-7.10/Makefile.in >> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 >> spurstacksrc/vm/gcc3x-interp.c >> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 >> nscogsrc/vm/gcc3x-cointerp.c >> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >> b869bae1da98ed4f113b599569313384b618ba2f 1597168 >> nscogsrc/vm/gcc3x-cointerp.c >> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 >> processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 >> processors/ARM/gdb-7.6/Makefile.in >> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 >> processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 >> stacksrc/vm/gcc3x-interp.c >> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 >> stacksrc/vm/gcc3x-interp.c >> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 >> platforms/win32/plugins/CameraPlugin/STRMBASE.lib >> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 >> build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 >> processors/IA32/bochs/build/macos/CWPro3_project.sit >> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 >> processors/IA32/bochs/configure >> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 >> build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 >> spursistasrc/vm/cogitARMv5.c >> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 >> processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 >> processors/ARM/gdb-7.10/opcodes/m32c-opc.h >> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 >> stacksrc/vm/gcc3x-interp.c >> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 >> spursistasrc/vm/cogitIA32.c >> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 >> build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 >> spursistasrc/vm/cogitMIPSEL.c >> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 >> spursistasrc/vm/cogitMIPSEL.c >> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 >> platforms/unix/config/configure >> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 >> processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >> >> - Bert - >> > > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/3bc89a55/attachment.htm From eliot.miranda at gmail.com Thu Jun 16 18:29:09 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 18:29:13 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Tim, this morning as I prepared to cone the repository I felt a rush of relief spread over me as I realised that I never haves to build and upload VMs again. Thank you, thank you, thank you, everyone who encouraged and helped me in making this transition. I am a happier human as a result. On Thu, Jun 16, 2016 at 1:24 AM, Tim Felgentreff wrote: > > Hi all, > > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > migrated to GitHub. Automatic builds are running ( > https://ci.appveyor.com/project/timfel/vm/branch/Cog, > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). > > Right now we have enabled all platform, object memory and bytecode set > combinations that I found build scripts for - most work, but OS X 64-bit > Sista is failing right now (32-bit works). At some point we'll have to > decide which combinations to put into the CI config as "allowed failures" > to get a green badge :) > > Another thing for those not familiar with Git: Right now the entire > repository is 360MB, including all history. Most of that is old images that > were at one point committed to SVN and that have been pulled into the > repository. We could clean those out (removing them from the history) to > make the repository smaller, but I felt ~400MB is still ok (albeit > technically over the Github quota. We'll see of they complain). I would > like to ask everyone to stop committing large binary files into the > repository, however. Git is simply not very suited to dealing with > binaries. If there is a need for that, Github has support for git-lfs, > which offers 1GB of free storage with a 1GB bandwith limit per month. If we > need more, we can look at the different billing levels. > > If you're familiar with Git, the only new thing to watch out for is the > updateSCSSVersions script as described in the README. It's not relevant for > the CI, but your own binaries will only show correct versions if this > script runs at appropriate times. > > If you are not familiar with Git and don't care, there are scripts for > committing that should take care of everything as described in the README. > Again, let us know if anything doesn't work. The only difference vs SVN to > watch out for for you will be that the old scripts/svnci would commit your > changes to the server, whereas the scripts/gitci script only commits them > locally. You'll have to run `git pull` and `git push` to get them up to the > server. > > If you have any questions regarding the repository setup please don't > hesitate to ask. You shouldn't be able to break anything, since we've > disabled force pushes to both master and Cog (and thus any chance of > destroying history). > > Thanks, > Tim & Fabio > > > > On 15 June 2016 at 19:26, Eliot Miranda wrote: > >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the >> scripts, and setting up automatic builds and hosting of binaries. We >> want to switch over from SVN tomorrow morning at 7am UTC. At that point, >> Tim and Fabio will merge any remaining commits on the SVN repository between >> now and that time and any further development will take place on >> Github. If possible, you may refrain from committing to SVN, as this >> will mean less work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch >> is the new default branch and is still called Cog, this is the main >> focus of development. The old trunk branch has been renamed to "oldTrunk". >> The master branch will track the Cog branch and will be the repository >> integrated into for releases. >> >> To get started, please refer to the updated README >> that is shown >> on the Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio >> >> > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/0e0e3378/attachment-0001.htm From btc at openinworld.com Thu Jun 16 19:01:02 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 16 19:01:25 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: On Fri, Jun 17, 2016 at 2:26 AM, Eliot Miranda wrote: > > > > On Thu, Jun 16, 2016 at 11:24 AM, Eliot Miranda wrote: >> >> Hi Bert, >> >> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg wrote: >>> >>> >>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda wrote: >>>> >>>> >>>> Hi All, >>>> >>>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >>>> > What is the advantage of this? The 44 .image files stored in the >>>> > repository take up 196MB, doubling the space. >>>> >>>> What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. >>>> >>>> So please, list these image files here... >>> >>> >>> Here's a list of all the blobs larger than 1 MB: >> >> >> Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. >> To be clear >> >> image/VMMaker-Squeak4.1.image >> image/VMMaker-Squeak4.1.changes (if it exists) >> image/CogTrunk43.image >> image/CogTrunk43.changes >> >> should exist. Rather than existing in the repo, can a script download these? Maybe need a really *permanent* location to provide the real script to download, so the download server/method can change in the future and still work with old commits. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? > > > http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository You beat me to it. I saw several other links all recommending BFG Repo-Cleaner. cheers -ben > > >> >> >>> >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >>> 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >>> 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >>> >>> - Bert - >> >> >> _,,,^..^,,,_ >> best, Eliot > > > > > -- > _,,,^..^,,,_ > best, Eliot > From eliot.miranda at gmail.com Thu Jun 16 19:03:47 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 19:03:51 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: Hi Ben, On Thu, Jun 16, 2016 at 12:01 PM, Ben Coman wrote: > > On Fri, Jun 17, 2016 at 2:26 AM, Eliot Miranda > wrote: > > > > > > > > On Thu, Jun 16, 2016 at 11:24 AM, Eliot Miranda > wrote: > >> > >> Hi Bert, > >> > >> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg < > bert@freudenbergs.de> wrote: > >>> > >>> > >>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda < > eliot.miranda@gmail.com> wrote: > >>>> > >>>> > >>>> Hi All, > >>>> > >>>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: > >>>> > What is the advantage of this? The 44 .image files stored in the > >>>> > repository take up 196MB, doubling the space. > >>>> > >>>> What are the images? IIRC there are no images in the svn repo. The > only big files are sources files for various key squeak and Pharo > releases. Did I check in images in the images directory by mistake? There > should be nine there; they're to be downloaded and built/converted, not > checked into the repository. > >>>> > >>>> So please, list these image files here... > >>> > >>> > >>> Here's a list of all the blobs larger than 1 MB: > >> > >> > >> Thanks. None of those image (or associated changes) files should exist > in image/. None of them exist in the svn repository. How did they creep > in? Some who's already up and running might like to nuke them and commit > them to the master asap. > > >> To be clear > >> > >> image/VMMaker-Squeak4.1.image > >> image/VMMaker-Squeak4.1.changes (if it exists) > >> image/CogTrunk43.image > >> image/CogTrunk43.changes > >> > >> should exist. > > Rather than existing in the repo, can a script download these? Maybe > need a really *permanent* location to provide the real script to > download, so the download server/method can change in the future and > still work with old commits. > Well, if anyone ever did need them they could always get them from the svn repository. It isn't going away it just isn't being used for Cog any more. But there images really are obsolete. > > Is this history pruning issue? Ah, that's what must have happened. > They were in svn at one time, and so have got copied in as part of > moving the entire history. So... anyone know enough git internals to > prune this part of the history? > > > > > > > http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository > > You beat me to it. I saw several other links all recommending BFG > Repo-Cleaner. > cheers -ben > > > > > > > >> > >> > >>> > >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 > image/VMMaker-Squeak4.1.image > >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 > sources/SqueakV46.sources > >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 > image/CogTrunk43.image > >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 > image/CogTrunk43.changes > >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 > image/CogTrunk43.image > >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 > platforms/iOS/vm/iPhone/iPhone.image > >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 > image/VMMaker-Squeak4.1.image > >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 > image/VMMaker-Squeak4.1.image > >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 > image/VMMaker-Squeak4.1.image > >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 > FloatMathPlugin/testdata/log-large.dat > >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 > FloatMathPlugin/testdata/sqrt-large.dat > >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 > FloatMathPlugin/testdata/exp-large.dat > >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 > FloatMathPlugin/testdata/atan-large.dat > >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 > FloatMathPlugin/testdata/sin-large.dat > >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 > platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib > >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols > >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 > platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib > >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 > platforms/iOS/vm/iPhone/iPhone.changes > >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 > processors/ARM/gdb-7.10/opcodes/i386-tbl.h > >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 > processors/ARM/gdb-7.10/opcodes/m32c-desc.c > >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 > platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser > >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 > processors/ARM/gdb-7.10/opcodes/m32c-opc.c > >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 > platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib > >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 > processors/ARM/gdb-7.10/sim/frv/model.c > >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 > platforms/win32/plugins/FT2Plugin/freetype.a > >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 > nsspur64src/vm/gcc3x-cointerp.c > >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 > nsspur64src/vm/cointerp.c > >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 > spursistasrc/vm/gcc3x-cointerp.c > >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 > spur64src/vm/cointerp.c > >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 > spur64src/vm/cointerp.c > >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 > nsspurstack64src/vm/gcc3x-interp.c > >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 > nsspurstack64src/vm/interp.c > >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 > nsspurstacksrc/vm/interp.c > >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 > spursrc/vm/gcc3x-cointerp.c > >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 > platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib > >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols > >>> 440955ce2200921b12153427645b8b191f8519be 2190822 > nsspurstacksrc/vm/gcc3x-interp.c > >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 > spursistasrc/vm/cointerp.c > >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 > platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib > >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings > >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control > >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 > spurstacksrc/vm/interp.c > >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 > spursrc/vm/gcc3x-cointerp.c > >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 > nsspurstacksrc/vm/gcc3x-interp.c > >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm > >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 > nsspurstacksrc/vm/gcc3x-interp.c > >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c > >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 > src/vm/gcc3x-cointerpmt.c > >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c > >>> 965a8b480996779d2345ca314707408c4471d808 1820909 > spursrc/vm/gcc3x-cointerp.c > >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 > spursrc/vm/gcc3x-cointerp.c > >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c > >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 > src/vm/gcc3x-cointerp.c > >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c > >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c > >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 > processors/ARM/gdb-7.10/Makefile.in > >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 > spurstacksrc/vm/interp.c > >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 > spurstacksrc/vm/gcc3x-interp.c > >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 > nscogsrc/vm/gcc3x-cointerp.c > >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 > src/vm/gcc3x-cointerpmt.c > >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c > >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 > nscogsrc/vm/gcc3x-cointerp.c > >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S > >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 > processors/ARM/gdb-7.6/Makefile.in > >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 > src/vm/gcc3x-cointerp.c > >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S > >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c > >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 > spurstacksrc/vm/interp.c > >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 > stacksrc/vm/gcc3x-interp.c > >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c > >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 > stacksrc/vm/gcc3x-interp.c > >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 > platforms/win32/plugins/CameraPlugin/STRMBASE.lib > >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 > build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin > >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 > processors/IA32/bochs/build/macos/CWPro3_project.sit > >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 > processors/IA32/bochs/configure > >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 > build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp > >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac > >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 > spursistasrc/vm/cogitARMv5.c > >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 > processors/ARM/gdb-7.10/opcodes/i386-opc.tbl > >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 > processors/ARM/gdb-7.10/opcodes/m32c-opc.h > >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 > stacksrc/vm/gcc3x-interp.c > >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 > spursistasrc/vm/cogitIA32.c > >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree > >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control > >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 > spursistasrc/vm/cogitMIPSEL.c > >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 > spursistasrc/vm/cogitMIPSEL.c > >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 > platforms/unix/config/configure > >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac > >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 > nsspur64src/vm/cogitX64.c > >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 > processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s > >>> > >>> - Bert - > >> > >> > >> _,,,^..^,,,_ > >> best, Eliot > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/7736634c/attachment-0001.htm From eliot.miranda at gmail.com Thu Jun 16 19:46:45 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 19:46:47 2016 Subject: get-url fails on Mac OS X [Was Re: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] Message-ID: Hi Perlers, in .git_filters/RevDateURL.smudge the URL is obtained with "git remote get-url origin", but that doesn't work on Mac OS X git version 1.9.5 (Apple Git-50.3). Instead one has to use git remote show origin. I'm modifying .git_filters/RevDateURL.smudge to read $url=`git remote get-url origin 2>/dev/null`; if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: //' 2>/dev/null` } $url =~ s/\s+$//m; But it strikes me that the editing down from * remote origin Fetch URL: http://github.com/OpenSmalltalk/vm Push URL: http://github.com/OpenSmalltalk/vm HEAD branch: Cog Remote branches: Cog tracked master tracked oldTrunk tracked platform/Cross/plugins tracked platform/win32/plugins tracked Local branch configured for 'git pull': Cog merges with remote Cog Local ref configured for 'git push': Cog pushes to Cog (up to date) to Fetch URL: http://github.com/OpenSmalltalk/vm and thence to http://github.com/OpenSmalltalk/vm would best be done in Perl. So anyone who's motivated, please fix my poor fix. I'm not a perl whiz. And I want to put it on the longer term list to replace these perl scripts with squeak or pharo scripts ;-) _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/d5567d18/attachment.htm From eliot.miranda at gmail.com Thu Jun 16 20:07:23 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 16 20:07:29 2016 Subject: Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] Message-ID: Hi All, so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?) I have a VM that outputs a reasonable version info: /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 12:53:33 2016 -0700 $ Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ Which begs the question how do I differentiate this from something built officially via Travis? Arguably the URL is wrong, and should only say " http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should just include my local hostname and current directory when I make any kind of local modification. So the above would read ... VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 2016 -0700 $ Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ Alternatively we could add another field, or modify one of the existing fields to say "I'm official" however one would do that. I don't know how, I just know we need this. I shouldn't be able to pollute the VM pool by putting some VM on some site somewhere that i just happened to build after several sherries and some cannabis brownies that looks to all intents and purposes just like a VM built by our official Travis slaves. Hic. Chillin' _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/01f1e9c4/attachment.htm From btc at openinworld.com Thu Jun 16 23:53:48 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 16 23:54:10 2016 Subject: get-url fails on Mac OS X [Was Re: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: Message-ID: On Fri, Jun 17, 2016 at 3:46 AM, Eliot Miranda wrote: > > Hi Perlers, > > in .git_filters/RevDateURL.smudge the URL is obtained with "git remote get-url origin", but that doesn't work on Mac OS X git version 1.9.5 (Apple Git-50.3). Instead one has to use git remote show origin. > > I'm modifying .git_filters/RevDateURL.smudge to read > > $url=`git remote get-url origin 2>/dev/null`; > if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: //' 2>/dev/null` } > $url =~ s/\s+$//m; > > But it strikes me that the editing down from > > * remote origin > Fetch URL: http://github.com/OpenSmalltalk/vm > Push URL: http://github.com/OpenSmalltalk/vm > HEAD branch: Cog > Remote branches: > Cog tracked > master tracked > oldTrunk tracked > platform/Cross/plugins tracked > platform/win32/plugins tracked > Local branch configured for 'git pull': > Cog merges with remote Cog > Local ref configured for 'git push': > Cog pushes to Cog (up to date) > > to > > Fetch URL: http://github.com/OpenSmalltalk/vm > > and thence to > > http://github.com/OpenSmalltalk/vm > > would best be done in Perl. So anyone who's motivated, please fix my poor fix. I'm not a perl whiz. > > And I want to put it on the longer term list to replace these perl scripts with squeak or pharo scripts ;-) > > _,,,^..^,,,_ > best, Eliot > Perhaps you could open an issue to remember this :) ... https://github.com/OpenSmalltalk/vm/issues oh, nice shiny features... cheers -ben From lewis at mail.msen.com Fri Jun 17 01:40:53 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 17 01:40:54 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> Message-ID: <20160617014053.GA17233@shell.msen.com> On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: > > I finally got a moment to look at this - not that I really have much clue > about the whole unix process thing - and it appears that something is odd > with the compiled code in the plugin. > > My test is very simple - run the UnixProcess class>listDirectory example. > It exits with a segfault and the forkAndExec??? method as the last thing > on the stack. > > I build a debug vm (and had some fun with asserts and the ARM fp offset in > the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling > the plugin with varying levels of optimisation, since we???ve fairly regularly > seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. > Nice. > > Ideas? > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and setup advice). Very cool. My only usability complaint is that the TV monitor is in the next room, so I am getting a stiff neck trying to look at the monitor while I type on my chiclet keyboard here in the kitchen. But it works, and it is a real computer. I started by compiling an interpreter VM to run against "trunk level" V3 image with OSProcess/CommandShell loaded. What I found so far: - The 32-bit VM running 64-bit image does not work, cannot load X11 driver. This used to work 6 or 8 years ago on 64 bit x86, so probably some regression because I have not been testing on 32-bit host, and Raspbian is 32-bit. - After loading OSProcess/CommandShell, I was getting errors, something like fork not being able to allocate memory. Sorry, I did not capture the error, and it's gone now. - I then ran the OSP/CommandShell test suite. This crashed my login session and took me to a login prompt. WTF?!? This is supposed to be impossible on a Unix system. I'm still provisionally impressed with Raspbian, but ... - I logged back in and ran the OSP/CommandShell tests again. Everything looks good now, except that tests related to file locking protocol are failing. These are rarely used functions and may be linux distro dependent, so I'm not worried about these failures. - RemoteTask seems to be working also. Nice. - Overall, most of the OSProcess functionality seems to be just working, so that is a pleasant surprise. - I have gotten a few image lockups. I don't think it is related to OSProcess, more likely that I am trying to use a "trunk level" V3 image, maybe a bit buggy at this point. I will try setting up a Cog/Spur build next, and see what that looks like. But probably not tonight :-) Dave From timfelgentreff at gmail.com Fri Jun 17 07:09:46 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Fri Jun 17 07:10:10 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: Hi Eliot, we can nuke the history, but everyone will have to re-clone the repository. Fabio and I will do it today, before everyone gets busy on the new repo. About the images you mention that are supposed to be there: These *will* cause problems down the road. There is no way we can keep removing them from history when new versions come to replace them, and still maintain a sensible collaborative development approach. Rewriting history to remove this will cause problems for everyone involved. These binary files really shouldn't be in Git at all. cheers, Tim On 16 June 2016 at 20:24, Eliot Miranda wrote: > > > Hi Bert, > > On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg wrote: >> >> >> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda wrote: >>> >>> >>> Hi All, >>> >>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >>> > What is the advantage of this? The 44 .image files stored in the >>> > repository take up 196MB, doubling the space. >>> >>> What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. >>> >>> So please, list these image files here... >> >> >> Here's a list of all the blobs larger than 1 MB: > > > Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. To be clear > > image/VMMaker-Squeak4.1.image > image/VMMaker-Squeak4.1.changes (if it exists) > image/CogTrunk43.image > image/CogTrunk43.changes > > should exist. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? > >> >> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image >> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources >> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image >> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image >> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image >> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image >> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat >> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat >> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat >> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat >> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat >> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes >> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h >> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c >> 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c >> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c >> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a >> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c >> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c >> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c >> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c >> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c >> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c >> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >> 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c >> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c >> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >> 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c >> 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c >> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c >> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >> 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c >> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c >> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in >> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c >> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c >> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >> b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c >> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in >> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c >> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c >> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib >> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit >> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure >> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c >> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h >> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c >> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c >> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c >> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c >> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure >> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >> >> - Bert - > > > _,,,^..^,,,_ > best, Eliot > From timfelgentreff at gmail.com Fri Jun 17 07:12:56 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Fri Jun 17 07:13:17 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <20160617014053.GA17233@shell.msen.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> Message-ID: Dave, there are builds for Raspbian on our new bintray page. If all you want is the latest version, you should be able to just use these, no need to compile yourself: https://bintray.com/opensmalltalk/vm/cog/201606161953/view#files cheers, Tim On 17 June 2016 at 03:40, David T. Lewis wrote: > > On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: >> >> I finally got a moment to look at this - not that I really have much clue >> about the whole unix process thing - and it appears that something is odd >> with the compiled code in the plugin. >> >> My test is very simple - run the UnixProcess class>listDirectory example. >> It exits with a segfault and the forkAndExec??? method as the last thing >> on the stack. >> >> I build a debug vm (and had some fun with asserts and the ARM fp offset in >> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling >> the plugin with varying levels of optimisation, since we???ve fairly regularly >> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. >> Nice. >> >> Ideas? >> > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and > setup advice). Very cool. My only usability complaint is that the TV monitor > is in the next room, so I am getting a stiff neck trying to look at the monitor > while I type on my chiclet keyboard here in the kitchen. But it works, and it > is a real computer. > > I started by compiling an interpreter VM to run against "trunk level" V3 image > with OSProcess/CommandShell loaded. What I found so far: > > - The 32-bit VM running 64-bit image does not work, cannot load X11 driver. > This used to work 6 or 8 years ago on 64 bit x86, so probably some regression > because I have not been testing on 32-bit host, and Raspbian is 32-bit. > > - After loading OSProcess/CommandShell, I was getting errors, something like > fork not being able to allocate memory. Sorry, I did not capture the error, > and it's gone now. > > - I then ran the OSP/CommandShell test suite. This crashed my login session > and took me to a login prompt. WTF?!? This is supposed to be impossible on > a Unix system. I'm still provisionally impressed with Raspbian, but ... > > - I logged back in and ran the OSP/CommandShell tests again. Everything looks > good now, except that tests related to file locking protocol are failing. > These are rarely used functions and may be linux distro dependent, so I'm > not worried about these failures. > > - RemoteTask seems to be working also. Nice. > > - Overall, most of the OSProcess functionality seems to be just working, so > that is a pleasant surprise. > > - I have gotten a few image lockups. I don't think it is related to OSProcess, > more likely that I am trying to use a "trunk level" V3 image, maybe a bit > buggy at this point. > > I will try setting up a Cog/Spur build next, and see what that looks like. > But probably not tonight :-) > > Dave > From timfelgentreff at gmail.com Fri Jun 17 07:15:55 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Fri Jun 17 07:16:17 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Hi Ben, Jakob is correct, but I think you were confused because Github also allows you to use SVN against any of their repositories. However, both options are strongly discouraged, because SVN *cannot* handle the kinds of merges that Git is doing (because I would argue that SVN doesn't actually handle merges properly at all - it leaves all the work up to the developer). So using Github's SVN bridge on a repository where not everyone else also uses that bridge will bring a world of pain to all devs involved. cheers, Tim On 16 June 2016 at 18:51, Ben Coman wrote: > > On Fri, Jun 17, 2016 at 12:45 AM, Jakob Reschke > wrote: >> >> 2016-06-16 18:38 GMT+02:00 Ben Coman : >>> >>> btw, is anyone going to be using git-svn, or is everyone making the >>> big jump pure git? >> >> Correct me, but I think there is no point to using git-svn here >> because the main repository will be the git one. git-svn allows one to >> use the git interface and play around with local branches where the >> main repository is svn. > > Thanks. I think I've misunderstood this the whole time, that you > could use svn commands against the github repository. > cheers -ben From timfelgentreff at gmail.com Fri Jun 17 07:18:02 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Fri Jun 17 07:18:24 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Hi Laura, we will update the README to carify this, but yes, the Github workflow of forking and submitting pull requests should be preferred. The CI will test all changes, we can discuss on the pull requests and so on. People who continue to contribute will eventually be promoted to core contributors so they can work on the main repository, but the nice thing is that the workflow on Github with forks isn't actually very different either :) cheers, Tim On 16 June 2016 at 19:37, Eliot Miranda wrote: > Hi Laura, Hi Tim, > > On Thu, Jun 16, 2016 at 10:09 AM, Laura Perez Cerrato > wrote: >> >> >> Hi everyone, >> >> First of all, thanks a lot! >> >> Meaning to ask the same question as Serge, what's the preferred way of >> collaborating for anyone who's not a contributor? forking and then >> submitting a pull request? > > > thats on you, Tim, and I to update the README.md with a description of the > contributor and change staging process. I'm going to be checking out the > repository for the first time in a few minutes. I guess we can bat aroun > drafts between us using git itself, but perhaps email would be more sensible > ;-) > > >> >> >> Cheers! >> >> -Laura Perez Cerrato >> >> On 16 June 2016 at 06:10, Serge Stinckwich >> wrote: >>> >>> >>> On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff >>> wrote: >>> > Hi all, >>> >>> Very impressive work, Tim&Fabio ! The power of full-automation ! >>> >>> > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 >>> > was >>> > migrated to GitHub. Automatic builds are running >>> > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, >>> > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are >>> > uploaded >>> > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). >>> >>> About uploading binary artifacts, this is something I asked and this >>> nice that Fabio >>> make it work :-) >>> >>> Apparently there is some problems with some artifacts that have a >>> double .zip extension. >>> >>> > Right now we have enabled all platform, object memory and bytecode set >>> > combinations that I found build scripts for - most work, but OS X >>> > 64-bit >>> > Sista is failing right now (32-bit works). At some point we'll have to >>> > decide which combinations to put into the CI config as "allowed >>> > failures" to >>> > get a green badge :) >>> > >>> > Another thing for those not familiar with Git: Right now the entire >>> > repository is 360MB, including all history. Most of that is old images >>> > that >>> > were at one point committed to SVN and that have been pulled into the >>> > repository. We could clean those out (removing them from the history) >>> > to >>> > make the repository smaller, but I felt ~400MB is still ok (albeit >>> > technically over the Github quota. We'll see of they complain). I would >>> > like >>> > to ask everyone to stop committing large binary files into the >>> > repository, >>> > however. Git is simply not very suited to dealing with binaries. If >>> > there is >>> > a need for that, Github has support for git-lfs, which offers 1GB of >>> > free >>> > storage with a 1GB bandwith limit per month. If we need more, we can >>> > look at >>> > the different billing levels. >>> > >>> > If you're familiar with Git, the only new thing to watch out for is the >>> > updateSCSSVersions script as described in the README. It's not relevant >>> > for >>> > the CI, but your own binaries will only show correct versions if this >>> > script >>> > runs at appropriate times. >>> > >>> > If you are not familiar with Git and don't care, there are scripts for >>> > committing that should take care of everything as described in the >>> > README. >>> > Again, let us know if anything doesn't work. The only difference vs SVN >>> > to >>> > watch out for for you will be that the old scripts/svnci would commit >>> > your >>> > changes to the server, whereas the scripts/gitci script only commits >>> > them >>> > locally. You'll have to run `git pull` and `git push` to get them up to >>> > the >>> > server. >>> > >>> > If you have any questions regarding the repository setup please don't >>> > hesitate to ask. You shouldn't be able to break anything, since we've >>> > disabled force pushes to both master and Cog (and thus any chance of >>> > destroying history). >>> >>> What is favorite way of contributing for people outside the vm team ? >>> pull-requests ? >>> >>> Regards, >>> -- >>> Serge Stinckwich >>> UCBN & UMI UMMISCO 209 (IRD/UPMC) >>> Every DSL ends up being Smalltalk >>> http://www.doesnotunderstand.org/ >> >> >> > > > > -- > _,,,^..^,,,_ > best, Eliot From timfelgentreff at gmail.com Fri Jun 17 07:22:00 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Fri Jun 17 07:22:21 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: Message-ID: Hi Eliot, how secure does this need to be? One way to differentiate the official VMs is to sign them directly on Travis (which we'll want to do anyway, just didn't get to it, yet). Another option is to just change the URL replacement code to do something else when not running on Travis --- like adding your hostname and path instead --- but this could be fairly easily messed with. Not sure how much malicious intent we want to prevent. cheers, Tim On 16 June 2016 at 22:07, Eliot Miranda wrote: > Hi All, > > so after fixing "git remote get-url origin" to fail over to "git remote > show origin | filter and munge" the culture shock of "git commit -a" (git > commit does nothing ?!?!?) I have a VM that outputs a reasonable version > info: > > /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak > 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: > 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.1886 uuid: > d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: > d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 > VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 > 12:53:33 2016 -0700 $ > Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ > > Which begs the question how do I differentiate this from something built > officially via Travis? Arguably the URL is wrong, and should only say > "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should > just include my local hostname and current directory when I make any kind of > local modification. So the above would read > > ... > VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 > 2016 -0700 $ > Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ > > Alternatively we could add another field, or modify one of the existing > fields to say "I'm official" however one would do that. I don't know how, I > just know we need this. I shouldn't be able to pollute the VM pool by > putting some VM on some site somewhere that i just happened to build after > several sherries and some cannabis brownies that looks to all intents and > purposes just like a VM built by our official Travis slaves. Hic. Chillin' > > _,,,^..^,,,_ > best, Eliot > > > From eliot.miranda at gmail.com Fri Jun 17 07:40:26 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 07:40:31 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: Message-ID: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Hi Tim, > On Jun 17, 2016, at 12:22 AM, Tim Felgentreff wrote: > > > Hi Eliot, > > how secure does this need to be? One way to differentiate the official > VMs is to sign them directly on Travis (which we'll want to do anyway, > just didn't get to it, yet). > > Another option is to just change the URL replacement code to do > something else when not running on Travis --- like adding your > hostname and path instead --- but this could be fairly easily messed > with. > > Not sure how much malicious intent we want to prevent. None. I don't think there's malicious intent at all. I do think we should differentiate between "personal" and Travis builds. It's more for my own information, so u don't get confused, than to prevent maliciousness. So do the simplest thing that could possibly work TSTTCPW. I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm (path relative to ~eliot). > > cheers, > Tim > >> On 16 June 2016 at 22:07, Eliot Miranda wrote: >> Hi All, >> >> so after fixing "git remote get-url origin" to fail over to "git remote >> show origin | filter and munge" the culture shock of "git commit -a" (git >> commit does nothing ?!?!?) I have a VM that outputs a reasonable version >> info: >> >> /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak >> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: >> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] >> CoInterpreter VMMaker.oscog-eem.1886 uuid: >> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: >> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 >> 12:53:33 2016 -0700 $ >> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ >> >> Which begs the question how do I differentiate this from something built >> officially via Travis? Arguably the URL is wrong, and should only say >> "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should >> just include my local hostname and current directory when I make any kind of >> local modification. So the above would read >> >> ... >> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 >> 2016 -0700 $ >> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ >> >> Alternatively we could add another field, or modify one of the existing >> fields to say "I'm official" however one would do that. I don't know how, I >> just know we need this. I shouldn't be able to pollute the VM pool by >> putting some VM on some site somewhere that i just happened to build after >> several sherries and some cannabis brownies that looks to all intents and >> purposes just like a VM built by our official Travis slaves. Hic. Chillin' >> >> _,,,^..^,,,_ >> best, Eliot >> >> >> From eliot.miranda at gmail.com Fri Jun 17 07:42:59 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 07:43:04 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <20160617014053.GA17233@shell.msen.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> Message-ID: <722D29DB-EC9F-4A14-8F3B-624D94543C00@gmail.com> Hi David, > On Jun 16, 2016, at 6:40 PM, David T. Lewis wrote: > > >> On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: >> >> I finally got a moment to look at this - not that I really have much clue >> about the whole unix process thing - and it appears that something is odd >> with the compiled code in the plugin. >> >> My test is very simple - run the UnixProcess class>listDirectory example. >> It exits with a segfault and the forkAndExec??? method as the last thing >> on the stack. >> >> I build a debug vm (and had some fun with asserts and the ARM fp offset in >> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling >> the plugin with varying levels of optimisation, since we???ve fairly regularly >> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. >> Nice. >> >> Ideas? > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and > setup advice). Very cool. My only usability complaint is that the TV monitor > is in the next room, so I am getting a stiff neck trying to look at the monitor > while I type on my chiclet keyboard here in the kitchen. But it works, and it > is a real computer. I recommend you either set up a VNC server on the Pi and VNC in or use X11. I never attach a monitor to the Pi except during setup. > > I started by compiling an interpreter VM to run against "trunk level" V3 image > with OSProcess/CommandShell loaded. What I found so far: > > - The 32-bit VM running 64-bit image does not work, cannot load X11 driver. > This used to work 6 or 8 years ago on 64 bit x86, so probably some regression > because I have not been testing on 32-bit host, and Raspbian is 32-bit. > > - After loading OSProcess/CommandShell, I was getting errors, something like > fork not being able to allocate memory. Sorry, I did not capture the error, > and it's gone now. > > - I then ran the OSP/CommandShell test suite. This crashed my login session > and took me to a login prompt. WTF?!? This is supposed to be impossible on > a Unix system. I'm still provisionally impressed with Raspbian, but ... > > - I logged back in and ran the OSP/CommandShell tests again. Everything looks > good now, except that tests related to file locking protocol are failing. > These are rarely used functions and may be linux distro dependent, so I'm > not worried about these failures. > > - RemoteTask seems to be working also. Nice. > > - Overall, most of the OSProcess functionality seems to be just working, so > that is a pleasant surprise. > > - I have gotten a few image lockups. I don't think it is related to OSProcess, > more likely that I am trying to use a "trunk level" V3 image, maybe a bit > buggy at this point. > > I will try setting up a Cog/Spur build next, and see what that looks like. > But probably not tonight :-) > > Dave > From eliot.miranda at gmail.com Fri Jun 17 07:47:38 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 07:47:47 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Hi Tim, > On Jun 17, 2016, at 12:09 AM, Tim Felgentreff wrote: > > > Hi Eliot, > > we can nuke the history, but everyone will have to re-clone the > repository. Fabio and I will do it today, before everyone gets busy on > the new repo. > > About the images you mention that are supposed to be there: These > *will* cause problems down the road. There is no way we can keep > removing them from history when new versions come to replace them, and > still maintain a sensible collaborative development approach. > Rewriting history to remove this will cause problems for everyone > involved. These binary files really shouldn't be in Git at all. As far as I'm concerned there should be /no/ image or changes files in the repo. I can't speak to eg the iPhone image, only the ones in the image directory. So don't read that I think any of them should be there :-). IMO nuke them all. Anyone want to defend one of the images b4 it's too late???? Heh heh heh... > > cheers, > Tim > >> On 16 June 2016 at 20:24, Eliot Miranda wrote: >> >> >> Hi Bert, >> >>> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg wrote: >>> >>> >>>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda wrote: >>>> >>>> >>>> Hi All, >>>> >>>>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >>>>> What is the advantage of this? The 44 .image files stored in the >>>>> repository take up 196MB, doubling the space. >>>> >>>> What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. >>>> >>>> So please, list these image files here... >>> >>> >>> Here's a list of all the blobs larger than 1 MB: >> >> >> Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. To be clear >> >> image/VMMaker-Squeak4.1.image >> image/VMMaker-Squeak4.1.changes (if it exists) >> image/CogTrunk43.image >> image/CogTrunk43.changes >> >> should exist. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? >> >>> >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >>> 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >>> 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >>> >>> - Bert - >> >> >> _,,,^..^,,,_ >> best, Eliot >> From kilon.alios at gmail.com Fri Jun 17 08:18:32 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Fri Jun 17 08:18:45 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Message-ID: if you dont want to worry about the technically details of Git I highly advise using some of the excellent git gui clients , I use GitUP which greatly simplifies git http://gitup.co/ On Fri, Jun 17, 2016 at 10:47 AM Eliot Miranda wrote: > > Hi Tim, > > > > On Jun 17, 2016, at 12:09 AM, Tim Felgentreff > wrote: > > > > > > Hi Eliot, > > > > we can nuke the history, but everyone will have to re-clone the > > repository. Fabio and I will do it today, before everyone gets busy on > > the new repo. > > > > About the images you mention that are supposed to be there: These > > *will* cause problems down the road. There is no way we can keep > > removing them from history when new versions come to replace them, and > > still maintain a sensible collaborative development approach. > > Rewriting history to remove this will cause problems for everyone > > involved. These binary files really shouldn't be in Git at all. > > As far as I'm concerned there should be /no/ image or changes files in the > repo. I can't speak to eg the iPhone image, only the ones in the image > directory. So don't read that I think any of them should be there :-). IMO > nuke them all. Anyone want to defend one of the images b4 it's too > late???? Heh heh heh... > > > > > cheers, > > Tim > > > >> On 16 June 2016 at 20:24, Eliot Miranda > wrote: > >> > >> > >> Hi Bert, > >> > >>> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg < > bert@freudenbergs.de> wrote: > >>> > >>> > >>>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda < > eliot.miranda@gmail.com> wrote: > >>>> > >>>> > >>>> Hi All, > >>>> > >>>>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: > >>>>> What is the advantage of this? The 44 .image files stored in the > >>>>> repository take up 196MB, doubling the space. > >>>> > >>>> What are the images? IIRC there are no images in the svn repo. The > only big files are sources files for various key squeak and Pharo > releases. Did I check in images in the images directory by mistake? There > should be nine there; they're to be downloaded and built/converted, not > checked into the repository. > >>>> > >>>> So please, list these image files here... > >>> > >>> > >>> Here's a list of all the blobs larger than 1 MB: > >> > >> > >> Thanks. None of those image (or associated changes) files should exist > in image/. None of them exist in the svn repository. How did they creep > in? Some who's already up and running might like to nuke them and commit > them to the master asap. To be clear > >> > >> image/VMMaker-Squeak4.1.image > >> image/VMMaker-Squeak4.1.changes (if it exists) > >> image/CogTrunk43.image > >> image/CogTrunk43.changes > >> > >> should exist. Is this history pruning issue? Ah, that's what must > have happened. They were in svn at one time, and so have got copied in as > part of moving the entire history. So... anyone know enough git internals > to prune this part of the history? > >> > >>> > >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 > image/VMMaker-Squeak4.1.image > >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 > sources/SqueakV46.sources > >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 > image/CogTrunk43.image > >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 > image/CogTrunk43.changes > >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 > image/CogTrunk43.image > >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 > platforms/iOS/vm/iPhone/iPhone.image > >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 > image/VMMaker-Squeak4.1.image > >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 > image/VMMaker-Squeak4.1.image > >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 > image/VMMaker-Squeak4.1.image > >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 > FloatMathPlugin/testdata/log-large.dat > >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 > FloatMathPlugin/testdata/sqrt-large.dat > >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 > FloatMathPlugin/testdata/exp-large.dat > >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 > FloatMathPlugin/testdata/atan-large.dat > >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 > FloatMathPlugin/testdata/sin-large.dat > >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 > platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib > >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols > >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 > platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib > >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 > platforms/iOS/vm/iPhone/iPhone.changes > >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 > processors/ARM/gdb-7.10/opcodes/i386-tbl.h > >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 > processors/ARM/gdb-7.10/opcodes/m32c-desc.c > >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 > platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser > >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 > processors/ARM/gdb-7.10/opcodes/m32c-opc.c > >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 > platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib > >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 > processors/ARM/gdb-7.10/sim/frv/model.c > >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 > platforms/win32/plugins/FT2Plugin/freetype.a > >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 > nsspur64src/vm/gcc3x-cointerp.c > >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 > nsspur64src/vm/cointerp.c > >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 > spursistasrc/vm/gcc3x-cointerp.c > >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 > spur64src/vm/cointerp.c > >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 > spur64src/vm/cointerp.c > >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 > nsspurstack64src/vm/gcc3x-interp.c > >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 > nsspurstack64src/vm/interp.c > >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 > nsspurstacksrc/vm/interp.c > >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 > spursrc/vm/gcc3x-cointerp.c > >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 > platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib > >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols > >>> 440955ce2200921b12153427645b8b191f8519be 2190822 > nsspurstacksrc/vm/gcc3x-interp.c > >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 > spursistasrc/vm/cointerp.c > >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 > platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib > >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings > >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control > >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 > spurstacksrc/vm/interp.c > >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 > spursrc/vm/gcc3x-cointerp.c > >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 > nsspurstacksrc/vm/gcc3x-interp.c > >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm > >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 > nsspurstacksrc/vm/gcc3x-interp.c > >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c > >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 > src/vm/gcc3x-cointerpmt.c > >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c > >>> 965a8b480996779d2345ca314707408c4471d808 1820909 > spursrc/vm/gcc3x-cointerp.c > >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 > spursrc/vm/gcc3x-cointerp.c > >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c > >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 > src/vm/gcc3x-cointerp.c > >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c > >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c > >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 > processors/ARM/gdb-7.10/Makefile.in > >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 > spurstacksrc/vm/interp.c > >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 > spurstacksrc/vm/gcc3x-interp.c > >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 > nscogsrc/vm/gcc3x-cointerp.c > >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 > src/vm/gcc3x-cointerpmt.c > >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c > >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 > nscogsrc/vm/gcc3x-cointerp.c > >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S > >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 > processors/ARM/gdb-7.6/Makefile.in > >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 > src/vm/gcc3x-cointerp.c > >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S > >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c > >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 > spurstacksrc/vm/interp.c > >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 > stacksrc/vm/gcc3x-interp.c > >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c > >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 > stacksrc/vm/gcc3x-interp.c > >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 > platforms/win32/plugins/CameraPlugin/STRMBASE.lib > >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 > build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin > >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 > processors/IA32/bochs/build/macos/CWPro3_project.sit > >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 > processors/IA32/bochs/configure > >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 > build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp > >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac > >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 > spursistasrc/vm/cogitARMv5.c > >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 > processors/ARM/gdb-7.10/opcodes/i386-opc.tbl > >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 > processors/ARM/gdb-7.10/opcodes/m32c-opc.h > >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 > stacksrc/vm/gcc3x-interp.c > >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 > spursistasrc/vm/cogitIA32.c > >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree > >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control > >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 > spursistasrc/vm/cogitMIPSEL.c > >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 > spursistasrc/vm/cogitMIPSEL.c > >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 > platforms/unix/config/configure > >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac > >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 > nsspur64src/vm/cogitX64.c > >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 > processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s > >>> > >>> - Bert - > >> > >> > >> _,,,^..^,,,_ > >> best, Eliot > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/0aa47f31/attachment-0001.htm From pbpublist at gmail.com Fri Jun 17 09:33:45 2016 From: pbpublist at gmail.com (Phil (list)) Date: Fri Jun 17 09:33:50 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <20160617014053.GA17233@shell.msen.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> Message-ID: <1466156025.19725.68.camel@gmail.com> On Thu, 2016-06-16 at 21:40 -0400, David T. Lewis wrote: >? > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the > shopping and > setup advice). Very cool. My only usability complaint is that the TV > monitor > is in the next room, so I am getting a stiff neck trying to look at > the monitor > while I type on my chiclet keyboard here in the kitchen. But it > works, and it > is a real computer. >? You can use it with a regular computer monitor assuming you have an extra one lying around with HDMI input (or a DVI->HDMI adapter, also you might need to disable overscan in the config file.) ?You can also setup ssh / VNC / remote X11 like any other Linux box for headless operation. ?My biggest complaint is the things have no power/reset switch out of the box (it is possible to add via a DIY mod) but other than that, it's a quite useful little device for Smalltalk! From lewis at mail.msen.com Fri Jun 17 11:54:01 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 17 11:54:02 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> Message-ID: <20160617115401.GA36464@shell.msen.com> Thanks Tim, I'll try the bintray.com builds, that helps. But I do also want to compile my own Cog/Spur VMs. That's the main reason I got the Pi, it is inexpensive enough that it was silly not to just get one and try it :-) Dave On Fri, Jun 17, 2016 at 09:12:56AM +0200, Tim Felgentreff wrote: > > Dave, > > there are builds for Raspbian on our new bintray page. If all you want > is the latest version, you should be able to just use these, no need > to compile yourself: > https://bintray.com/opensmalltalk/vm/cog/201606161953/view#files > > cheers, > Tim > > On 17 June 2016 at 03:40, David T. Lewis wrote: > > > > On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: > >> > >> I finally got a moment to look at this - not that I really have much clue > >> about the whole unix process thing - and it appears that something is odd > >> with the compiled code in the plugin. > >> > >> My test is very simple - run the UnixProcess class>listDirectory example. > >> It exits with a segfault and the forkAndExec??? method as the last thing > >> on the stack. > >> > >> I build a debug vm (and had some fun with asserts and the ARM fp offset in > >> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling > >> the plugin with varying levels of optimisation, since we???ve fairly regularly > >> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. > >> Nice. > >> > >> Ideas? > >> > > > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and > > setup advice). Very cool. My only usability complaint is that the TV monitor > > is in the next room, so I am getting a stiff neck trying to look at the monitor > > while I type on my chiclet keyboard here in the kitchen. But it works, and it > > is a real computer. > > > > I started by compiling an interpreter VM to run against "trunk level" V3 image > > with OSProcess/CommandShell loaded. What I found so far: > > > > - The 32-bit VM running 64-bit image does not work, cannot load X11 driver. > > This used to work 6 or 8 years ago on 64 bit x86, so probably some regression > > because I have not been testing on 32-bit host, and Raspbian is 32-bit. > > > > - After loading OSProcess/CommandShell, I was getting errors, something like > > fork not being able to allocate memory. Sorry, I did not capture the error, > > and it's gone now. > > > > - I then ran the OSP/CommandShell test suite. This crashed my login session > > and took me to a login prompt. WTF?!? This is supposed to be impossible on > > a Unix system. I'm still provisionally impressed with Raspbian, but ... > > > > - I logged back in and ran the OSP/CommandShell tests again. Everything looks > > good now, except that tests related to file locking protocol are failing. > > These are rarely used functions and may be linux distro dependent, so I'm > > not worried about these failures. > > > > - RemoteTask seems to be working also. Nice. > > > > - Overall, most of the OSProcess functionality seems to be just working, so > > that is a pleasant surprise. > > > > - I have gotten a few image lockups. I don't think it is related to OSProcess, > > more likely that I am trying to use a "trunk level" V3 image, maybe a bit > > buggy at this point. > > > > I will try setting up a Cog/Spur build next, and see what that looks like. > > But probably not tonight :-) > > > > Dave > > From lewis at mail.msen.com Fri Jun 17 12:03:25 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 17 12:03:28 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <722D29DB-EC9F-4A14-8F3B-624D94543C00@gmail.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <722D29DB-EC9F-4A14-8F3B-624D94543C00@gmail.com> Message-ID: <20160617120325.GB36464@shell.msen.com> On Fri, Jun 17, 2016 at 12:42:59AM -0700, Eliot Miranda wrote: > > Hi David, > > > > On Jun 16, 2016, at 6:40 PM, David T. Lewis wrote: > > > > > >> On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: > >> > >> I finally got a moment to look at this - not that I really have much clue > >> about the whole unix process thing - and it appears that something is odd > >> with the compiled code in the plugin. > >> > >> My test is very simple - run the UnixProcess class>listDirectory example. > >> It exits with a segfault and the forkAndExec??? method as the last thing > >> on the stack. > >> > >> I build a debug vm (and had some fun with asserts and the ARM fp offset in > >> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling > >> the plugin with varying levels of optimisation, since we???ve fairly regularly > >> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. > >> Nice. > >> > >> Ideas? > > > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and > > setup advice). Very cool. My only usability complaint is that the TV monitor > > is in the next room, so I am getting a stiff neck trying to look at the monitor > > while I type on my chiclet keyboard here in the kitchen. But it works, and it > > is a real computer. > > I recommend you either set up a VNC server on the Pi and VNC in or use > X11. I never attach a monitor to the Pi except during setup. > Thanks Eliot, I'll do that. I was partly making fun of myself fumbling around trying to put the pieces together for the first time. Remember that classic old video (from DEC research labs I think?) showing a first time user trying to insert a floppy disk into a PC? That was me setting up my new Pi ;-) Dave From lists at fniephaus.com Fri Jun 17 12:47:02 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Fri Jun 17 12:47:17 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- 35c031a09d98dc08484156c3ce54b136f756474e 17864140 CogTrunk43.changes 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 CogTrunk43.changes 17ae0daff2486d8103218105f7050587c0f0dbd4 17864315 CogTrunk43.changes 539898aed0f8d0f1b435eb3b68a27915cefbb99a 21109928 CogTrunk43.image 2c74b720358234a061e8a6fbcb4450684b917527 23188396 CogTrunk43.image 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 CogTrunk43.image e941ef38100dbfbe461832d803b478b1b3c32ba7 26002240 SqueakV41.sources dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 SqueakV46.sources c37c646132ab5d87bccf1342f2aa8d2072e331fa 35184983 SqueakV50.sources ea99befa8b44c00e3867c43ba074b47259b4b6e9 8058370 VMMaker-Squeak4.1.changes 5ce7d315b52bee2ca6e8265b2107407336cc8ef1 7348370 VMMaker-Squeak4.1.changes 8d7eb75365ff3d70ec257cd5671f5df471807667 8052007 VMMaker-Squeak4.1.changes 6305903da7f9f94f462715c9c719e1c88633de13 7357389 VMMaker-Squeak4.1.changes d79e94bbc399451467b5f3a3e0cf73729ea0d1ae 8094995 VMMaker-Squeak4.1.changes 28df003453b6e3b42c6633a4014cb30b209e220c 7358802 VMMaker-Squeak4.1.changes 0f44a3beefb19816d45cb04602c555631631943e 13949664 VMMaker-Squeak4.1.image 7ec7768a0c08551bc7f7e3e93134ea0f5bebeddb 13956700 VMMaker-Squeak4.1.image 6395bc4b9c1bc8f6f258b596c3f7c15fa53b5072 13940504 VMMaker-Squeak4.1.image 226436fd59f9bc69ef09ea93cd54d7dbeca6b29d 13226828 VMMaker-Squeak4.1.image 4f5e60f1a05557abbb846cbf9e9975a6a5800c51 65800920 VMMaker-Squeak4.1.image 0b6902d893b599375cebbaf23bcbd9ff0b1e89b9 13942288 VMMaker-Squeak4.1.image 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 VMMaker-Squeak4.1.image 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 VMMaker-Squeak4.1.image d54c5fbc4c1517b21715ce9221078dfb323b4e1f 37403596 VMMaker-Squeak4.1.image 5bf020da6ac707561449f637dc788cced6ab3009 14173040 VMMaker-Squeak4.1.image 6ef85dd743b6c7ae82a48f925cd959502e4c0e0f 14189628 VMMaker-Squeak4.1.image ab90ab30a4585c05711b24df644a47c994cd59fe 65740316 VMMaker-Squeak4.1.image e5af70c52ec3a4b25b31bef1f925a9675ec2a6b7 13909356 VMMaker-Squeak4.1.image 059f54b82978abae78513d89deabeb510c1dd9f3 30829896 VMMaker-Squeak4.1.image 24033f357e54db9c73866b542111f7c12583cc17 13394412 VMMaker-Squeak4.1.image e12bc3e5f5d5ba76935e6d35a540a654d5ff47fb 14173236 VMMaker-Squeak4.1.image e06874ecb8f15237e42dfeb708cf1423c06de3bb 13320132 VMMaker-Squeak4.1.image 287e9c15719caf266fe9b75fca5c9f15537c175a 13239552 VMMaker-Squeak4.1.image 1a606437ad2e83716fbc0c8dcc9f35552110f5c5 68419116 VMMaker-Squeak4.1.image 34018b584fc470bf0f1c948b877f2ef762baff2d 13967160 VMMaker-Squeak4.1.image 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 VMMaker-Squeak4.1.image 1687fc07749a9124c3f82594c2384748a774228b 14197920 VMMaker-Squeak4.1.image 8eef3a6a50549e139611348453ccb529faada2cc 72769176 VMMaker-Squeak4.1.image e5e8c16802ca6b562f81e7e28754268d498b8819 13378460 VMMaker-Squeak4.1.image cef78f45e6c6d44ec291c209498debdba5d778dc 13227144 VMMaker-Squeak4.1.image 12127247c3d231022560a14423e6642167007cba 72847232 VMMaker-Squeak4.1.image 4090d9b321eee4fb69aff1e938fa520fcbd1b8ed 13275384 VMMaker-Squeak4.1.image feba79f6c750f45eacc655c25e3dcc00d57b7240 31382524 VMMaker-Squeak4.1.image 7f7a6f8262488a839714e7294b68f29de1f568d8 24294696 VMMaker-Squeak4.1.image 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 VMMaker-Squeak4.1.image 4afa3499bbb139f7acb233ed87b73efe6d85bc80 37559040 VMMaker-Squeak4.1.image 79f8806a40b2cb94ea858fb4f104aeeece228463 14193188 VMMaker-Squeak4.1.image 5dbbe2c449af84d72434566c72ec1aa48c5b6afa 19811288 VMMaker-Squeak4.1.image f5c8eb8eb46e4614338ef993bc23f58b3c0bcca8 25576980 VMMaker-Squeak4.1.image cdb9c0505216f621b868c214593662a5ad3c3aa3 28697636 VMMaker-Squeak4.1.image 4e4f671cb8d77533cf1c6b38f18b33920c2743bd 13236228 VMMaker-Squeak4.1.image 975b01ed0a06d951328951419a8a231e143577ae 14050756 VMMaker-Squeak4.1.image 77c28fa8d41ac4687b29a0e35501a012c9f7c8be 18672984 VMMaker-Squeak4.1.image 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 atan-large.dat 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 exp-large.dat ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 iPhone.image 535d87a271835e9f7a808fdb9a83022405d73b06 20186596 iPhone.image e0dc54f1428dc6df9b8c9149e2934c49f0525cab 18277000 iPhone.image b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 log-large.dat 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 sin-large.dat 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 sqrt-large.dat From karlramberg at gmail.com Fri Jun 17 13:22:52 2016 From: karlramberg at gmail.com (karl ramberg) Date: Fri Jun 17 13:23:02 2016 Subject: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Will Win x64 VM be built also ? Best, Karl On Wed, Jun 15, 2016 at 7:26 PM, Eliot Miranda wrote: > > Hi all, > > we are all finished importing the VM repository to Github, migrating the > scripts, and setting up automatic builds and hosting of binaries. We > want to switch over from SVN tomorrow morning at 7am UTC. At that point, > Tim and Fabio will merge any remaining commits on the SVN repository between > now and that time and any further development will take place on Github. > If possible, you may refrain from committing to SVN, as this will mean > less work for Tim and Fabio. > > The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch > is the new default branch and is still called Cog, this is the main focus > of development. The old trunk branch has been renamed to "oldTrunk". The > master branch will track the Cog branch and will be the repository > integrated into for releases. > > To get started, please refer to the updated README > that is shown on the > Github page. > > _,,,^..^,,,_ > best, Eliot, Tim & Fabio > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/798bb10e/attachment.htm From henrik.s.johansen at veloxit.no Fri Jun 17 13:09:06 2016 From: henrik.s.johansen at veloxit.no (Henrik Sperre Johansen) Date: Fri Jun 17 13:48:40 2016 Subject: [Vm-dev] Re: Cog + Pi + OSProcess In-Reply-To: <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> Message-ID: <1466168946288-4901424.post@n4.nabble.com> tim Rowledge wrote > I?ve tried compiling the plugin with varying levels of optimisation, since > we?ve fairly regularly seen problems there, and even at -O0 it fails. So > debug -> OK, no-debug -> boom. Nice. > > Ideas? Just a thought, but reading the list of optimizations enabled with -O0 from https://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html, -f-omit-frame-pointer seems like a suspect that has caused problems before... Could it be the arm make files are missing -fno-omit-frame-pointer at some crucial place? Cheers, Henry -- View this message in context: http://forum.world.st/Cog-Pi-OSProcess-tp4893984p4901424.html Sent from the Squeak VM mailing list archive at Nabble.com. From bert at freudenbergs.de Fri Jun 17 14:00:59 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Fri Jun 17 14:01:01 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Message-ID: On Fri, Jun 17, 2016 at 2:47 PM, Fabio Niephaus wrote: > > Hi all, > > Tim and I just stripped all files from the repository that were larger > than 7M. These were images, changes, sources, and test files (a detailed > list is attached). Please clone the repository again. > For anyone wondering: I did a "git gc" before building the file list, that's probably why there were more images in Fabio's list. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/73e9989d/attachment.htm From eliot.miranda at gmail.com Fri Jun 17 14:10:32 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 14:10:38 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Message-ID: Hi Fabio, > On Jun 17, 2016, at 5:47 AM, Fabio Niephaus wrote: > > Hi all, > > Tim and I just stripped all files from the repository that were larger than 7M. These were images, changes, sources, and test files (a detailed list is attached). Please clone the repository again. > > You can find a backup of the sources files that were in /sources on the Cog/master branch at [1]. We have also updated the .gitignore to ignore *.image, *.changes, and *.sources globally. > > @Eliot: could you shed some light on how the sources files have been used? Instead of using git-lfs, it might be better to host large files somewhere (e.g. on Bintray since we are already using it) and to download them on demand. Some builds include sources files, such as Newwspeak. See eg build.macos32x86/newspeak.cog.spur/installer. I agree, downloading them would be best. But it would be great if they were available from one place rather than having to use URLs on various sites. Not important. Just convenient. > > On smaller systems, it might still be better to download the zip [2] or to only clone the last n commits via `git clone --depth n ...`. > > Best, > Fabio > > [1] https://bintray.com/opensmalltalk/assets/sources/svn-backup/view?sort=&order=#files > [2] e.g. https://github.com/OpenSmalltalk/vm/archive/master.zip > > > -- > >> On Fri, Jun 17, 2016 at 10:18 AM Dimitris Chloupis wrote: >> >> if you dont want to worry about the technically details of Git I highly advise using some of the excellent git gui clients , I use GitUP which greatly simplifies git >> >> http://gitup.co/ >> >> >> -- >> >>> On Fri, Jun 17, 2016 at 10:47 AM Eliot Miranda wrote: >>> >>> Hi Tim, >>> >>> >>> > On Jun 17, 2016, at 12:09 AM, Tim Felgentreff wrote: >>> > >>> > >>> > Hi Eliot, >>> > >>> > we can nuke the history, but everyone will have to re-clone the >>> > repository. Fabio and I will do it today, before everyone gets busy on >>> > the new repo. >>> > >>> > About the images you mention that are supposed to be there: These >>> > *will* cause problems down the road. There is no way we can keep >>> > removing them from history when new versions come to replace them, and >>> > still maintain a sensible collaborative development approach. >>> > Rewriting history to remove this will cause problems for everyone >>> > involved. These binary files really shouldn't be in Git at all. >>> >>> As far as I'm concerned there should be /no/ image or changes files in the repo. I can't speak to eg the iPhone image, only the ones in the image directory. So don't read that I think any of them should be there :-). IMO nuke them all. Anyone want to defend one of the images b4 it's too late???? Heh heh heh... >>> >>> > >>> > cheers, >>> > Tim >>> > >>> >> On 16 June 2016 at 20:24, Eliot Miranda wrote: >>> >> >>> >> >>> >> Hi Bert, >>> >> >>> >>> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg wrote: >>> >>> >>> >>> >>> >>>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda wrote: >>> >>>> >>> >>>> >>> >>>> Hi All, >>> >>>> >>> >>>>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >>> >>>>> What is the advantage of this? The 44 .image files stored in the >>> >>>>> repository take up 196MB, doubling the space. >>> >>>> >>> >>>> What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. >>> >>>> >>> >>>> So please, list these image files here... >>> >>> >>> >>> >>> >>> Here's a list of all the blobs larger than 1 MB: >>> >> >>> >> >>> >> Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. To be clear >>> >> >>> >> image/VMMaker-Squeak4.1.image >>> >> image/VMMaker-Squeak4.1.changes (if it exists) >>> >> image/CogTrunk43.image >>> >> image/CogTrunk43.changes >>> >> >>> >> should exist. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? >>> >> >>> >>> >>> >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image >>> >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources >>> >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >>> >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >>> >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >>> >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image >>> >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image >>> >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image >>> >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image >>> >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat >>> >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat >>> >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat >>> >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat >>> >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat >>> >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >>> >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >>> >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >>> >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes >>> >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h >>> >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c >>> >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >>> >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c >>> >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >>> >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c >>> >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a >>> >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c >>> >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >>> >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c >>> >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >>> >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >>> >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c >>> >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c >>> >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c >>> >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c >>> >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >>> >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >>> >>> 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c >>> >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c >>> >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >>> >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >>> >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >>> >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >>> >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c >>> >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c >>> >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >>> >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c >>> >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >>> >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >>> >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >>> >>> 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c >>> >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c >>> >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >>> >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >>> >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >>> >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >>> >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in >>> >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >>> >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c >>> >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c >>> >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >>> >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >>> >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c >>> >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >>> >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in >>> >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >>> >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >>> >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >>> >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >>> >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c >>> >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >>> >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c >>> >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib >>> >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >>> >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit >>> >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure >>> >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >>> >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >>> >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c >>> >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >>> >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h >>> >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c >>> >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c >>> >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >>> >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >>> >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c >>> >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c >>> >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure >>> >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >>> >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >>> >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >>> >>> >>> >>> - Bert - >>> >> >>> >> >>> >> _,,,^..^,,,_ >>> >> best, Eliot >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/63bca929/attachment-0001.htm From timfelgentreff at gmail.com Fri Jun 17 14:59:59 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Fri Jun 17 15:00:26 2016 Subject: [squeak-dev] Re: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: Message-ID: Hi Karl, As soon as there is a build script for one, yes :) cheers, Tim On 17 June 2016 at 15:22, karl ramberg wrote: > Will Win x64 VM be built also ? > > Best, > Karl > > On Wed, Jun 15, 2016 at 7:26 PM, Eliot Miranda > wrote: >> >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the >> scripts, and setting up automatic builds and hosting of binaries. We want >> to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and >> Fabio will merge any remaining commits on the SVN repository between now and >> that time and any further development will take place on Github. If >> possible, you may refrain from committing to SVN, as this will mean less >> work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog >> branch is the new default branch and is still called Cog, this is the main >> focus of development. The old trunk branch has been renamed to "oldTrunk". >> The master branch will track the Cog branch and will be the repository >> integrated into for releases. >> >> To get started, please refer to the updated README that is shown on the >> Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio >> > > > > From eliot.miranda at gmail.com Fri Jun 17 15:04:06 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 15:04:10 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <20160617120325.GB36464@shell.msen.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <722D29DB-EC9F-4A14-8F3B-624D94543C00@gmail.com> <20160617120325.GB36464@shell.msen.com> Message-ID: <693840FC-0A48-46F7-8EE8-4BDDC08CFD23@gmail.com> > On Jun 17, 2016, at 5:03 AM, David T. Lewis wrote: > > >> On Fri, Jun 17, 2016 at 12:42:59AM -0700, Eliot Miranda wrote: >> >> Hi David, >> >> >>> On Jun 16, 2016, at 6:40 PM, David T. Lewis wrote: >>> >>> >>>> On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: >>>> >>>> I finally got a moment to look at this - not that I really have much clue >>>> about the whole unix process thing - and it appears that something is odd >>>> with the compiled code in the plugin. >>>> >>>> My test is very simple - run the UnixProcess class>listDirectory example. >>>> It exits with a segfault and the forkAndExec??? method as the last thing >>>> on the stack. >>>> >>>> I build a debug vm (and had some fun with asserts and the ARM fp offset in >>>> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling >>>> the plugin with varying levels of optimisation, since we???ve fairly regularly >>>> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. >>>> Nice. >>>> >>>> Ideas? >>> >>> I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and >>> setup advice). Very cool. My only usability complaint is that the TV monitor >>> is in the next room, so I am getting a stiff neck trying to look at the monitor >>> while I type on my chiclet keyboard here in the kitchen. But it works, and it >>> is a real computer. >> >> I recommend you either set up a VNC server on the Pi and VNC in or use >> X11. I never attach a monitor to the Pi except during setup. > > Thanks Eliot, I'll do that. I was partly making fun of myself fumbling around > trying to put the pieces together for the first time. Remember that classic > old video (from DEC research labs I think?) showing a first time user trying > to insert a floppy disk into a PC? That was me setting up my new Pi ;-) :-). I can relate :-) > Dave From btc at openinworld.com Fri Jun 17 15:27:13 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 17 15:27:37 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda wrote: > >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff wrote: >> >>> On 16 June 2016 at 22:07, Eliot Miranda wrote: >>> Hi All, >>> >>> so after fixing "git remote get-url origin" to fail over to "git remote >>> show origin | filter and munge" the culture shock of "git commit -a" (git >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable version >>> info: >>> >>> /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 >>> 12:53:33 2016 -0700 $ >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ >>> >>> Which begs the question how do I differentiate this from something built >>> officially via Travis? Arguably the URL is wrong, and should only say >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should >>> just include my local hostname and current directory when I make any kind of >>> local modification. So the above would read >>> >>> ... >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 >>> 2016 -0700 $ >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ >>> >>> Alternatively we could add another field, or modify one of the existing >>> fields to say "I'm official" however one would do that. I don't know how, I >>> just know we need this. I shouldn't be able to pollute the VM pool by >>> putting some VM on some site somewhere that i just happened to build after >>> several sherries and some cannabis brownies that looks to all intents and >>> purposes just like a VM built by our official Travis slaves. Hic. Chillin' I just discovered git-describe, which seems like it could be useful... http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html So if Travis created "r201606161953" as an *official* tag for successful builds like this... https://github.com/travis-ci/travis-ci/issues/1476 then `git describe` would produce "r201606161953" for that build, and after a couple of commits in my personal repo would produce "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish non-official builds. In addition, I can now copy-paste a VM's output revision string to directly do "git checkout r201606161953" instead of "git checkout master@{2016-06-16 19:53} which I read is only viable for 90 days anyway, and has some complexity between whether the given date is author commit date or merge date. But after doing "git checkout r201606161953" in my personal repo git describe ==> r201606161953 is indistinguishable from the Travis build but... git describe --long ==> r201606161953-0-a264e03b is distinguishable. In addition, if I edit some files and rebuild before committing I want to distinguish this from when I build a fresh check out , which can be done with... git describe --long --dirty ==> r201606161953-0-a264e03b-dirty So that last would be used to version personal builds, while Travis would use "git describe" without any flags. ==> r201606161953 >> how secure does this need to be? One way to differentiate the official >> VMs is to sign them directly on Travis (which we'll want to do anyway, >> just didn't get to it, yet). >> >> Another option is to just change the URL replacement code to do >> something else when not running on Travis --- like adding your >> hostname and path instead --- but this could be fairly easily messed >> with. >> >> Not sure how much malicious intent we want to prevent. Later on we should have Travis signing its build artefacts, but for now keep it simple. > > None. I don't think there's malicious intent at all. I do think we should differentiate between "personal" and Travis builds. It's more for my own information, so u don't get confused, than to prevent maliciousness. So do the simplest thing that could possibly work TSTTCPW. I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm (path relative to ~eliot). I think `git branch` is as important as `path`. Username could come from `git config user.name | sed 's/ //g' cheers -ben From tim at rowledge.org Fri Jun 17 16:47:16 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 17 16:47:05 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <20160617014053.GA17233@shell.msen.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> Message-ID: <591969F5-84C5-4D02-A95F-2BEE32B4790B@rowledge.org> > On 16-06-2016, at 6:40 PM, David T. Lewis wrote: > > > On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: >> >> I finally got a moment to look at this - not that I really have much clue >> about the whole unix process thing - and it appears that something is odd >> with the compiled code in the plugin. >> >> My test is very simple - run the UnixProcess class>listDirectory example. >> It exits with a segfault and the forkAndExec??? method as the last thing >> on the stack. >> >> I build a debug vm (and had some fun with asserts and the ARM fp offset in >> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling >> the plugin with varying levels of optimisation, since we???ve fairly regularly >> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. >> Nice. >> >> Ideas? >> > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and > setup advice). Very cool. My only usability complaint is that the TV monitor > is in the next room, so I am getting a stiff neck trying to look at the monitor > while I type on my chiclet keyboard here in the kitchen. But it works, and it > is a real computer. As previously mentioned I use xrdp to solve this. The only issue it causes me is having to use ?sudo? in a lot of places you might not expect; running Squeak is almost understandable (though you don?t need it when running a direct display) but needing it to make a vm is crazy, but the ?install? part simply won?t work without it. > > I started by compiling an interpreter VM to run against "trunk level" V3 image > with OSProcess/CommandShell loaded. What I found so far: > > - The 32-bit VM running 64-bit image does not work, cannot load X11 driver. > This used to work 6 or 8 years ago on 64 bit x86, so probably some regression > because I have not been testing on 32-bit host, and Raspbian is 32-bit. Yup, an will stay that way for a while at least, even on the 64 bit ARM v8. > > - After loading OSProcess/CommandShell, I was getting errors, something like > fork not being able to allocate memory. Sorry, I did not capture the error, > and it's gone now. > Is it possible that we are simply grabbing too much address space and the fork fails because of that? I know the images are tiny by today?s standards - I swear my camera sometime produces image file bigger than my .image files - but how much address space are we grabbing? I can?t find any notes but I?m pretty sure there was a time when the Scratch ?help? couldn?t work because the OS couldn?t find enough memory to fire up the web browser. > - I then ran the OSP/CommandShell test suite. This crashed my login session > and took me to a login prompt. WTF?!? This is supposed to be impossible on > a Unix system. I'm still provisionally impressed with Raspbian, but ? I?ve never been massively impressed with the claims of unix perfection. I?ve been able to lock up and crash both applications on, and actual unices on ppc, x86, ARM, HPPA, 68k etc etc. > > > I will try setting up a Cog/Spur build next, and see what that looks like. > But probably not tonight :-) If using xrdp, you?ll need to use `sudo ./mvm` etc. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPE: Create Parity Error From tim at rowledge.org Fri Jun 17 16:52:01 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 17 16:51:49 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <1466156025.19725.68.camel@gmail.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <1466156025.19725.68.camel@gmail.com> Message-ID: <45B6BA88-D918-460C-9F16-C97D905EFE9E@rowledge.org> > On 17-06-2016, at 2:33 AM, Phil (list) wrote: > > My biggest complaint is the things have no power/reset > switch out of the box (it is possible to add via a DIY mod) but other > than that, it's a quite useful little device for Smalltalk! I?m inclined to agree, but my attempted solution is to start work on a HAT that would provide a) power input from a wider range of PSUs with a switchmode regulator etc b) cooling (for heavily worked Pi3?s particularly - I did manage to work one so hard it just shut down) c) power/reboot switch d) (maybe) a basic ADC e) (maybe) some other small missing item It?s very up in the air right now, might be a first attempt at a kickstarter etc. Anyone here interested? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind. From lists at fniephaus.com Fri Jun 17 16:52:02 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Fri Jun 17 16:52:15 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: <54F07109-67A6-4882-BC6F-E6FA9FD7ABB1@smalltalkconsulting.com> References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <54F07109-67A6-4882-BC6F-E6FA9FD7ABB1@smalltalkconsulting.com> Message-ID: Hi John, -- On Thu, Jun 16, 2016 at 7:50 PM John McIntosh < johnmci@smalltalkconsulting.com> wrote: > > > OS X 64-bit > > Sista fails > > > Need some pointers so I can debug this > Here's the failing build: https://travis-ci.org/OpenSmalltalk/vm/jobs/138342179#L73 According to [1], there is supposed to be a [2]. There isn't, but there is a [3]. So I'm assuming that 64bit spursista has not been implemented yet (same with Linux 64bit). I will disable OS X 64-bit Spur Sista builds for now. [1] https://github.com/OpenSmalltalk/vm/blob/56c4157d4a41fbc6d8f98e241c4eec954d15ebd2/build.macos64x64/squeak.sista.spur/Makefile#L6 [2] https://github.com/OpenSmalltalk/vm/tree/Cog/spursista64src/vm [3] https://github.com/OpenSmalltalk/vm/tree/Cog/spursistasrc/vm > > > > Sent from my iPhone > > On Jun 16, 2016, at 9:56 AM, Eliot Miranda > wrote: > > > Hi All, > > On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: > > > > On Thu, Jun 16, 2016 at 5:10 PM, Serge Stinckwich > > wrote: > > > On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff > > wrote: > > Hi all, > > > Very impressive work, Tim&Fabio ! The power of full-automation ! > > > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > > migrated to GitHub. Automatic builds are running > > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, > > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded > > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files). > > > About uploading binary artifacts, this is something I asked and this > > nice that Fabio make it work :-) > > > What is the advantage of this? The 44 .image files stored in the > > repository take up 196MB, doubling the space. > > > What are the images? IIRC there are no images in the svn repo. The only > big files are sources files for various key squeak and Pharo releases. > Did I check in images in the images directory by mistake? There should be > nine there; they're to be downloaded and built/converted, not checked into > the repository. > > So please, list these image files here... > > I guess thats not a > > big deal for a one time cost to clone the repository - for most of us > > with wide bandwidths in the modern world. But some places still have > > limited bandwidth. > > > Also SSD are sometimes not so big, and maybe someone wants to compile > > on a smaller system like as RasPi (although it can handle reasonable > > sized storage cards.) > > > Apparently there is some problems with some artifacts that have a > > double .zip extension. > > > Right now we have enabled all platform, object memory and bytecode set > > combinations that I found build scripts for - most work, but OS X 64-bit > > Sista is failing right now (32-bit works). At some point we'll have to > > decide which combinations to put into the CI config as "allowed failures" > to > > get a green badge :) > > > Another thing for those not familiar with Git: Right now the entire > > repository is 360MB, including all history. Most of that is old images that > > were at one point committed to SVN and that have been pulled into the > > repository. We could clean those out (removing them from the history) to > > make the repository smaller, but I felt ~400MB is still ok (albeit > > technically over the Github quota. We'll see of they complain). I would > like > > to ask everyone to stop committing large binary files into the repository, > > however. Git is simply not very suited to dealing with binaries. > > If there is a need for that, Github has support for git-lfs, which offers > 1GB of free > > storage with a 1GB bandwith limit per month. > > > Initially I said... "Please, can we consider doing that. 1GB/1GB > > seems ample, and $5/mth provides 50GB/50GB [1] (and you'd expect those > > quotas to expand over time.) And a quick reference to how it works > > [2]. However enabling lfs doesn't automatically convert existing > > commits. The recommend migration tool seems to be git-lfs-migrate > > [3]. But history is rewritten, so any clones will need to be rebased > > - so now at the start is probably the best time to do it ! " > > > But then I read lfs currently doesn't work properly with forked repos [4] > [5] > > Also early lfs versions seem to have had a performance issue [6], > > but that may be recently solved [7]. > > > > btw, is anyone going to be using git-svn, or is everyone making the > > big jump pure git? > > > In any case, I'm very glad to see the repo on git. Thanks all that > > helped make it happen, and Tim & Fabio for the work. > > > cheers -ben > > > [1] > https://help.github.com/articles/billing-plans-for-git-large-file-storage/ > > [2] https://git-lfs.github.com/ > > [3] https://github.com/bozaro/git-lfs-migrate > > [4] > https://medium.com/@megastep/github-s-large-file-storage-is-no-panacea-for-open-source-quite-the-opposite-12c0e16a9a91#.omrd0qw6n > > [5] https://github.com/github/git-lfs/issues/773 > > [6] > https://www.bountysource.com/issues/21357625-git-lfs-is-unusable-slow-especially-on-windows > > [7] https://developer.atlassian.com/blog/2016/04/git-lfs-12-clone-faster/ > > > > > > > If we need more, we can look at > > the different billing levels. > > > If you're familiar with Git, the only new thing to watch out for is the > > updateSCSSVersions script as described in the README. It's not relevant for > > the CI, but your own binaries will only show correct versions if this > script > > runs at appropriate times. > > > If you are not familiar with Git and don't care, there are scripts for > > committing that should take care of everything as described in the README. > > Again, let us know if anything doesn't work. The only difference vs SVN to > > watch out for for you will be that the old scripts/svnci would commit your > > changes to the server, whereas the scripts/gitci script only commits them > > locally. You'll have to run `git pull` and `git push` to get them up to the > > server. > > > If you have any questions regarding the repository setup please don't > > hesitate to ask. You shouldn't be able to break anything, since we've > > disabled force pushes to both master and Cog (and thus any chance of > > destroying history). > > > What is favorite way of contributing for people outside the vm team ? > > pull-requests ? > > > Regards, > > -- > > Serge Stinckwich > > UCBN & UMI UMMISCO 209 (IRD/UPMC) > > Every DSL ends up being Smalltalk > > http://www.doesnotunderstand.org/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/39c65bd4/attachment-0001.htm From tim at rowledge.org Fri Jun 17 16:53:18 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 17 16:53:06 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <1466168946288-4901424.post@n4.nabble.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <1466168946288-4901424.post@n4.nabble.com> Message-ID: > On 17-06-2016, at 6:09 AM, Henrik Sperre Johansen wrote: > > Could it be the arm make files are missing -fno-omit-frame-pointer at some > crucial place? Always a possibility. gcc?s flags and options are like paying whack-a-mole, with a mole of moles. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XO: Execute Operator From eliot.miranda at gmail.com Fri Jun 17 16:58:00 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 16:58:05 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: Tim, Fabio, McStalker.~$ du -sh oscogvm 1.2G oscogvm McStalker.~$ rm -rf oscogvm McStalker.~$ git clone http://github.com/OpenSmalltalk/vm oscogvm Cloning into 'oscogvm'... remote: Counting objects: 69291, done. remote: Compressing objects: 100% (6/6), done. remote: Total 69291 (delta 1), reused 0 (delta 0), pack-reused 69285 Receiving objects: 100% (69291/69291), 91.39 MiB | 2.35 MiB/s, done. Resolving deltas: 100% (44522/44522), done. Checking connectivity... done. Checking out files: 100% (9870/9870), done. McStalker.~$ (cd oscogvm; ./scripts/updateSCCSVersions) No local changes to save No stash found. McStalker.~$ du -sh oscogvm 392M oscogvm McStalker.~$ Lovely! On Fri, Jun 17, 2016 at 12:09 AM, Tim Felgentreff wrote: > > Hi Eliot, > > we can nuke the history, but everyone will have to re-clone the > repository. Fabio and I will do it today, before everyone gets busy on > the new repo. > > About the images you mention that are supposed to be there: These > *will* cause problems down the road. There is no way we can keep > removing them from history when new versions come to replace them, and > still maintain a sensible collaborative development approach. > Rewriting history to remove this will cause problems for everyone > involved. These binary files really shouldn't be in Git at all. > > cheers, > Tim > > On 16 June 2016 at 20:24, Eliot Miranda wrote: > > > > > > Hi Bert, > > > > On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg > wrote: > >> > >> > >> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda > wrote: > >>> > >>> > >>> Hi All, > >>> > >>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: > >>> > What is the advantage of this? The 44 .image files stored in the > >>> > repository take up 196MB, doubling the space. > >>> > >>> What are the images? IIRC there are no images in the svn repo. The > only big files are sources files for various key squeak and Pharo > releases. Did I check in images in the images directory by mistake? There > should be nine there; they're to be downloaded and built/converted, not > checked into the repository. > >>> > >>> So please, list these image files here... > >> > >> > >> Here's a list of all the blobs larger than 1 MB: > > > > > > Thanks. None of those image (or associated changes) files should exist > in image/. None of them exist in the svn repository. How did they creep > in? Some who's already up and running might like to nuke them and commit > them to the master asap. To be clear > > > > image/VMMaker-Squeak4.1.image > > image/VMMaker-Squeak4.1.changes (if it exists) > > image/CogTrunk43.image > > image/CogTrunk43.changes > > > > should exist. Is this history pruning issue? Ah, that's what must have > happened. They were in svn at one time, and so have got copied in as part > of moving the entire history. So... anyone know enough git internals to > prune this part of the history? > > > >> > >> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 > image/VMMaker-Squeak4.1.image > >> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 > sources/SqueakV46.sources > >> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image > >> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 > image/CogTrunk43.changes > >> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image > >> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 > platforms/iOS/vm/iPhone/iPhone.image > >> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 > image/VMMaker-Squeak4.1.image > >> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 > image/VMMaker-Squeak4.1.image > >> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 > image/VMMaker-Squeak4.1.image > >> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 > FloatMathPlugin/testdata/log-large.dat > >> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 > FloatMathPlugin/testdata/sqrt-large.dat > >> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 > FloatMathPlugin/testdata/exp-large.dat > >> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 > FloatMathPlugin/testdata/atan-large.dat > >> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 > FloatMathPlugin/testdata/sin-large.dat > >> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 > platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib > >> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols > >> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 > platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib > >> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 > platforms/iOS/vm/iPhone/iPhone.changes > >> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 > processors/ARM/gdb-7.10/opcodes/i386-tbl.h > >> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 > processors/ARM/gdb-7.10/opcodes/m32c-desc.c > >> 8d66e7b3f3d10585846476ac343627852530647a 4287774 > platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser > >> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 > processors/ARM/gdb-7.10/opcodes/m32c-opc.c > >> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 > platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib > >> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 > processors/ARM/gdb-7.10/sim/frv/model.c > >> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 > platforms/win32/plugins/FT2Plugin/freetype.a > >> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 > nsspur64src/vm/gcc3x-cointerp.c > >> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 > nsspur64src/vm/cointerp.c > >> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 > spursistasrc/vm/gcc3x-cointerp.c > >> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c > >> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c > >> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 > nsspurstack64src/vm/gcc3x-interp.c > >> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 > nsspurstack64src/vm/interp.c > >> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 > nsspurstacksrc/vm/interp.c > >> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 > spursrc/vm/gcc3x-cointerp.c > >> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 > platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib > >> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols > >> 440955ce2200921b12153427645b8b191f8519be 2190822 > nsspurstacksrc/vm/gcc3x-interp.c > >> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 > spursistasrc/vm/cointerp.c > >> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 > platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib > >> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings > >> 34622fc8d020d258054f991209e02d300f51e4af 2097172 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control > >> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 > spurstacksrc/vm/interp.c > >> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 > spursrc/vm/gcc3x-cointerp.c > >> 92e95daf567930738b49a7ad87585c96623733fb 1884583 > nsspurstacksrc/vm/gcc3x-interp.c > >> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm > >> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 > nsspurstacksrc/vm/gcc3x-interp.c > >> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c > >> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 > src/vm/gcc3x-cointerpmt.c > >> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c > >> 965a8b480996779d2345ca314707408c4471d808 1820909 > spursrc/vm/gcc3x-cointerp.c > >> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 > spursrc/vm/gcc3x-cointerp.c > >> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c > >> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c > >> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c > >> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c > >> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 > processors/ARM/gdb-7.10/Makefile.in > >> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 > spurstacksrc/vm/interp.c > >> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 > spurstacksrc/vm/gcc3x-interp.c > >> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 > nscogsrc/vm/gcc3x-cointerp.c > >> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 > src/vm/gcc3x-cointerpmt.c > >> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c > >> b869bae1da98ed4f113b599569313384b618ba2f 1597168 > nscogsrc/vm/gcc3x-cointerp.c > >> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S > >> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 > processors/ARM/gdb-7.6/Makefile.in > >> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c > >> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S > >> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c > >> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 > spurstacksrc/vm/interp.c > >> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 > stacksrc/vm/gcc3x-interp.c > >> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c > >> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 > stacksrc/vm/gcc3x-interp.c > >> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 > platforms/win32/plugins/CameraPlugin/STRMBASE.lib > >> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 > build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin > >> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 > processors/IA32/bochs/build/macos/CWPro3_project.sit > >> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 > processors/IA32/bochs/configure > >> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 > build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp > >> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac > >> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 > spursistasrc/vm/cogitARMv5.c > >> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 > processors/ARM/gdb-7.10/opcodes/i386-opc.tbl > >> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 > processors/ARM/gdb-7.10/opcodes/m32c-opc.h > >> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 > stacksrc/vm/gcc3x-interp.c > >> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 > spursistasrc/vm/cogitIA32.c > >> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree > >> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control > >> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 > spursistasrc/vm/cogitMIPSEL.c > >> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 > spursistasrc/vm/cogitMIPSEL.c > >> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 > platforms/unix/config/configure > >> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac > >> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 > nsspur64src/vm/cogitX64.c > >> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 > processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s > >> > >> - Bert - > > > > > > _,,,^..^,,,_ > > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/845a2567/attachment-0001.htm From Lou at Keystone-Software.com Fri Jun 17 17:09:58 2016 From: Lou at Keystone-Software.com (Louis LaBrunda) Date: Fri Jun 17 17:10:11 2016 Subject: [Vm-dev] Cog + Pi + OSProcess References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <1466156025.19725.68.camel@gmail.com> <45B6BA88-D918-460C-9F16-C97D905EFE9E@rowledge.org> Message-ID: <6ib8mb56tlouq1667prkvtkp618huv9qh6@4ax.com> Hi Tim, How about a small battery back up that can signal the software that it need to save and shutdown cleanly when it loses power. Lou On Fri, 17 Jun 2016 09:52:01 -0700, tim Rowledge wrote: >> On 17-06-2016, at 2:33 AM, Phil (list) wrote: >> >> My biggest complaint is the things have no power/reset >> switch out of the box (it is possible to add via a DIY mod) but other >> than that, it's a quite useful little device for Smalltalk! > >I?m inclined to agree, but my attempted solution is to start work on a HAT that would provide >a) power input from a wider range of PSUs with a switchmode regulator etc >b) cooling (for heavily worked Pi3?s particularly - I did manage to work one so hard it just shut down) >c) power/reboot switch >d) (maybe) a basic ADC >e) (maybe) some other small missing item > >It?s very up in the air right now, might be a first attempt at a kickstarter etc. Anyone here interested? > >tim -- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon From tim at rowledge.org Fri Jun 17 17:19:20 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 17 17:19:19 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <6ib8mb56tlouq1667prkvtkp618huv9qh6@4ax.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <1466156025.19725.68.camel@gmail.com> <45B6BA88-D918-460C-9F16-C97D905EFE9E@rowledge.org> <6ib8mb56tlouq1667prkvtkp618huv9qh6@4ax.com> Message-ID: > On 17-06-2016, at 10:09 AM, Louis LaBrunda wrote: > > > Hi Tim, > > How about a small battery back up that can signal the software that it need to save and > shutdown cleanly when it loses power. There are actually several HATs to provide assorted UPS type functionality and/or battery power etc. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Trinoc does it take to change a lightbulb?? "Why do you want to know about our maintenance schedules? Are you planning to attack us in the dark?" From lists at fniephaus.com Fri Jun 17 17:31:29 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Fri Jun 17 17:31:43 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: Yep, that's way better! We've also used the opportunity to rewrite all commits with Git-compatible author information, so [1] now shows results retrospectively. [1] https://github.com/OpenSmalltalk/vm/graphs/contributors On Fri, 17 Jun 2016 at 18:58, Eliot Miranda wrote: > > Tim, Fabio, > > McStalker.~$ du -sh oscogvm > 1.2G oscogvm > McStalker.~$ rm -rf oscogvm > McStalker.~$ git clone http://github.com/OpenSmalltalk/vm oscogvm > Cloning into 'oscogvm'... > remote: Counting objects: 69291, done. > remote: Compressing objects: 100% (6/6), done. > remote: Total 69291 (delta 1), reused 0 (delta 0), pack-reused 69285 > Receiving objects: 100% (69291/69291), 91.39 MiB | 2.35 MiB/s, done. > Resolving deltas: 100% (44522/44522), done. > Checking connectivity... done. > Checking out files: 100% (9870/9870), done. > McStalker.~$ (cd oscogvm; ./scripts/updateSCCSVersions) > No local changes to save > No stash found. > McStalker.~$ du -sh oscogvm > 392M oscogvm > McStalker.~$ > > Lovely! > > On Fri, Jun 17, 2016 at 12:09 AM, Tim Felgentreff < > timfelgentreff@gmail.com> wrote: > >> >> Hi Eliot, >> >> we can nuke the history, but everyone will have to re-clone the >> repository. Fabio and I will do it today, before everyone gets busy on >> the new repo. >> >> About the images you mention that are supposed to be there: These >> *will* cause problems down the road. There is no way we can keep >> removing them from history when new versions come to replace them, and >> still maintain a sensible collaborative development approach. >> Rewriting history to remove this will cause problems for everyone >> involved. These binary files really shouldn't be in Git at all. >> >> cheers, >> Tim >> >> On 16 June 2016 at 20:24, Eliot Miranda wrote: >> > >> > >> > Hi Bert, >> > >> > On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg < >> bert@freudenbergs.de> wrote: >> >> >> >> >> >> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda < >> eliot.miranda@gmail.com> wrote: >> >>> >> >>> >> >>> Hi All, >> >>> >> >>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >> >>> > What is the advantage of this? The 44 .image files stored in the >> >>> > repository take up 196MB, doubling the space. >> >>> >> >>> What are the images? IIRC there are no images in the svn repo. The >> only big files are sources files for various key squeak and Pharo >> releases. Did I check in images in the images directory by mistake? There >> should be nine there; they're to be downloaded and built/converted, not >> checked into the repository. >> >>> >> >>> So please, list these image files here... >> >> >> >> >> >> Here's a list of all the blobs larger than 1 MB: >> > >> > >> > Thanks. None of those image (or associated changes) files should exist >> in image/. None of them exist in the svn repository. How did they creep >> in? Some who's already up and running might like to nuke them and commit >> them to the master asap. To be clear >> > >> > image/VMMaker-Squeak4.1.image >> > image/VMMaker-Squeak4.1.changes (if it exists) >> > image/CogTrunk43.image >> > image/CogTrunk43.changes >> > >> > should exist. Is this history pruning issue? Ah, that's what must >> have happened. They were in svn at one time, and so have got copied in as >> part of moving the entire history. So... anyone know enough git internals >> to prune this part of the history? >> > >> >> >> >> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 >> image/VMMaker-Squeak4.1.image >> >> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 >> sources/SqueakV46.sources >> >> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 >> image/CogTrunk43.image >> >> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 >> image/CogTrunk43.changes >> >> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 >> image/CogTrunk43.image >> >> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 >> platforms/iOS/vm/iPhone/iPhone.image >> >> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 >> image/VMMaker-Squeak4.1.image >> >> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 >> image/VMMaker-Squeak4.1.image >> >> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 >> image/VMMaker-Squeak4.1.image >> >> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 >> FloatMathPlugin/testdata/log-large.dat >> >> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 >> FloatMathPlugin/testdata/sqrt-large.dat >> >> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 >> FloatMathPlugin/testdata/exp-large.dat >> >> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 >> FloatMathPlugin/testdata/atan-large.dat >> >> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 >> FloatMathPlugin/testdata/sin-large.dat >> >> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 >> platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >> >> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >> >> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 >> platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >> >> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 >> platforms/iOS/vm/iPhone/iPhone.changes >> >> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 >> processors/ARM/gdb-7.10/opcodes/i386-tbl.h >> >> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 >> processors/ARM/gdb-7.10/opcodes/m32c-desc.c >> >> 8d66e7b3f3d10585846476ac343627852530647a 4287774 >> platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >> >> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 >> processors/ARM/gdb-7.10/opcodes/m32c-opc.c >> >> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 >> platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >> >> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 >> processors/ARM/gdb-7.10/sim/frv/model.c >> >> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 >> platforms/win32/plugins/FT2Plugin/freetype.a >> >> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 >> nsspur64src/vm/gcc3x-cointerp.c >> >> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 >> nsspur64src/vm/cointerp.c >> >> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 >> spursistasrc/vm/gcc3x-cointerp.c >> >> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 >> spur64src/vm/cointerp.c >> >> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 >> spur64src/vm/cointerp.c >> >> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 >> nsspurstack64src/vm/gcc3x-interp.c >> >> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 >> nsspurstack64src/vm/interp.c >> >> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 >> nsspurstacksrc/vm/interp.c >> >> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 >> spursrc/vm/gcc3x-cointerp.c >> >> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 >> platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >> >> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 >> build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >> >> 440955ce2200921b12153427645b8b191f8519be 2190822 >> nsspurstacksrc/vm/gcc3x-interp.c >> >> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 >> spursistasrc/vm/cointerp.c >> >> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 >> platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >> >> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >> >> 34622fc8d020d258054f991209e02d300f51e4af 2097172 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >> >> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 >> spurstacksrc/vm/interp.c >> >> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 >> spursrc/vm/gcc3x-cointerp.c >> >> 92e95daf567930738b49a7ad87585c96623733fb 1884583 >> nsspurstacksrc/vm/gcc3x-interp.c >> >> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >> >> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 >> nsspurstacksrc/vm/gcc3x-interp.c >> >> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >> >> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 >> src/vm/gcc3x-cointerpmt.c >> >> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >> >> 965a8b480996779d2345ca314707408c4471d808 1820909 >> spursrc/vm/gcc3x-cointerp.c >> >> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 >> spursrc/vm/gcc3x-cointerp.c >> >> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >> >> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 >> src/vm/gcc3x-cointerp.c >> >> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >> >> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >> >> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 >> processors/ARM/gdb-7.10/Makefile.in >> >> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 >> spurstacksrc/vm/interp.c >> >> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 >> spurstacksrc/vm/gcc3x-interp.c >> >> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 >> nscogsrc/vm/gcc3x-cointerp.c >> >> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 >> src/vm/gcc3x-cointerpmt.c >> >> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >> >> b869bae1da98ed4f113b599569313384b618ba2f 1597168 >> nscogsrc/vm/gcc3x-cointerp.c >> >> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 >> processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >> >> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 >> processors/ARM/gdb-7.6/Makefile.in >> >> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 >> src/vm/gcc3x-cointerp.c >> >> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 >> processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >> >> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >> >> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 >> spurstacksrc/vm/interp.c >> >> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 >> stacksrc/vm/gcc3x-interp.c >> >> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >> >> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 >> stacksrc/vm/gcc3x-interp.c >> >> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 >> platforms/win32/plugins/CameraPlugin/STRMBASE.lib >> >> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 >> build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >> >> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 >> processors/IA32/bochs/build/macos/CWPro3_project.sit >> >> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 >> processors/IA32/bochs/configure >> >> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 >> build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >> >> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >> >> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 >> spursistasrc/vm/cogitARMv5.c >> >> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 >> processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >> >> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 >> processors/ARM/gdb-7.10/opcodes/m32c-opc.h >> >> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 >> stacksrc/vm/gcc3x-interp.c >> >> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 >> spursistasrc/vm/cogitIA32.c >> >> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 >> nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >> >> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 >> build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >> >> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 >> spursistasrc/vm/cogitMIPSEL.c >> >> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 >> spursistasrc/vm/cogitMIPSEL.c >> >> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 >> platforms/unix/config/configure >> >> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >> >> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 >> nsspur64src/vm/cogitX64.c >> >> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 >> processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >> >> >> >> - Bert - >> > >> > >> > _,,,^..^,,,_ >> > best, Eliot >> > >> > > > > -- > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/1d84b930/attachment-0001.htm From gettimothy at zoho.com Fri Jun 17 20:30:56 2016 From: gettimothy at zoho.com (gettimothy) Date: Fri Jun 17 20:31:00 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> Message-ID: <155600f30ab.c69f2e721171.9222616235329166632@zoho.com> Awesome. Thank you all. ---- On Fri, 17 Jun 2016 13:31:29 -0400 Fabio Niephaus <lists@fniephaus.com> wrote ---- Yep, that's way better! We've also used the opportunity to rewrite all commits with Git-compatible author information, so [1] now shows results retrospectively. [1] https://github.com/OpenSmalltalk/vm/graphs/contributors On Fri, 17 Jun 2016 at 18:58, Eliot Miranda <eliot.miranda@gmail.com> wrote: Tim, Fabio, McStalker.~$ du -sh oscogvm 1.2G oscogvm McStalker.~$ rm -rf oscogvm McStalker.~$ git clone http://github.com/OpenSmalltalk/vm oscogvm Cloning into 'oscogvm'... remote: Counting objects: 69291, done. remote: Compressing objects: 100% (6/6), done. remote: Total 69291 (delta 1), reused 0 (delta 0), pack-reused 69285 Receiving objects: 100% (69291/69291), 91.39 MiB | 2.35 MiB/s, done. Resolving deltas: 100% (44522/44522), done. Checking connectivity... done. Checking out files: 100% (9870/9870), done. McStalker.~$ (cd oscogvm; ./scripts/updateSCCSVersions) No local changes to save No stash found. McStalker.~$ du -sh oscogvm 392M oscogvm McStalker.~$ Lovely! On Fri, Jun 17, 2016 at 12:09 AM, Tim Felgentreff <timfelgentreff@gmail.com> wrote: Hi Eliot, we can nuke the history, but everyone will have to re-clone the repository. Fabio and I will do it today, before everyone gets busy on the new repo. About the images you mention that are supposed to be there: These *will* cause problems down the road. There is no way we can keep removing them from history when new versions come to replace them, and still maintain a sensible collaborative development approach. Rewriting history to remove this will cause problems for everyone involved. These binary files really shouldn't be in Git at all. cheers, Tim On 16 June 2016 at 20:24, Eliot Miranda <eliot.miranda@gmail.com> wrote: > > > Hi Bert, > > On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg <bert@freudenbergs.de> wrote: >> >> >> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: >>> >>> >>> Hi All, >>> >>> On Jun 16, 2016, at 9:38 AM, Ben Coman <btc@openinworld.com> wrote: >>> > What is the advantage of this? The 44 .image files stored in the >>> > repository take up 196MB, doubling the space. >>> >>> What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. >>> >>> So please, list these image files here... >> >> >> Here's a list of all the blobs larger than 1 MB: > > > Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. To be clear > > image/VMMaker-Squeak4.1.image > image/VMMaker-Squeak4.1.changes (if it exists) > image/CogTrunk43.image > image/CogTrunk43.changes > > should exist. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? > >> >> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image >> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources >> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image >> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image >> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image >> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image >> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat >> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat >> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat >> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat >> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat >> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes >> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h >> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c >> 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c >> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c >> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a >> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c >> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c >> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c >> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c >> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c >> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c >> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >> 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c >> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c >> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >> 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c >> 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c >> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c >> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >> 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c >> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c >> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in >> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c >> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c >> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >> b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c >> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in >> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c >> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c >> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib >> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit >> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure >> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c >> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h >> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c >> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c >> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c >> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c >> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure >> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >> >> - Bert - > > > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/03b13c2a/attachment-0001.htm From eliot.miranda at gmail.com Fri Jun 17 20:49:32 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 17 20:49:38 2016 Subject: [Vm-dev] 64-bit bug(s) Message-ID: Hi Timothy, Hi All, I know some people have seen UI bugs with the 64-bit VM and image. This is just to report that I see one very obvious bug. In a recent messages browser on 64-bits any attempt to select a method other than the first in the list works, but immediately the selection reverts to the first element in the list. I suspect something in the event chain. But it's nice to have an obvious bug to chase instead of the much harder visual bugs people have been reporting up until now. Hopefully the same root cause will account for both bugs. Fingers crossed. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/0607e7d8/attachment.htm From btc at openinworld.com Sat Jun 18 00:01:03 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 18 00:01:27 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Message-ID: On Fri, Jun 17, 2016 at 8:47 PM, Fabio Niephaus wrote: > > Hi all, > > Tim and I just stripped all files from the repository that were larger than 7M. These were images, changes, sources, and test files (a detailed list is attached). Please clone the repository again. Thanks Fabio. git count-objects -vH was ==> size-pack: 354.75 MiB now ==> size-pack: 93.25 MiB Very nice! Now just to note the obvious, the BFG Repo Cleaner site advises "It's best to delete all old clones, as they'll have dirty history that you don't want to risk pushing back into your newly cleaned repo." cheers -ben > > You can find a backup of the sources files that were in /sources on the Cog/master branch at [1]. We have also updated the .gitignore to ignore *.image, *.changes, and *.sources globally. > > @Eliot: could you shed some light on how the sources files have been used? Instead of using git-lfs, it might be better to host large files somewhere (e.g. on Bintray since we are already using it) and to download them on demand. > > On smaller systems, it might still be better to download the zip [2] or to only clone the last n commits via `git clone --depth n ...`. > > Best, > Fabio > > [1] https://bintray.com/opensmalltalk/assets/sources/svn-backup/view?sort=&order=#files > [2] e.g. https://github.com/OpenSmalltalk/vm/archive/master.zip > > > -- > > On Fri, Jun 17, 2016 at 10:18 AM Dimitris Chloupis wrote: >> >> >> if you dont want to worry about the technically details of Git I highly advise using some of the excellent git gui clients , I use GitUP which greatly simplifies git >> >> http://gitup.co/ >> >> >> -- >> >> On Fri, Jun 17, 2016 at 10:47 AM Eliot Miranda wrote: >>> >>> >>> Hi Tim, >>> >>> >>> > On Jun 17, 2016, at 12:09 AM, Tim Felgentreff wrote: >>> > >>> > >>> > Hi Eliot, >>> > >>> > we can nuke the history, but everyone will have to re-clone the >>> > repository. Fabio and I will do it today, before everyone gets busy on >>> > the new repo. >>> > >>> > About the images you mention that are supposed to be there: These >>> > *will* cause problems down the road. There is no way we can keep >>> > removing them from history when new versions come to replace them, and >>> > still maintain a sensible collaborative development approach. >>> > Rewriting history to remove this will cause problems for everyone >>> > involved. These binary files really shouldn't be in Git at all. >>> >>> As far as I'm concerned there should be /no/ image or changes files in the repo. I can't speak to eg the iPhone image, only the ones in the image directory. So don't read that I think any of them should be there :-). IMO nuke them all. Anyone want to defend one of the images b4 it's too late???? Heh heh heh... >>> >>> > >>> > cheers, >>> > Tim >>> > >>> >> On 16 June 2016 at 20:24, Eliot Miranda wrote: >>> >> >>> >> >>> >> Hi Bert, >>> >> >>> >>> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg wrote: >>> >>> >>> >>> >>> >>>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda wrote: >>> >>>> >>> >>>> >>> >>>> Hi All, >>> >>>> >>> >>>>> On Jun 16, 2016, at 9:38 AM, Ben Coman wrote: >>> >>>>> What is the advantage of this? The 44 .image files stored in the >>> >>>>> repository take up 196MB, doubling the space. >>> >>>> >>> >>>> What are the images? IIRC there are no images in the svn repo. The only big files are sources files for various key squeak and Pharo releases. Did I check in images in the images directory by mistake? There should be nine there; they're to be downloaded and built/converted, not checked into the repository. >>> >>>> >>> >>>> So please, list these image files here... >>> >>> >>> >>> >>> >>> Here's a list of all the blobs larger than 1 MB: >>> >> >>> >> >>> >> Thanks. None of those image (or associated changes) files should exist in image/. None of them exist in the svn repository. How did they creep in? Some who's already up and running might like to nuke them and commit them to the master asap. To be clear >>> >> >>> >> image/VMMaker-Squeak4.1.image >>> >> image/VMMaker-Squeak4.1.changes (if it exists) >>> >> image/CogTrunk43.image >>> >> image/CogTrunk43.changes >>> >> >>> >> should exist. Is this history pruning issue? Ah, that's what must have happened. They were in svn at one time, and so have got copied in as part of moving the entire history. So... anyone know enough git internals to prune this part of the history? >>> >> >>> >>> >>> >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 image/VMMaker-Squeak4.1.image >>> >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 sources/SqueakV46.sources >>> >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 image/CogTrunk43.image >>> >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 image/CogTrunk43.changes >>> >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 image/CogTrunk43.image >>> >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 platforms/iOS/vm/iPhone/iPhone.image >>> >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 image/VMMaker-Squeak4.1.image >>> >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 image/VMMaker-Squeak4.1.image >>> >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 image/VMMaker-Squeak4.1.image >>> >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 FloatMathPlugin/testdata/log-large.dat >>> >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 FloatMathPlugin/testdata/sqrt-large.dat >>> >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 FloatMathPlugin/testdata/exp-large.dat >>> >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 FloatMathPlugin/testdata/atan-large.dat >>> >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 FloatMathPlugin/testdata/sin-large.dat >>> >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib >>> >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols >>> >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib >>> >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 platforms/iOS/vm/iPhone/iPhone.changes >>> >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 processors/ARM/gdb-7.10/opcodes/i386-tbl.h >>> >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 processors/ARM/gdb-7.10/opcodes/m32c-desc.c >>> >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser >>> >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 processors/ARM/gdb-7.10/opcodes/m32c-opc.c >>> >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib >>> >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 processors/ARM/gdb-7.10/sim/frv/model.c >>> >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 platforms/win32/plugins/FT2Plugin/freetype.a >>> >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 nsspur64src/vm/gcc3x-cointerp.c >>> >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 nsspur64src/vm/cointerp.c >>> >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 spursistasrc/vm/gcc3x-cointerp.c >>> >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 spur64src/vm/cointerp.c >>> >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 spur64src/vm/cointerp.c >>> >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 nsspurstack64src/vm/gcc3x-interp.c >>> >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 nsspurstack64src/vm/interp.c >>> >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 nsspurstacksrc/vm/interp.c >>> >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 spursrc/vm/gcc3x-cointerp.c >>> >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib >>> >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols >>> >>> 440955ce2200921b12153427645b8b191f8519be 2190822 nsspurstacksrc/vm/gcc3x-interp.c >>> >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 spursistasrc/vm/cointerp.c >>> >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib >>> >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings >>> >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control >>> >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 spurstacksrc/vm/interp.c >>> >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 spursrc/vm/gcc3x-cointerp.c >>> >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 nsspurstacksrc/vm/gcc3x-interp.c >>> >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 build.linux32ARM/asasm >>> >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 nsspurstacksrc/vm/gcc3x-interp.c >>> >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 sistasrc/vm/cointerp.c >>> >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 src/vm/gcc3x-cointerpmt.c >>> >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 src/vm/cointerpmt.c >>> >>> 965a8b480996779d2345ca314707408c4471d808 1820909 spursrc/vm/gcc3x-cointerp.c >>> >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 spursrc/vm/gcc3x-cointerp.c >>> >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 src/vm/cointerpmt.c >>> >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 src/vm/gcc3x-cointerp.c >>> >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 spursrc/vm/cointerp.c >>> >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c >>> >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 processors/ARM/gdb-7.10/Makefile.in >>> >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 spurstacksrc/vm/interp.c >>> >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 spurstacksrc/vm/gcc3x-interp.c >>> >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 nscogsrc/vm/gcc3x-cointerp.c >>> >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 src/vm/gcc3x-cointerpmt.c >>> >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 src/vm/cointerpmt.c >>> >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 nscogsrc/vm/gcc3x-cointerp.c >>> >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S >>> >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 processors/ARM/gdb-7.6/Makefile.in >>> >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 src/vm/gcc3x-cointerp.c >>> >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S >>> >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 nscogsrc/vm/cointerp.c >>> >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 spurstacksrc/vm/interp.c >>> >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 stacksrc/vm/gcc3x-interp.c >>> >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 stacksrc/vm/interp.c >>> >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 stacksrc/vm/gcc3x-interp.c >>> >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 platforms/win32/plugins/CameraPlugin/STRMBASE.lib >>> >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin >>> >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 processors/IA32/bochs/build/macos/CWPro3_project.sit >>> >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 processors/IA32/bochs/configure >>> >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp >>> >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac >>> >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 spursistasrc/vm/cogitARMv5.c >>> >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 processors/ARM/gdb-7.10/opcodes/i386-opc.tbl >>> >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 processors/ARM/gdb-7.10/opcodes/m32c-opc.h >>> >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 stacksrc/vm/gcc3x-interp.c >>> >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 spursistasrc/vm/cogitIA32.c >>> >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree >>> >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control >>> >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 spursistasrc/vm/cogitMIPSEL.c >>> >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 spursistasrc/vm/cogitMIPSEL.c >>> >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 platforms/unix/config/configure >>> >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac >>> >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 nsspur64src/vm/cogitX64.c >>> >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s >>> >>> >>> >>> - Bert - >>> >> >>> >> >>> >> _,,,^..^,,,_ >>> >> best, Eliot >>> >> > > From eliot.miranda at gmail.com Sat Jun 18 00:34:20 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Jun 18 00:34:25 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <6ib8mb56tlouq1667prkvtkp618huv9qh6@4ax.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <1466156025.19725.68.camel@gmail.com> <45B6BA88-D918-460C-9F16-C97D905EFE9E@rowledge.org> <6ib8mb56tlouq1667prkvtkp618huv9qh6@4ax.com> Message-ID: > On Jun 17, 2016, at 10:09 AM, Louis LaBrunda wrote: > > > Hi Tim, > > How about a small battery back up that can signal the software that it need to save and > shutdown cleanly when it loses power. +1 > > Lou > > On Fri, 17 Jun 2016 09:52:01 -0700, tim Rowledge wrote: > >>> On 17-06-2016, at 2:33 AM, Phil (list) wrote: >>> >>> My biggest complaint is the things have no power/reset >>> switch out of the box (it is possible to add via a DIY mod) but other >>> than that, it's a quite useful little device for Smalltalk! >> >> I?m inclined to agree, but my attempted solution is to start work on a HAT that would provide >> a) power input from a wider range of PSUs with a switchmode regulator etc >> b) cooling (for heavily worked Pi3?s particularly - I did manage to work one so hard it just shut down) >> c) power/reboot switch >> d) (maybe) a basic ADC >> e) (maybe) some other small missing item >> >> It?s very up in the air right now, might be a first attempt at a kickstarter etc. Anyone here interested? >> >> tim > -- > Louis LaBrunda > Keystone Software Corp. > SkypeMe callto://PhotonDemon > From tim at rowledge.org Sat Jun 18 01:07:55 2016 From: tim at rowledge.org (tim Rowledge) Date: Sat Jun 18 01:07:43 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <1466156025.19725.68.camel@gmail.com> <45B6BA88-D918-460C-9F16-C97D905EFE9E@rowledge.org> <6ib8mb56tlouq1667prkvtkp618huv9qh6@4ax.com> Message-ID: > On 17-06-2016, at 5:34 PM, Eliot Miranda wrote: > > > > >> On Jun 17, 2016, at 10:09 AM, Louis LaBrunda wrote: >> >> >> Hi Tim, >> >> How about a small battery back up that can signal the software that it need to save and >> shutdown cleanly when it loses power. > > +1 http://www.piups.net/ http://www.modmypi.com/raspberry-pi/breakout-boards/pi-modules/ups-pico http://homediyelectronics.com/projects/raspberrypi/ups/ http://www.pimodulescart.com/shop/item.aspx?itemid=24 http://www.mini-box.com/picoUPS-100-12V-DC-micro-UPS-system-battery-backup-system Lots of choices here. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Success always occurs in private, and failure in full view. From eliot.miranda at gmail.com Sat Jun 18 03:20:23 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Jun 18 03:20:26 2016 Subject: [Vm-dev] Regression in tryLoading Message-ID: Hi John, in the Cocoa platform Alien>>primLoadLibrary: no longer manages to load e.g. 'libSystem.B.dylib', which breaks the Quicksort callback example (Alien class>>exampleCqsort) plus any attempt to load libraries other than plains. Please, pretty please, can you fix this? The code in platforms/iOS//vm/OSX/sqMacUnixExternalPrims.m is too labyrinthine for my tiny brain. All I want is working 5640-bit and 32-bit callbacks and I'm not getting very far on my favourite development and test platform :-( _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/7e860b91/attachment.htm From eliot.miranda at gmail.com Sat Jun 18 03:28:04 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Jun 18 03:28:07 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: Hi Ben, On Fri, Jun 17, 2016 at 8:27 AM, Ben Coman wrote: > > On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda > wrote: > > > >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff > wrote: > >> > >>> On 16 June 2016 at 22:07, Eliot Miranda > wrote: > >>> Hi All, > >>> > >>> so after fixing "git remote get-url origin" to fail over to "git > remote > >>> show origin | filter and munge" the culture shock of "git commit -a" > (git > >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable > version > >>> info: > >>> > >>> > /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak > >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT > Compiler: > >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] > >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: > >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 > >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: > >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 > >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun > 16 > >>> 12:53:33 2016 -0700 $ > >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ > >>> > >>> Which begs the question how do I differentiate this from something > built > >>> officially via Travis? Arguably the URL is wrong, and should only say > >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps > should > >>> just include my local hostname and current directory when I make any > kind of > >>> local modification. So the above would read > >>> > >>> ... > >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 > 12:53:33 > >>> 2016 -0700 $ > >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ > >>> > >>> Alternatively we could add another field, or modify one of the existing > >>> fields to say "I'm official" however one would do that. I don't know > how, I > >>> just know we need this. I shouldn't be able to pollute the VM pool by > >>> putting some VM on some site somewhere that i just happened to build > after > >>> several sherries and some cannabis brownies that looks to all intents > and > >>> purposes just like a VM built by our official Travis slaves. Hic. > Chillin' > > I just discovered git-describe, which seems like it could be useful... > > http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html > > So if Travis created "r201606161953" as an *official* tag for > successful builds like this... > https://github.com/travis-ci/travis-ci/issues/1476 > > then `git describe` would produce "r201606161953" for that build, and > after a couple of commits in my personal repo would produce > "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish > non-official builds. > > In addition, I can now copy-paste a VM's output revision string > to directly do "git checkout r201606161953" > instead of "git checkout master@{2016-06-16 19:53} which I read is > only viable for 90 days anyway, and has some complexity between > whether the given date is author commit date or merge date. > > But after doing "git checkout r201606161953" in my personal repo > git describe > ==> r201606161953 is indistinguishable from the Travis build > but... > git describe --long > ==> r201606161953-0-a264e03b is distinguishable. > > In addition, if I edit some files and rebuild before committing I > want to distinguish this from when I build a fresh check out , which > can be done with... > git describe --long --dirty ==> r201606161953-0-a264e03b-dirty > > So that last would be used to version personal builds, > while Travis would use "git describe" without any flags. > ==> r201606161953 > Sounds really good, but McStalker.oscogvm$ uname -a Darwin McStalker 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 McStalker.oscogvm$ git --version git version 1.9.5 (Apple Git-50.3) McStalker.oscogvm$ git describe fatal: No names found, cannot describe anything. McStalker.oscogvm$ git describe --long fatal: No names found, cannot describe anything. McStalker.oscogvm$ >> how secure does this need to be? One way to differentiate the official > >> VMs is to sign them directly on Travis (which we'll want to do anyway, > >> just didn't get to it, yet). > >> > >> Another option is to just change the URL replacement code to do > >> something else when not running on Travis --- like adding your > >> hostname and path instead --- but this could be fairly easily messed > >> with. > >> > >> Not sure how much malicious intent we want to prevent. > > Later on we should have Travis signing its build artefacts, but for > now keep it simple. > The Mac builds already sign provided a certificate is installed and an environment variable set to point to it. See SIGNING_IDENTITY in build.macos*/common/Makefile.app > > > > > None. I don't think there's malicious intent at all. I do think we > should differentiate between "personal" and Travis builds. It's more for > my own information, so u don't get confused, than to prevent > maliciousness. So do the simplest thing that could possibly work TSTTCPW. > I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm > (path relative to ~eliot). > > I think `git branch` is as important as `path`. > Username could come from `git config user.name | sed 's/ //g' > > cheers -ben > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/9d32bb7a/attachment.htm From lists at fniephaus.com Sat Jun 18 08:53:08 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Sat Jun 18 08:53:21 2016 Subject: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC In-Reply-To: References: <1863A765-94A3-404D-9D44-94B07900AA13@gmail.com> <06A68E20-D6E2-4840-8D63-2D79D2F65F92@gmail.com> Message-ID: -- On Sat, Jun 18, 2016 at 2:01 AM Ben Coman wrote: > > On Fri, Jun 17, 2016 at 8:47 PM, Fabio Niephaus > wrote: > > > > Hi all, > > > > Tim and I just stripped all files from the repository that were larger > than 7M. These were images, changes, sources, and test files (a detailed > list is attached). Please clone the repository again. > > Thanks Fabio. > git count-objects -vH > was ==> size-pack: 354.75 MiB > now ==> size-pack: 93.25 MiB > > Very nice! Now just to note the obvious, the BFG Repo Cleaner site > advises "It's best to delete all old clones, as they'll have dirty > history that you don't want to risk pushing back into your newly > cleaned repo." > That shouldn't be a problem, because Cog and master are protected branches and can't be forced pushed. However, please don't force push any other branches! > > cheers -ben > > > > > You can find a backup of the sources files that were in /sources on the > Cog/master branch at [1]. We have also updated the .gitignore to ignore > *.image, *.changes, and *.sources globally. > > > > @Eliot: could you shed some light on how the sources files have been > used? Instead of using git-lfs, it might be better to host large files > somewhere (e.g. on Bintray since we are already using it) and to download > them on demand. > > > > On smaller systems, it might still be better to download the zip [2] or > to only clone the last n commits via `git clone --depth n ...`. > > > > Best, > > Fabio > > > > [1] > https://bintray.com/opensmalltalk/assets/sources/svn-backup/view?sort=&order=#files > > [2] e.g. https://github.com/OpenSmalltalk/vm/archive/master.zip > > > > > > -- > > > > On Fri, Jun 17, 2016 at 10:18 AM Dimitris Chloupis < > kilon.alios@gmail.com> wrote: > >> > >> > >> if you dont want to worry about the technically details of Git I highly > advise using some of the excellent git gui clients , I use GitUP which > greatly simplifies git > >> > >> http://gitup.co/ > >> > >> > >> -- > >> > >> On Fri, Jun 17, 2016 at 10:47 AM Eliot Miranda > wrote: > >>> > >>> > >>> Hi Tim, > >>> > >>> > >>> > On Jun 17, 2016, at 12:09 AM, Tim Felgentreff < > timfelgentreff@gmail.com> wrote: > >>> > > >>> > > >>> > Hi Eliot, > >>> > > >>> > we can nuke the history, but everyone will have to re-clone the > >>> > repository. Fabio and I will do it today, before everyone gets busy > on > >>> > the new repo. > >>> > > >>> > About the images you mention that are supposed to be there: These > >>> > *will* cause problems down the road. There is no way we can keep > >>> > removing them from history when new versions come to replace them, > and > >>> > still maintain a sensible collaborative development approach. > >>> > Rewriting history to remove this will cause problems for everyone > >>> > involved. These binary files really shouldn't be in Git at all. > >>> > >>> As far as I'm concerned there should be /no/ image or changes files in > the repo. I can't speak to eg the iPhone image, only the ones in the image > directory. So don't read that I think any of them should be there :-). IMO > nuke them all. Anyone want to defend one of the images b4 it's too > late???? Heh heh heh... > >>> > >>> > > >>> > cheers, > >>> > Tim > >>> > > >>> >> On 16 June 2016 at 20:24, Eliot Miranda > wrote: > >>> >> > >>> >> > >>> >> Hi Bert, > >>> >> > >>> >>> On Thu, Jun 16, 2016 at 11:16 AM, Bert Freudenberg < > bert@freudenbergs.de> wrote: > >>> >>> > >>> >>> > >>> >>>> On Thu, Jun 16, 2016 at 6:56 PM, Eliot Miranda < > eliot.miranda@gmail.com> wrote: > >>> >>>> > >>> >>>> > >>> >>>> Hi All, > >>> >>>> > >>> >>>>> On Jun 16, 2016, at 9:38 AM, Ben Coman > wrote: > >>> >>>>> What is the advantage of this? The 44 .image files stored in > the > >>> >>>>> repository take up 196MB, doubling the space. > >>> >>>> > >>> >>>> What are the images? IIRC there are no images in the svn repo. > The only big files are sources files for various key squeak and Pharo > releases. Did I check in images in the images directory by mistake? There > should be nine there; they're to be downloaded and built/converted, not > checked into the repository. > >>> >>>> > >>> >>>> So please, list these image files here... > >>> >>> > >>> >>> > >>> >>> Here's a list of all the blobs larger than 1 MB: > >>> >> > >>> >> > >>> >> Thanks. None of those image (or associated changes) files should > exist in image/. None of them exist in the svn repository. How did they > creep in? Some who's already up and running might like to nuke them and > commit them to the master asap. To be clear > >>> >> > >>> >> image/VMMaker-Squeak4.1.image > >>> >> image/VMMaker-Squeak4.1.changes (if it exists) > >>> >> image/CogTrunk43.image > >>> >> image/CogTrunk43.changes > >>> >> > >>> >> should exist. Is this history pruning issue? Ah, that's what must > have happened. They were in svn at one time, and so have got copied in as > part of moving the entire history. So... anyone know enough git internals > to prune this part of the history? > >>> >> > >>> >>> > >>> >>> 289eaa1573428ec1d31e5b1d0c672f1dd4389ff4 75830604 > image/VMMaker-Squeak4.1.image > >>> >>> dae3895f5cb962ec205710e5e135af1fedadeb3e 35378778 > sources/SqueakV46.sources > >>> >>> 2c74b720358234a061e8a6fbcb4450684b917527 23188396 > image/CogTrunk43.image > >>> >>> 6021cb4306d88aca6e1dd1d1fa648b7b18afb346 22212014 > image/CogTrunk43.changes > >>> >>> 1c0d4671846802366fa00265b172fd57bc7f1e06 21110428 > image/CogTrunk43.image > >>> >>> ecac4ad04095069bc697c4c2a2e1f858294a9811 20246864 > platforms/iOS/vm/iPhone/iPhone.image > >>> >>> 501a17b3af13bc384c3b7d09e9f045e519bd2990 14207204 > image/VMMaker-Squeak4.1.image > >>> >>> 47f32118be78eb4918384f4412539bcc7a8b676f 13537612 > image/VMMaker-Squeak4.1.image > >>> >>> 6602ee71ed2fd921ad23b4ad6cd69e70c453719c 13395572 > image/VMMaker-Squeak4.1.image > >>> >>> b0db5cee8f4047fd5ca02f0910bbb4bad09e152d 8000008 > FloatMathPlugin/testdata/log-large.dat > >>> >>> 83ed67006c7e7ef741d14122bdd67f23a8f6667d 8000008 > FloatMathPlugin/testdata/sqrt-large.dat > >>> >>> 7ebaa30ee9f4f64dd82651646acb6f79a34eff20 8000008 > FloatMathPlugin/testdata/exp-large.dat > >>> >>> 7cfacf7f9a795c47f2077a02623d5120587b73a5 8000008 > FloatMathPlugin/testdata/atan-large.dat > >>> >>> 364dc80dc5e1e7f2a02c9c7030190da4f8ebea42 8000008 > FloatMathPlugin/testdata/sin-large.dat > >>> >>> 8d6d32a9a5ec14dfc40b255198d4c27f2b0e0a58 6948164 > platforms/win32/third-party/dx9sdk/Lib/d3dx9dt.lib > >>> >>> 2becfa74458d9c8124e704d1a1a4f7ac3615c59a 6225720 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/symbols0.pbxsymbols > >>> >>> ffc9f0d8c9dcce47e80450f751bd8153f446d3eb 5959648 > platforms/win32/third-party/dx9sdk/Lib/d3dx9.lib > >>> >>> 4965f047c2cfcbac8fe0f117b2703d5d431c82fc 5549557 > platforms/iOS/vm/iPhone/iPhone.changes > >>> >>> ca804ab97ede40e5a399b8252c8847a23e431d48 5249151 > processors/ARM/gdb-7.10/opcodes/i386-tbl.h > >>> >>> 04e86ba5ef6e2f17f2bbc469212dfd64ee92f2e6 4299471 > processors/ARM/gdb-7.10/opcodes/m32c-desc.c > >>> >>> 8d66e7b3f3d10585846476ac343627852530647a 4287774 > platforms/iOS/vm/SqueakPureObjcCogVM.xcodeproj/johnmci.pbxuser > >>> >>> 61e0ce4736dca3b7d5be29fe9ad70ff1be52502f 4061860 > processors/ARM/gdb-7.10/opcodes/m32c-opc.c > >>> >>> 3f039fa2a9694c8049b5ba54353993c6c36b067f 3901404 > platforms/win32/third-party/dx9sdk/Lib/DxErr9.lib > >>> >>> e23bc8c971c834ae2793efd3f3ef9eabf490fe50 3309142 > processors/ARM/gdb-7.10/sim/frv/model.c > >>> >>> 747dce4e607d40bb596cf897ed41e0f8d6ac5e58 3129142 > platforms/win32/plugins/FT2Plugin/freetype.a > >>> >>> 8e0a3dd9550a78e6c4de99bb66348f203942f266 2904152 > nsspur64src/vm/gcc3x-cointerp.c > >>> >>> dead491d0e30636474ff7a7cbdb15b84f4604638 2903895 > nsspur64src/vm/cointerp.c > >>> >>> de51f985f55ec82538a9806d3dcef1fcd788cec7 2745979 > spursistasrc/vm/gcc3x-cointerp.c > >>> >>> 6fa7c5a4780c3e3d220e39d612572e708c9fddd2 2565876 > spur64src/vm/cointerp.c > >>> >>> 4d775921bd65ac10884de1d75a595052b7efb000 2549550 > spur64src/vm/cointerp.c > >>> >>> 4ff55f09936dc5e3bd31e6f869212b5ad6504bb1 2539136 > nsspurstack64src/vm/gcc3x-interp.c > >>> >>> 339e0fadfb07d7386e6940039c8c75904841795a 2538879 > nsspurstack64src/vm/interp.c > >>> >>> 25ef6ba9ac1305551024e651ae59fffa3c37b42e 2499583 > nsspurstacksrc/vm/interp.c > >>> >>> 408fd7522634a24e3100131466c9845c1e4aede5 2489223 > spursrc/vm/gcc3x-cointerp.c > >>> >>> 755e2901d955ee552537ba5257e37baa57026fbc 2467156 > platforms/win32/third-party/dx9sdk/Lib/d3dx8dt.lib > >>> >>> 207e1d8998b933ae6e9e8c95b49f5549c01abba7 2335480 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/symbols0.pbxsymbols > >>> >>> 440955ce2200921b12153427645b8b191f8519be 2190822 > nsspurstacksrc/vm/gcc3x-interp.c > >>> >>> 2eeab574645d321b7c82e9326e8ce6fca0ea90a6 2166050 > spursistasrc/vm/cointerp.c > >>> >>> 8305ff4c2132877d299251b2cf8ce0ef9e253f5e 2151212 > platforms/win32/third-party/dx9sdk/Lib/d3dx8.lib > >>> >>> ac5b064ff1dab48e062b55abbf4ca062a2208ba4 2120346 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/strings > >>> >>> 34622fc8d020d258054f991209e02d300f51e4af 2097172 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/strings.pbxstrings/control > >>> >>> 0339985e008c6a3aef0f100b81c305185aa68a02 2038849 > spurstacksrc/vm/interp.c > >>> >>> 12738ed85962daaf6a8b9d1abd84753e743687f6 1979492 > spursrc/vm/gcc3x-cointerp.c > >>> >>> 92e95daf567930738b49a7ad87585c96623733fb 1884583 > nsspurstacksrc/vm/gcc3x-interp.c > >>> >>> 74a462dc2ab59214a0d4c6aee24f39a9616ea2ee 1883410 > build.linux32ARM/asasm > >>> >>> 3f03bc920c4b7ece1d0b1866c4e2370333a6f89e 1873776 > nsspurstacksrc/vm/gcc3x-interp.c > >>> >>> 2aca9a5c0f5e608a70db5cfc91a6a886666d245f 1862675 > sistasrc/vm/cointerp.c > >>> >>> 76bcfe783efb5c8cd347ab5fe540e53b18796a7a 1847830 > src/vm/gcc3x-cointerpmt.c > >>> >>> 67111059d939197a333ef99a0c3369a240d0607d 1847573 > src/vm/cointerpmt.c > >>> >>> 965a8b480996779d2345ca314707408c4471d808 1820909 > spursrc/vm/gcc3x-cointerp.c > >>> >>> c07fff851d59be32a9a622c933ec3bfc99aadb8f 1813731 > spursrc/vm/gcc3x-cointerp.c > >>> >>> 0535c5a8bbc8cacb45444b63d1bb0fac4d8c945d 1805930 > src/vm/cointerpmt.c > >>> >>> b32dd1706c9cb9243ab601bea5858ee4c4d35841 1775670 > src/vm/gcc3x-cointerp.c > >>> >>> 5bcff5e443fd9c85565424ce254dae35ebddc512 1766278 > spursrc/vm/cointerp.c > >>> >>> fd22897bc5560fb323a53f1cfa70482a1041fea4 1740866 src/vm/cointerp.c > >>> >>> 61e0ab62c5a681d2c3cebc8f07f2b19509b09fcd 1702387 > processors/ARM/gdb-7.10/Makefile.in > >>> >>> fcf11dee7a4281cf55bf3ac934c03c65a2549da7 1651282 > spurstacksrc/vm/interp.c > >>> >>> 459c08ef533a0fa1d890c4cbf98677c821575eb6 1640494 > spurstacksrc/vm/gcc3x-interp.c > >>> >>> 37130b7b5654d6463ef9ae0c1cdc41557563ea6e 1606745 > nscogsrc/vm/gcc3x-cointerp.c > >>> >>> e79dc6385d03bf4fb366ee2f0ab17a9a1da6fd92 1601274 > src/vm/gcc3x-cointerpmt.c > >>> >>> 63a0a45c3deba933fa3e8bf5e19fdba89c9f3382 1601017 > src/vm/cointerpmt.c > >>> >>> b869bae1da98ed4f113b599569313384b618ba2f 1597168 > nscogsrc/vm/gcc3x-cointerp.c > >>> >>> 6ffe6d1c5cfc5437c9ad7546984435003955b967 1570257 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all32bitopcodes.S > >>> >>> 08049deb96d0c1ac13cc73783c5be49bdf9d6167 1545524 > processors/ARM/gdb-7.6/Makefile.in > >>> >>> b204734be5f5ecac3359c59fc91bb57e87d686e2 1539831 > src/vm/gcc3x-cointerp.c > >>> >>> 516583bb2d3ab842905c2de5a64c1ae7da2cd02b 1533080 > processors/ARM/gdb-7.10/sim/testsuite/sim/bfin/se_all64bitg0opcodes.S > >>> >>> 0005172fb0f366b97ceb72659d96ff8ec7f3fc23 1465675 > nscogsrc/vm/cointerp.c > >>> >>> 88a8274c105c920e26e0d9604c721361a52fc83f 1463083 > spurstacksrc/vm/interp.c > >>> >>> 936576ff13fe06747798c82a4dd38361c4ab23d8 1346792 > stacksrc/vm/gcc3x-interp.c > >>> >>> 2e14536e7c96b802f76896455e7ba60c12d0dc89 1341859 > stacksrc/vm/interp.c > >>> >>> 02d4abfbda264e0293a77822b9557ae315697a55 1326768 > stacksrc/vm/gcc3x-interp.c > >>> >>> 17f186d5c7eb600b599725a88bf84cbb9ec2282a 1284776 > platforms/win32/plugins/CameraPlugin/STRMBASE.lib > >>> >>> bf57ded9f7b284fe26e6a18faf456b3393aed98c 1275996 > build.macos32x86/squeak.cog.spur/resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin > >>> >>> b10adc6f89039843e66c4b876bed9049e309ef04 1255450 > processors/IA32/bochs/build/macos/CWPro3_project.sit > >>> >>> e9dd77ab38f5db36a47b12b002fa3d6859c7339a 1238039 > processors/IA32/bochs/configure > >>> >>> b5c75b9330c2a9ab779842894d95a2eabaa3ce1d 1200054 > build.win32x86/newspeak.cog.spur/installer/InstallerBackground.bmp > >>> >>> bfa76e31a4107eaaca11851d3dc536fd9ab2da77 1171699 platforms/Mac > >>> >>> d9261fba5ba9e6898ffa31776938549e3ca507e2 1157317 > spursistasrc/vm/cogitARMv5.c > >>> >>> ed6fe63fb4832f1c099e8149ef633d72d576b4e3 1153949 > processors/ARM/gdb-7.10/opcodes/i386-opc.tbl > >>> >>> 9844474fe8ea7082b12125d76c5e3b3a853b8d0d 1132761 > processors/ARM/gdb-7.10/opcodes/m32c-opc.h > >>> >>> 2b2201585be870860f6c480a1a95eb4f8c3a3509 1108303 > stacksrc/vm/gcc3x-interp.c > >>> >>> 4e31ed52ad15c7216bc0299794ba7388bd4c1a67 1069859 > spursistasrc/vm/cogitIA32.c > >>> >>> 46b20c4e6ef3e5c436938e7e2982017fd2b13d7e 1064268 > nsspurcogbuild/macbuild/build/CoreVM.build/CoreVM.pbxindex/cdecls.pbxbtree > >>> >>> c36cc19ee1658d23886d93a73289048128c4ba95 1048596 > build.macos64x64/xcode/CocoaTemplate/build/CocoaTemplate.build/CocoaTemplate.pbxindex/strings.pbxstrings/control > >>> >>> 7fb702db78c6af71da3d1927a8b16ed6393df4ce 1045815 > spursistasrc/vm/cogitMIPSEL.c > >>> >>> f9eebe49b93b9fe5ac9879f84f505caaee5e2521 1044784 > spursistasrc/vm/cogitMIPSEL.c > >>> >>> d28406446edf029b9b389403d882c6ae581d1fb2 1043986 > platforms/unix/config/configure > >>> >>> e7dbfe6af3567f7878b51c44806605012469ba47 1043820 platforms/Mac > >>> >>> 126d45143fcb4ec0f4c79a7c8f2c215f9c5f491e 1041640 > nsspur64src/vm/cogitX64.c > >>> >>> 8c8384e04b343c2216e1b9244f3b60a73e289007 1017027 > processors/ARM/gdb-7.10/sim/testsuite/sim/mips/mips32-dsp2.s > >>> >>> > >>> >>> - Bert - > >>> >> > >>> >> > >>> >> _,,,^..^,,,_ > >>> >> best, Eliot > >>> >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/02b567c7/attachment-0001.htm From lists at fniephaus.com Sat Jun 18 09:04:42 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Sat Jun 18 09:04:53 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: -- On Sat, Jun 18, 2016 at 5:28 AM Eliot Miranda wrote: > > Hi Ben, > > On Fri, Jun 17, 2016 at 8:27 AM, Ben Coman wrote: > >> >> On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda >> wrote: >> > >> >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff < >> timfelgentreff@gmail.com> wrote: >> >> >> >>> On 16 June 2016 at 22:07, Eliot Miranda >> wrote: >> >>> Hi All, >> >>> >> >>> so after fixing "git remote get-url origin" to fail over to "git >> remote >> >>> show origin | filter and munge" the culture shock of "git commit -a" >> (git >> >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable >> version >> >>> info: >> >>> >> >>> >> /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak >> >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT >> Compiler: >> >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] >> >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: >> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >> >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: >> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >> >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun >> 16 >> >>> 12:53:33 2016 -0700 $ >> >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ >> >>> >> >>> Which begs the question how do I differentiate this from something >> built >> >>> officially via Travis? Arguably the URL is wrong, and should only say >> >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps >> should >> >>> just include my local hostname and current directory when I make any >> kind of >> >>> local modification. So the above would read >> >>> >> >>> ... >> >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 >> 12:53:33 >> >>> 2016 -0700 $ >> >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ >> >>> >> >>> Alternatively we could add another field, or modify one of the >> existing >> >>> fields to say "I'm official" however one would do that. I don't know >> how, I >> >>> just know we need this. I shouldn't be able to pollute the VM pool by >> >>> putting some VM on some site somewhere that i just happened to build >> after >> >>> several sherries and some cannabis brownies that looks to all intents >> and >> >>> purposes just like a VM built by our official Travis slaves. Hic. >> Chillin' >> >> I just discovered git-describe, which seems like it could be useful... >> >> http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html >> >> So if Travis created "r201606161953" as an *official* tag for >> successful builds like this... >> https://github.com/travis-ci/travis-ci/issues/1476 >> >> then `git describe` would produce "r201606161953" for that build, and >> after a couple of commits in my personal repo would produce >> "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish >> non-official builds. >> >> In addition, I can now copy-paste a VM's output revision string >> to directly do "git checkout r201606161953" >> instead of "git checkout master@{2016-06-16 19:53} which I read is >> only viable for 90 days anyway, and has some complexity between >> whether the given date is author commit date or merge date. >> >> But after doing "git checkout r201606161953" in my personal repo >> git describe >> ==> r201606161953 is indistinguishable from the Travis build >> but... >> git describe --long >> ==> r201606161953-0-a264e03b is distinguishable. >> >> In addition, if I edit some files and rebuild before committing I >> want to distinguish this from when I build a fresh check out , which >> can be done with... >> git describe --long --dirty ==> r201606161953-0-a264e03b-dirty >> >> So that last would be used to version personal builds, >> while Travis would use "git describe" without any flags. >> ==> r201606161953 >> > > Sounds really good, but > > McStalker.oscogvm$ uname -a > Darwin McStalker 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 > PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 > McStalker.oscogvm$ git --version > git version 1.9.5 (Apple Git-50.3) > McStalker.oscogvm$ git describe > fatal: No names found, cannot describe anything. > McStalker.oscogvm$ git describe --long > fatal: No names found, cannot describe anything. > McStalker.oscogvm$ > > >> how secure does this need to be? One way to differentiate the official >> >> VMs is to sign them directly on Travis (which we'll want to do anyway, >> >> just didn't get to it, yet). >> >> >> >> Another option is to just change the URL replacement code to do >> >> something else when not running on Travis --- like adding your >> >> hostname and path instead --- but this could be fairly easily messed >> >> with. >> >> >> >> Not sure how much malicious intent we want to prevent. >> >> Later on we should have Travis signing its build artefacts, but for >> now keep it simple. >> > > The Mac builds already sign provided a certificate is installed and an > environment variable set to point to it. See SIGNING_IDENTITY in > build.macos*/common/Makefile.app > Cool! Now we only need to decide whose certificate to use. We can encrypt the cert securely, add it to the repository and install it during a build. BTW: we are already doing this for the RSqueak VM [1] as well. [1] https://github.com/HPI-SWA-Lab/RSqueak-App/blob/c8e28879a8a9da97fe06cd5cb82e9b9c3058924e/prepare.sh#L42-L46 > > >> >> > >> > None. I don't think there's malicious intent at all. I do think we >> should differentiate between "personal" and Travis builds. It's more for >> my own information, so u don't get confused, than to prevent >> maliciousness. So do the simplest thing that could possibly work TSTTCPW. >> I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm >> (path relative to ~eliot). >> >> I think `git branch` is as important as `path`. >> Username could come from `git config user.name | sed 's/ //g' >> >> cheers -ben >> > > > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/29fb6bd3/attachment.htm From btc at openinworld.com Sat Jun 18 09:05:33 2016 From: btc at openinworld.com (Ben Coman) Date: Sat Jun 18 09:06:01 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: On Sat, Jun 18, 2016 at 11:28 AM, Eliot Miranda wrote: > > Hi Ben, > > On Fri, Jun 17, 2016 at 8:27 AM, Ben Coman wrote: >> >> >> On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda wrote: >> > >> >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff wrote: >> >> >> >>> On 16 June 2016 at 22:07, Eliot Miranda wrote: >> >>> Hi All, >> >>> >> >>> so after fixing "git remote get-url origin" to fail over to "git remote >> >>> show origin | filter and munge" the culture shock of "git commit -a" (git >> >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable version >> >>> info: >> >>> >> >>> /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak >> >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT Compiler: >> >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] >> >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: >> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >> >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: >> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >> >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu Jun 16 >> >>> 12:53:33 2016 -0700 $ >> >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ >> >>> >> >>> Which begs the question how do I differentiate this from something built >> >>> officially via Travis? Arguably the URL is wrong, and should only say >> >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps should >> >>> just include my local hostname and current directory when I make any kind of >> >>> local modification. So the above would read >> >>> >> >>> ... >> >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 12:53:33 >> >>> 2016 -0700 $ >> >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ >> >>> >> >>> Alternatively we could add another field, or modify one of the existing >> >>> fields to say "I'm official" however one would do that. I don't know how, I >> >>> just know we need this. I shouldn't be able to pollute the VM pool by >> >>> putting some VM on some site somewhere that i just happened to build after >> >>> several sherries and some cannabis brownies that looks to all intents and >> >>> purposes just like a VM built by our official Travis slaves. Hic. Chillin' >> >> I just discovered git-describe, which seems like it could be useful... >> http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html >> >> So if Travis created "r201606161953" as an *official* tag for >> successful builds like this... >> https://github.com/travis-ci/travis-ci/issues/1476 >> >> then `git describe` would produce "r201606161953" for that build, and >> after a couple of commits in my personal repo would produce >> "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish >> non-official builds. >> >> In addition, I can now copy-paste a VM's output revision string >> to directly do "git checkout r201606161953" >> instead of "git checkout master@{2016-06-16 19:53} which I read is >> only viable for 90 days anyway, and has some complexity between >> whether the given date is author commit date or merge date. >> >> But after doing "git checkout r201606161953" in my personal repo >> git describe >> ==> r201606161953 is indistinguishable from the Travis build >> but... >> git describe --long >> ==> r201606161953-0-a264e03b is distinguishable. >> >> In addition, if I edit some files and rebuild before committing I >> want to distinguish this from when I build a fresh check out , which >> can be done with... >> git describe --long --dirty ==> r201606161953-0-a264e03b-dirty >> >> So that last would be used to version personal builds, >> while Travis would use "git describe" without any flags. >> ==> r201606161953 > > > Sounds really good, but > > McStalker.oscogvm$ uname -a > Darwin McStalker 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 > McStalker.oscogvm$ git --version > git version 1.9.5 (Apple Git-50.3) > McStalker.oscogvm$ git describe > fatal: No names found, cannot describe anything. > McStalker.oscogvm$ git describe --long > fatal: No names found, cannot describe anything. > McStalker.oscogvm$ That confused me also for a moment. Its only because there are not yet any tags. Try this... $ git tag -a mytag -m "my message" $ git describe --long --dirty $ touch x $ git add x $ git commit -m "blah de blah" $ git describe --long --dirty $ echo blah > x $ git describe --long --dirty Plus these tags can be applied retroactively without affecting history... https://git-scm.com/book/en/v2/Git-Basics-Tagging cheers -ben > >> >> how secure does this need to be? One way to differentiate the official >> >> VMs is to sign them directly on Travis (which we'll want to do anyway, >> >> just didn't get to it, yet). >> >> >> >> Another option is to just change the URL replacement code to do >> >> something else when not running on Travis --- like adding your >> >> hostname and path instead --- but this could be fairly easily messed >> >> with. >> >> >> >> Not sure how much malicious intent we want to prevent. >> >> Later on we should have Travis signing its build artefacts, but for >> now keep it simple. > > > The Mac builds already sign provided a certificate is installed and an environment variable set to point to it. See SIGNING_IDENTITY in build.macos*/common/Makefile.app > >> >> >> > >> > None. I don't think there's malicious intent at all. I do think we should differentiate between "personal" and Travis builds. It's more for my own information, so u don't get confused, than to prevent maliciousness. So do the simplest thing that could possibly work TSTTCPW. I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm (path relative to ~eliot). >> >> I think `git branch` is as important as `path`. >> Username could come from `git config user.name | sed 's/ //g' From lists at fniephaus.com Sat Jun 18 12:51:21 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Sat Jun 18 12:51:34 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: -- On Sat, Jun 18, 2016 at 11:06 AM Ben Coman wrote: > > On Sat, Jun 18, 2016 at 11:28 AM, Eliot Miranda > wrote: > > > > Hi Ben, > > > > On Fri, Jun 17, 2016 at 8:27 AM, Ben Coman wrote: > >> > >> > >> On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda > wrote: > >> > > >> >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff < > timfelgentreff@gmail.com> wrote: > >> >> > >> >>> On 16 June 2016 at 22:07, Eliot Miranda > wrote: > >> >>> Hi All, > >> >>> > >> >>> so after fixing "git remote get-url origin" to fail over to > "git remote > >> >>> show origin | filter and munge" the culture shock of "git commit > -a" (git > >> >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable > version > >> >>> info: > >> >>> > >> >>> > /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak > >> >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT > Compiler: > >> >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur > VM] > >> >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: > >> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 > >> >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: > >> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 > >> >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu > Jun 16 > >> >>> 12:53:33 2016 -0700 $ > >> >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ > >> >>> > >> >>> Which begs the question how do I differentiate this from something > built > >> >>> officially via Travis? Arguably the URL is wrong, and should only > say > >> >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and > perhaps should > >> >>> just include my local hostname and current directory when I make > any kind of > >> >>> local modification. So the above would read > >> >>> > >> >>> ... > >> >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 > 12:53:33 > >> >>> 2016 -0700 $ > >> >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ > >> >>> > >> >>> Alternatively we could add another field, or modify one of the > existing > >> >>> fields to say "I'm official" however one would do that. I don't > know how, I > >> >>> just know we need this. I shouldn't be able to pollute the VM pool > by > >> >>> putting some VM on some site somewhere that i just happened to > build after > >> >>> several sherries and some cannabis brownies that looks to all > intents and > >> >>> purposes just like a VM built by our official Travis slaves. Hic. > Chillin' > >> > >> I just discovered git-describe, which seems like it could be useful... > >> > http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html > >> > >> So if Travis created "r201606161953" as an *official* tag for > >> successful builds like this... > >> https://github.com/travis-ci/travis-ci/issues/1476 > >> > >> then `git describe` would produce "r201606161953" for that build, and > >> after a couple of commits in my personal repo would produce > >> "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish > >> non-official builds. > >> > >> In addition, I can now copy-paste a VM's output revision string > >> to directly do "git checkout r201606161953" > >> instead of "git checkout master@{2016-06-16 19:53} which I read is > >> only viable for 90 days anyway, and has some complexity between > >> whether the given date is author commit date or merge date. > >> > >> But after doing "git checkout r201606161953" in my personal repo > >> git describe > >> ==> r201606161953 is indistinguishable from the Travis build > >> but... > >> git describe --long > >> ==> r201606161953-0-a264e03b is distinguishable. > >> > >> In addition, if I edit some files and rebuild before committing I > >> want to distinguish this from when I build a fresh check out , which > >> can be done with... > >> git describe --long --dirty ==> r201606161953-0-a264e03b-dirty > >> > >> So that last would be used to version personal builds, > >> while Travis would use "git describe" without any flags. > >> ==> r201606161953 > > > > > > Sounds really good, but > > > > McStalker.oscogvm$ uname -a > > Darwin McStalker 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 > 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 > > McStalker.oscogvm$ git --version > > git version 1.9.5 (Apple Git-50.3) > > McStalker.oscogvm$ git describe > > fatal: No names found, cannot describe anything. > > McStalker.oscogvm$ git describe --long > > fatal: No names found, cannot describe anything. > > McStalker.oscogvm$ > > That confused me also for a moment. Its only because there are not > yet any tags. > Try this... > $ git tag -a mytag -m "my message" > $ git describe --long --dirty > $ touch x > $ git add x > $ git commit -m "blah de blah" > $ git describe --long --dirty > $ echo blah > x > $ git describe --long --dirty > > Plus these tags can be applied retroactively without affecting history... > https://git-scm.com/book/en/v2/Git-Basics-Tagging > > cheers -ben > It might be a good idea to tag the last (or first?) commit after the migration. But how do we do tagging? Have we decided on anything yet (e.g. [1])? Shall we start with v1.0.0 or shall v1.0.0 be the very first stable release of the OpenSmalltalk VM? Or would `201606171704` be a tag? We certainly shouldn't confuse people with these numbers and the version number of the VM. Cheers, Fabio [1] http://semver.org/ > > > > >> >> how secure does this need to be? One way to differentiate the > official > >> >> VMs is to sign them directly on Travis (which we'll want to do > anyway, > >> >> just didn't get to it, yet). > >> >> > >> >> Another option is to just change the URL replacement code to do > >> >> something else when not running on Travis --- like adding your > >> >> hostname and path instead --- but this could be fairly easily messed > >> >> with. > >> >> > >> >> Not sure how much malicious intent we want to prevent. > >> > >> Later on we should have Travis signing its build artefacts, but for > >> now keep it simple. > > > > > > The Mac builds already sign provided a certificate is installed and an > environment variable set to point to it. See SIGNING_IDENTITY in > build.macos*/common/Makefile.app > > > >> > >> > >> > > >> > None. I don't think there's malicious intent at all. I do think we > should differentiate between "personal" and Travis builds. It's more for > my own information, so u don't get confused, than to prevent > maliciousness. So do the simplest thing that could possibly work TSTTCPW. > I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm > (path relative to ~eliot). > >> > >> I think `git branch` is as important as `path`. > >> Username could come from `git config user.name | sed 's/ //g' > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/91ac14f2/attachment-0001.htm From lewis at mail.msen.com Sat Jun 18 14:18:20 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Sat Jun 18 14:18:22 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> Message-ID: <20160618141820.GA13878@shell.msen.com> On Fri, Jun 17, 2016 at 09:12:56AM +0200, Tim Felgentreff wrote: > > Dave, > > there are builds for Raspbian on our new bintray page. If all you want > is the latest version, you should be able to just use these, no need > to compile yourself: > https://bintray.com/opensmalltalk/vm/cog/201606161953/view#files > Hi Tim, The latest VM at bintray works fine, thanks. I also tried running the Squeak 5.0 all-in-one. It crashes. Yikes. The attached nohup.out shows the error. Has this been reported before? Dave > > On 17 June 2016 at 03:40, David T. Lewis wrote: > > > > On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote: > >> > >> I finally got a moment to look at this - not that I really have much clue > >> about the whole unix process thing - and it appears that something is odd > >> with the compiled code in the plugin. > >> > >> My test is very simple - run the UnixProcess class>listDirectory example. > >> It exits with a segfault and the forkAndExec??? method as the last thing > >> on the stack. > >> > >> I build a debug vm (and had some fun with asserts and the ARM fp offset in > >> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling > >> the plugin with varying levels of optimisation, since we???ve fairly regularly > >> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. > >> Nice. > >> > >> Ideas? > >> > > > > I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and > > setup advice). Very cool. My only usability complaint is that the TV monitor > > is in the next room, so I am getting a stiff neck trying to look at the monitor > > while I type on my chiclet keyboard here in the kitchen. But it works, and it > > is a real computer. > > > > I started by compiling an interpreter VM to run against "trunk level" V3 image > > with OSProcess/CommandShell loaded. What I found so far: > > > > - The 32-bit VM running 64-bit image does not work, cannot load X11 driver. > > This used to work 6 or 8 years ago on 64 bit x86, so probably some regression > > because I have not been testing on 32-bit host, and Raspbian is 32-bit. > > > > - After loading OSProcess/CommandShell, I was getting errors, something like > > fork not being able to allocate memory. Sorry, I did not capture the error, > > and it's gone now. > > > > - I then ran the OSP/CommandShell test suite. This crashed my login session > > and took me to a login prompt. WTF?!? This is supposed to be impossible on > > a Unix system. I'm still provisionally impressed with Raspbian, but ... > > > > - I logged back in and ran the OSP/CommandShell tests again. Everything looks > > good now, except that tests related to file locking protocol are failing. > > These are rarely used functions and may be linux distro dependent, so I'm > > not worried about these failures. > > > > - RemoteTask seems to be working also. Nice. > > > > - Overall, most of the OSProcess functionality seems to be just working, so > > that is a pleasant surprise. > > > > - I have gotten a few image lockups. I don't think it is related to OSProcess, > > more likely that I am trying to use a "trunk level" V3 image, maybe a bit > > buggy at this point. > > > > I will try setting up a Cog/Spur build next, and see what that looks like. > > But probably not tonight :-) > > > > Dave > > -------------- next part -------------- /home/pi/squeak/Squeak5.0/Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/bin/squeak Illegal instruction Sat Jun 18 01:01:26 2016 /home/pi/squeak/Squeak5.0/Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/lib/squeak/5.0-3397/squeak Squeak VM version: 5.0-3397 Mon Jul 6 15:05:07 PDT 2015 gcc 4.6.3 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-eem.1405 uuid: 7aff388a-73ba-4202-bb5a-72b0759ff46b Jul 6 2015 With: StackToRegisterMappingCogit VMMaker.oscog-eem.1401 uuid: 036f0933-639a-49dd-8a1d-a03bcdcb0a0a Jul 3 2015 Revision: VM: r3397 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2015-07-06 11:56:39 -0700 Plugins: r3347 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Build host: Linux pi2 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux plugin path: /home/pi/squeak/Squeak5.0/Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/bin/../lib/squeak/5.0-3397 [default: /home/pi/squeak/Squeak5.0/Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/lib/squeak/5.0-3397/] C stack backtrace & registers: r0 0x000006cd r1 0x00000000 r2 0x0153cd64 r3 0x01501230 r4 0x01e501d8 r5 0x0200a9e8 r6 0x00000000 r7 0x0200ad98 r8 0x000006be r9 0x001f6598 r10 0x001e7d66 fp 0x7e831318 ip 0x000006bf sp 0x7e831308 lr 0x015523e8 pc 0x01552a0c *[0x0] [0x0] Smalltalk stack dump: 0x7e831318 M FlapTab(Morph)>wantsSteps 0x2063018: a(n) FlapTab 0x7e831330 M FlapTab(Morph)>intoWorld: 0x2063018: a(n) FlapTab 0x7e831360 M PasteUpMorph(Morph)>privateAddMorph:atIndex: 0x18292e8: a(n) PasteUpMorph 0x7e831388 I PasteUpMorph(Morph)>addMorph:inFrontOf: 0x18292e8: a(n) PasteUpMorph 0x7e8313b4 M [] in PasteUpMorph(Morph)>addMorphInFrontOfLayer: 0x18292e8: a(n) PasteUpMorph 0x7e8313d8 M Array(SequenceableCollection)>do: 0x182af10: a(n) Array 0x7e8313f8 M PasteUpMorph(Morph)>addMorphInFrontOfLayer: 0x18292e8: a(n) PasteUpMorph 0x7e831414 M PasteUpMorph>addMorphFront: 0x18292e8: a(n) PasteUpMorph 0x7e831440 I [] in PasteUpMorph>addGlobalFlaps 0x2138780: a(n) PasteUpMorph 0x7e831460 M OrderedCollection>do: 0x182a8d8: a(n) OrderedCollection 0x7e83148c I PasteUpMorph>addGlobalFlaps 0x2138780: a(n) PasteUpMorph 0x7e8314ac I PasteUpMorph>installFlaps 0x2138780: a(n) PasteUpMorph 0x7e8314cc I PasteUpMorph>install 0x2138780: a(n) PasteUpMorph 0x7e8314f4 I AutoStart class>checkForUpdates 0x200d658: a(n) AutoStart class 0x7e831514 M AutoStart class>startUp: 0x200d658: a(n) AutoStart class 0x7e831540 M [] in SmalltalkImage>send:toClassesNamedIn:with: 0x203cc50: a(n) SmalltalkImage 0x7e831568 I OrderedCollection>do: 0x22b19a0: a(n) OrderedCollection 0x7e831590 I SmalltalkImage>send:toClassesNamedIn:with: 0x203cc50: a(n) SmalltalkImage 0x7e8315bc I SmalltalkImage>processStartUpList: 0x203cc50: a(n) SmalltalkImage 0x7e8315e8 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded: 0x203cc50: a(n) SmalltalkImage 0x29b4d78 s SmalltalkImage>snapshot:andQuit:embedded: 0x2075320 s SmalltalkImage>snapshot:andQuit: 0x29a5f30 s TheWorldMenu>quitSession 0x29a7fe8 s PasteUpMorph>windowEvent: 0x29aa170 s PasteUpMorph(Morph)>handleWindowEvent: 0x29aa790 s WindowEvent>sentTo: 0x29aa7f0 s PasteUpMorph(Morph)>handleEvent: 0x29aa850 s MorphicEventDispatcher>dispatchWindowEvent:with: 0x29aa8b0 s MorphicEventDispatcher>dispatchEvent:with: 0x29aa910 s PasteUpMorph(Morph)>processEvent:using: 0x29aa970 s PasteUpMorph>processEvent:using: 0x29aa9d0 s PasteUpMorph(Morph)>processEvent: 0x29aaa30 s HandMorph>sendEvent:focus:clear: 0x29aaa90 s HandMorph>sendEvent:focus: 0x29aaaf0 s HandMorph>handleEvent: 0x29aab50 s HandMorph>processEvents 0x29aabb0 s [] in WorldState>doOneCycleNowFor: 0x29aac10 s Array(SequenceableCollection)>do: 0x29aae10 s WorldState>handsDo: 0x29aae70 s WorldState>doOneCycleNowFor: 0x29aaed0 s WorldState>doOneCycleFor: 0x29aaf30 s PasteUpMorph>doOneCycle 0x23bcf58 s [] in MorphicProject>(nil) 0x1fd1f98 s [] in BlockClosure>(nil) Most recent primitives - basicNew \\ basicNew \\ \\ \\ \\ \\ = basicNew \\ \\ basicNew @ perform:with: @ @ perform:with: @ \\ \\ \\ value \\ \\ \\ // digitCompare: // // // // // // // // scaledIdentityHash scaledIdentityHash scaledIdentityHash \\ \\ \\ scaledIdentityHash scaledIdentityHash scaledIdentityHash \\ \\ basicNew basicNew basicNew new: \\ privateRGB \\ \\ \\ \\ basicNew @ @ @ @ replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: \\ \\ \\ basicNew @ \\ \\ @ @ // @ @ @ @ @ @ @ @ @ // @ @ @ @ @ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ @ @ // // > @ @ @ @ shallowCopy shallowCopy value: \\ stringHash:initialHash: \\ \\ value privateAddMorph:atIndex: privateAddMorph:atIndex: **StackOverflow** \\ \\ \\ \\ @ perform:with: @ @ perform:with: @ @ @ value: copyWithout: replaceFrom:to:with:startingAt: \\ replaceFrom:to:with:startingAt: \\ \\ \\ \\ \\ \\ \\ value: \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ @ perform:with: @ @ perform:with: @ @ @ \\ \\ \\ value: value: size replaceFrom:to:with:startingAt: compare:with:collated: instVarAt: value: instVarAt: instVarAt: instVarAt: compare:with:collated: instVarAt: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: compare:with:collated: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: instVarAt: replaceFrom:to:with:startingAt: compare:with:collated: compare:with:collated: instVarAt: value: \\ stringHash:initialHash: \\ scanFor: \\ \\ **StackOverflow** \\ \\ \\ \\ @ perform:with: @ @ perform:with: @ @ @ replaceFrom:to:with:startingAt: \\ replaceFrom:to:with:startingAt: - \\ \\ \\ \\ stack page bytes 4096 available headroom 2788 minimum unused headroom 24 (Illegal instruction) Aborted From tim at rowledge.org Sat Jun 18 16:56:21 2016 From: tim at rowledge.org (tim Rowledge) Date: Sat Jun 18 16:56:09 2016 Subject: [Vm-dev] Cog + Pi + OSProcess In-Reply-To: <20160618141820.GA13878@shell.msen.com> References: <695CDB5C-DAC7-48EF-998C-AB3EC615F26D@veloxit.no> <5876F79D-7604-4039-8E92-AE0E767D7587@rowledge.org> <20160617014053.GA17233@shell.msen.com> <20160618141820.GA13878@shell.msen.com> Message-ID: <994E9FDB-DBAB-415D-B8A5-03C5A318D30D@rowledge.org> > On 18-06-2016, at 7:18 AM, David T. Lewis wrote: > > I also tried running the Squeak 5.0 all-in-one. It crashes. Yikes. > > The attached nohup.out shows the error. Has this been reported before? I suspect that it could be the CPIC problem where we had to redesign the CPIC.. except the 5.0 all-in-one should postdate the fix for that by some time? oh, maybe not. The AiO vm is date last July and the CPIC change was last October, after I got my first prototype Pi3. So, almost certainly bad CPIC. We ought to fix the AiO soon, but we?re heading towards that anyway. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 4) "This machine is a piece of GAGH! I need dual G5 processors if I am to do battle with this code!" From commits at source.squeak.org Sat Jun 18 18:19:50 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sat Jun 18 18:19:51 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.125.mcz Message-ID: Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.125.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.125 Author: tty Time: 18 June 2016, 1:24:08.924628 pm UUID: 5aebcc78-d7e1-4b52-8c70-2251899215cb Ancestors: CMakeVMMakerSqueak-tty.124 Decoupled CMakeVMMakerSqueak from CMakeVMMaker. All tests pass, output generated. Next Up: Build a 64x64 squeak.cog.spur Configuration. Update/verify Help Tutorial accurately reflects process. Debug CMake errors that popped up with Ian's TestBigEndian macro: CMake Error at /usr/share/cmake-2.8/Modules/TestBigEndian.cmake:44 (message): no suitable type found Call Stack (most recent call first): config.cmake:40 (TEST_BIG_ENDIAN) CMakeLists.txt:162 (include) =============== Diff against CMakeVMMakerSqueak-tty.124 =============== Item was changed: SystemOrganization addCategory: #CMakeVMMakerSqueak! SystemOrganization addCategory: #'CMakeVMMakerSqueak-BSD32x86'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Builder'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-CMakeCompositeTemplates'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-CMakeCustomTemplates'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-CMakeTemplates'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Help'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-IA32-Bochs'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-IOS'! - SystemOrganization addCategory: #'CMakeVMMakerSqueak-Libs'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Linux32ARMv6'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Linux32x86'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Linux64x64'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-MacOSPowerPC'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-MacOSX32x86'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-SunOS32x86'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Tests'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-VMPlugins'! SystemOrganization addCategory: #'CMakeVMMakerSqueak-Win32x86'! Item was changed: ----- Method: CMakeVMGeneratorForSqueak>>generateByTemplate (in category 'code generation') ----- generateByTemplate "The bulk of CMake generation happens here. See CPlatformConfigForSqueak>>initialize for CMake output. that occurs prior to this method. (This may change on refactoring) Think Seaside renderOn composition. " | extPlugins intPlugins | self flag: 'tty'. "refactor so that the cascade reflects CMake terminilogy" output := String new writeStream. config templates: OrderedCollection new. config setGlobalOptions: self; cmakePrefixPath; cmakeIncludePath; cmakeLibraryPath; cmakeIncludeModules; cmakeCFlags; cmakeAddDefinitions; cmakeWriteDirectoriesDotCmake: self; cmakeIncludeDirectories: self; "<---" preferredIncludes; "<---why 3 of em?" standardIncludes; "<---" setGlobalOptionsAfterDetermineSystem: self; extraVMSettings: self; "<--catch-all method. os/platform specific" setCoreSources: self; setPlatformSources: self; setCrossSources: self; setExtraSources; cmakeSetSourceFilesProperties; cmakeListAppend:'LINKLIBS' elements: (config externalLibs); cmakeAddExecutableNameOptionSource: self; setExecutableOutputPath; addVMPlugins: self. config templates do: [:each | self puts: each content]. config templates: OrderedCollection new. extPlugins := self generatePluginConfigs: config internalPlugins internal: true. intPlugins := self generatePluginConfigs: config externalPlugins internal: false. + self flag:'tty: pharo code would download and install libraries. I think detection belongs in CMake and user should set up their own system for squeak. '. + " self processThirdpartyLibraries. " - self processThirdpartyLibraries. "<--unused in Pharo code? What exactly does this do?" self processPlugins: intPlugins, extPlugins. self config templates addLast:((CMakeCommand new) command:'target_link_libraries' params:(self moduleName , ' ${LINKLIBS}')). " self cmd: 'target_link_libraries' params: self moduleName , ' ${LINKLIBS}'." config postBuildActions: self.. config templates do: [:each | self puts: each content]. self saveFile. self generateBuildScript! Item was removed: - ----- Method: CMakeVMMakerSqueakCommonConfigTest>>testCommonCompilerFlags (in category 'as yet unclassified') ----- - testCommonCompilerFlags - #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig) - do:[:each | - (Smalltalk at:each) - allSubclassesDo:[:configuration | | o | - configuration isAbstractBaseClass "*" - ifFalse:[ o:= configuration basicNew. - self assert:(o commonCompilerFlags isKindOf: Collection)]]]. - - "* - SqueakWin32x86Config browse - the return array embeds 'self executableName' which does not exist in an AbstractBaseClass - " - - - - - - - - ! Item was added: + ----- Method: CMakeVMMakerSqueakCommonConfigTest>>testIsLittleEndian (in category 'as yet unclassified') ----- + testIsLittleEndian + #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig) + do:[:each | + (Smalltalk at:each) + allSubclassesDo:[:configuration | | o | + configuration isAbstractBaseClass not + ifTrue:[ + o:= configuration basicNew. + (o excludeFromBuild not) + ifTrue:[ self assert:(o isLittleEndian)]]]] + + + + + + + + ! Item was removed: - ----- Method: CMakeVMMakerSqueakRedirectMethodsTest>>testCommonCompilerFlags (in category 'as yet unclassified') ----- - testCommonCompilerFlags - #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) - do:[:each | - (Smalltalk at:each) - allSubclassesDo:[:configuration | | o buildTypes| - o:= configuration basicNew. - (o excludeFromBuild not) & (configuration isAbstractBaseClass not) - ifTrue:[ - buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). - buildTypes do:[:buildType | - o configureForBuildType: buildType. - self assert:(o commonCompilerFlags isArray)]]]]. - ! Item was removed: - ----- Method: CMakeVMMakerSqueakRedirectMethodsTest>>testThirdPartyLibs (in category 'as yet unclassified') ----- - testThirdPartyLibs - #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) - do:[:each | - (Smalltalk at:each) - allSubclassesDo:[:configuration | | o buildTypes| - o:= configuration basicNew. - (o excludeFromBuild not) & (configuration isAbstractBaseClass not) - ifTrue:[ - buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). - buildTypes do:[:buildType | - o configureForBuildType: buildType. - self assert:(o thirdpartyLibs isKindOf: Collection). - ]]]]. - - - - - - - - ! Item was removed: - ----- Method: CMakeVMMakerSqueakRedirectMethodsWithArgTest>>testSetExtraTargetProperties (in category 'as yet unclassified') ----- - testSetExtraTargetProperties - self flag:'tty'. "Is the self shouldnt sufficient?" - #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) - do:[:each | - (Smalltalk at:each) - allSubclassesDo:[:configuration | | o buildTypes vmGenerator| - o:= configuration basicNew. - (o excludeFromBuild not) & (configuration isAbstractBaseClass not) - ifTrue:[ - buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). - buildTypes do:[:buildType | - o configureForBuildType: buildType. - vmGenerator:=CMakeVMGeneratorForSqueak new. - vmGenerator config: o. - vmGenerator output:(String new writeStream). - self shouldnt: [o setExtraTargetProperties: vmGenerator] raise: Error]]]]. - ! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>pages (in category 'accessing') ----- pages "platformSources...cogitClass...src vs vmsrc" ^#( overview tests identifyPlatform identifyPlatformAbstractBaseClass identifyBuilder createTheConfiguration excludingConfigFromBuilds setAvailableBuildTypes firstCMakeGeneration tackingStockOne cPlatformConfigForSqueak methodRedirectPattern theVMGenerator tackingStockTwo cPlatformConfigForSqueakInitialize initializePlatformSources customizePlatformSources initializeVMPlugins customizeVMPlugins configGenerateByTemplate specifyCogitClass vmsrc specifyDirectories dirBuildLanguageVMMM setGlobalOptions cmakePrefixPath cmakeIncludePath cmakeLibraryPath cmakeIncludeModules cmakeCFlags cmakeAddDefinitions cmakeWriteDirectoriesDotCmake cmakeIncludeDirectories preferredIncludes standardIncludes setGlobalOptionsAfterDetermineSystem extraVMSettings setCoreSources setPlatformSources setCrossSources setExtraSources cmakeSetSourceFilesProperties cmakeListAppendLINKLIBSelements cmakeAddExecutableNameOptionSource setExecutableOutputPath addVMPlugins generatePluginConfigs specifyPlugins - processThirdpartyLibraries processPlugins postBuildActions generateBuildScript fin ) ! Item was removed: - ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>processThirdpartyLibraries (in category 'pages') ----- - processThirdpartyLibraries - ^HelpTopic - title:'Process Third Party Libraries' - contents: - 'Within the broad outline of this tutorial, you are here: - 8. Customizing your Configuration. - - SystemNavigation browseAllImplementorsOf: #processThirdpartyLibraries - - I have no idea what this does. It exists in the pharo codebase. - - If I do figure out its utility, then the processing architecture will be similar or identical to the Plugin processing. - - i.e. Libraries will be represented by objects which will have the responsibility of generating ''stuff''. - - - - .'! Item was changed: + Object subclass: #CPlatformConfigForSqueak - CPlatformConfig subclass: #CPlatformConfigForSqueak instanceVariableNames: 'buildType cogDir generateBuild generateBuildAssert generateBuildAssertITimerHeartbeat generateBuildDebug generateBuildDebugITimerHeartbeat generateBuildDebugMultiThreaded generateBuildIHeartbeatTimer generateBuildMultiThreaded generateBuildMultiThreadedAssert generateBuildMultiThreadedDebug templates enabledebugmessages platformSources vmplugins' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak'! CPlatformConfigForSqueak class instanceVariableNames: 'isAbstractBaseClass'! !CPlatformConfigForSqueak commentStamp: 'tty 12/8/2014 11:28' prior: 0! A CPlatformConfigForSqueak acts as a compatability layer for Squeak and an Abstract Base Class for extended functionality required for the Squeak CMakeVMMaker use-case. I make (very) heavy use of a specific design pattern for configuring myself and remaining compatible with pharo's CMakeVMMaker. The entry point for that pattern is my method 'configureForBuildType: aSymbol' . Each method send in there detects my buildType and routes the send to the approriate method for that buildType. Subclasses of me 'must' configure themselves for each build type per that pattern. However this can be very easy by just returning the base configuration. Tests are written to verify that this support infrastructure is in place. I have two important methods. excludeFromBuild and isAbstractBaseClass. excludeFromBuild is used to exclude a configuration from being built by a Builder. is used to exclude a configuration from Testing. isAbstractBaseClass is used by configurations that exclude themselves from being built by a Builder BUT need to be included in Testing. excludeFromBuild | isAbstractBaseClass | should build | should test T T NO YES T F NO NO F T YES YES F F YES YES The use-case is as follows. An abstract base class contains a lot of functionality that must be implemented and tested for the system to work, but it is not meant to be compiled. concrete classes of that AbstractBase class can exclude themselves from being built by builders and by doing so are not tested. However, once a concrete configuration is enabled to be built, it must pass all tests. Linux32x86Config is an example of an AbstractBase class that must pass all testing, but is not buildable. Its subclass Linux32x86SqueakCogV3Config needs testing, but a developer can toggle 'exclude from build' to hide it from Builders or make it available to them. Tests make the decision on what configurations to test. Here are some examples. (o excludeFromBuild not) & (configuration isAbstractBaseClass not) this is a concrete [Lang][VM][MemoryManager][etc] configuration that will be built. No platform classes considered (o excludeFromBuild) & (configuration isAbstractBaseClass not) This is a concrete [Lang][VM][MemoryManager][etc] configuration that will be NOT built. (o excludeFromBuild not) | (configuration isAbstractBaseClass) concrete implementation may depend on its [OS][VMWordSize][Processor] AbstractBaseClass for platform level methods. example: Linux32x86Config ccBuild has the '-m32' compiler flag that is common to all builds on that platform (o excludeFromBuild not) & (configuration isAbstractBaseClass) Not allowed. [OS][VMWordSize][Processor] AbstractBaseClasses should not be built. This is a useful test in its own right. (o excludeFromBuild) & (configuration isAbstractBaseClass) These are the AbstractBaseClasses. An AbstractBaseClass should always be excluded from a build HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp tty.! CPlatformConfigForSqueak class instanceVariableNames: 'isAbstractBaseClass'! Item was changed: ----- Method: CPlatformConfigForSqueak>>compilerFlags (in category 'compiling') ----- compilerFlags - self flag:'tty'. "This goes away if we agree to fork the project. " self deprecated:' this catchall method has been split into dedicated methods: cmakePrefixPath cmakeIncludePath cmakeLibraryPath cmakeIncludeModules; cmakeCFlags; '. "see method ''generate'' in CMakeVMGeneratorForSqueak browse for old call. " self cmakeCFlags. "The old CMakeVMMaker loaded all kinds of stuff in compilerflags that where really pre-processor definitions etc. I have factored them out in the interest of clarity and simplicity. "! Item was added: + ----- Method: CPlatformConfigForSqueak>>defaultExternalPlugins (in category 'plugins') ----- + defaultExternalPlugins + self shouldBeImplemented ! Item was added: + ----- Method: CPlatformConfigForSqueak>>defaultInternalPlugins (in category 'plugins') ----- + defaultInternalPlugins + self shouldBeImplemented ! Item was added: + ----- Method: CPlatformConfigForSqueak>>dirPlatforms (in category 'cmake directory') ----- + dirPlatforms + ^'platforms'! Item was added: + ----- Method: CPlatformConfigForSqueak>>doesNotUnderstand: (in category 'utils') ----- + doesNotUnderstand: aMessage + " ignore configureXYZ: messages " + + | sel | + sel := aMessage selector. + + ((sel beginsWith: 'configure') and: [ + (sel indexOf: $: ) = sel size ] ) ifTrue: [ ^ self ]. + + ^ super doesNotUnderstand: aMessage! Item was added: + ----- Method: CPlatformConfigForSqueak>>isLittleEndian (in category 'testing') ----- + isLittleEndian + "default is true. Override if necessary" + ^ true! Item was added: + ----- Method: CPlatformConfigForSqueak>>platformName (in category 'accessing') ----- + platformName + "override in subclass" + self subclassResponsibility ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>prepareForGeneration (in category 'source generation') ----- - prepareForGeneration - "feel free to override me" - |i| - self flag:'tty'. - i:= self interpreterClass. - ((i == CoInterpreter) | (i == CoInterpreterMT )) - ifTrue:[self prepareForCogGeneration]. "what is more efficient? self or super? tty." - (i == StackInterpreter) - ifTrue:[self prepareForStackVMGeneration]. - - ! Item was changed: ----- Method: CPlatformConfigForSqueak>>prepareVMMaker (in category 'squeak compatability') ----- prepareVMMaker | maker allPlugins | "In CogVMs (in contrast to Interpreter VM) the generated sources are platform independent, therefore Cross is ok" maker := VMMaker forPlatform: 'Cross'. maker sourceDirectoryName: self srcDir pathName. + maker platformRootDirectoryName: self dirPlatforms. - maker platformRootDirectoryName: self platformsDir. allPlugins := self internalPlugins , self externalPlugins. "touch plugins to force their source generation unconditionally" allPlugins do: [:name | (Smalltalk globals at: name) touch ]. " Why we put all plugins as external? Because the generated sources are not different whether the plugins were defined as internal or external. VMMaker used to need this to to generate plugins.int and plugins.ext files. But since this is achieved in another way with CMakeVMMaker, there is no different at all to put all plugins as internal or as external." maker externalModules addAll: allPlugins. ^ maker! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibs (in category 'cmake buildType redirects') ----- - thirdpartyLibs - "Route this message send to the message appropriate for my buildType " - |d | - d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. - d - at: #build put: [self thirdpartyLibsBuild]; - at: #buildAssert put: [self thirdpartyLibsBuildAssert]; - at: #buildAssertITimerHeartbeat put: [self thirdpartyLibsBuildAssertITimerHeartbeat]; - at:#buildDebug put: [self thirdpartyLibsBuildDebug]; - at: #buildDebugITimerHeartbeat put: [self thirdpartyLibsBuildDebugITimerHeartbeat ]; - at: #buildITimerHeartbeat put: [self thirdpartyLibsBuildITimerHeartbeat]; - at: #buildMultiThreaded put: [self thirdpartyLibsBuildMultiThreaded]; - at: #buildMultiThreadedAssert put: [self thirdpartyLibsBuildMultiThreadedAssert]; - at: #buildMultiThreadedDebug put: [self thirdpartyLibsBuildMultiThreadedDebug ]; - at: #buildNone put:[self thirdpartyLibsBuildNone]. - ^(d at: buildType) value - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuild (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuild - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - - do nothing is an option - " - self subclassResponsibility - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildAssert (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildAssert - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildAssertITimerHeartbeat - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildDebug (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildDebug - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildDebugITimerHeartbeat - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildITimerHeartbeat - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildMultiThreaded (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreaded - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreadedAssert - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreadedDebug - "convenience method to customize third party libs for this buildType. - - SystemNavigation default browseMethodsWhoseNamesContain: 'addThirdpartyLibrary:' - - SystemNavigation default browseMethodsWhoseNamesContain: 'processThirdpartyLibraries' - - SystemNavigation default browseMethodsWhoseNamesContain: 'thirdpartyLibs' - " - ^ self thirdpartyLibsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>thirdpartyLibsBuildNoBuildType (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildNoBuildType - "SHOULD NOT GET HERE" - self shouldNotImplement. - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>x (in category 'cmake buildType redirects') ----- - x - "Route this message send to the message appropriate for my buildType " - |d | - d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. - d - at: #build put: [self xBuild]; - at: #buildAssert put: [self xBuildAssert]; - at: #buildAssertITimerHeartbeat put: [self xBuildAssertITimerHeartbeat]; - at:#buildDebug put: [self xBuildDebug]; - at: #buildDebugITimerHeartbeat put: [self xBuildDebugITimerHeartbeat ]; - at: #buildITimerHeartbeat put: [self xBuildITimerHeartbeat]; - at: #buildMultiThreaded put: [self xBuildMultiThreaded]; - at: #buildMultiThreadedAssert put: [self xBuildMultiThreadedAssert]; - at: #buildMultiThreadedDebug put: [self xBuildMultiThreadedDebug ]; - at: #buildNone put:[self xNoBuildType]. - ^(d at: buildType) value! Item was added: + ----- Method: InterpreterPlugin class>>generateFor:internal: (in category '*CMakeVMMakerSqueak') ----- + generateFor: aCMakeVMGenerator internal: aBoolean + + ^ aCMakeVMGenerator + generatePlugin: self + internal: aBoolean + extraRules: nil! Item was removed: - SqueakCMThirdpartyLibrary subclass: #SqueakCMFreetype2 - instanceVariableNames: '' - classVariableNames: '' - poolDictionaries: '' - category: 'CMakeVMMakerSqueak-Libs'! - - !SqueakCMFreetype2 commentStamp: '' prior: 0! - This is a configuration for building freetype2 library! Item was removed: - ----- Method: SqueakCMFreetype2 class>>canonicalName (in category 'accessing') ----- - canonicalName - ^ 'freetype2'! Item was removed: - ----- Method: SqueakCMFreetype2>>archiveMD5Sum (in category 'package properties') ----- - archiveMD5Sum - - ^ 'c15f6dc8ed190d67b89ae09aaf7896b4'! Item was removed: - ----- Method: SqueakCMFreetype2>>build (in category 'generating actions') ----- - build - - gen - puts: - ' - add_custom_command(OUTPUT "${ft2config}" - COMMAND ./configure --prefix=''${installPrefix}'' ', self configurationFlags, ' - WORKING_DIRECTORY "${libSourcesDir}" - DEPENDS "${unpackTarget}" - ) - add_custom_command(OUTPUT "${ft2libInstalled}" - COMMAND make - COMMAND make install - WORKING_DIRECTORY "${libSourcesDir}" - DEPENDS "${ft2config}" - COMMENT "Building ${libName}" - ) - ' - ! Item was removed: - ----- Method: SqueakCMFreetype2>>copyArtefacts (in category 'generating actions') ----- - copyArtefacts - - self - copy: '${ft2libInstalled}' - to: '${externalModulesDir}/${libraryFileName}'.! Item was removed: - ----- Method: SqueakCMFreetype2>>defineAsTarget (in category 'generating actions') ----- - defineAsTarget - - gen puts: - - ' - add_custom_target(${libName} - DEPENDS ${externalModulesDir}/${libraryFileName} - ) - ' - - ! Item was removed: - ----- Method: SqueakCMFreetype2>>defineGlobalTargets (in category 'generating actions') ----- - defineGlobalTargets - | var | - var := self canonicalName , '_LIB'. - vmGen set: var toString: self targetForLinking. - " - define a library as imported one - and make it depend from it's build target - " - vmGen - puts: - ('add_library("{1}" SHARED IMPORTED GLOBAL) - set_target_properties("{1}" PROPERTIES IMPORTED_LOCATION "{1}") - add_dependencies("{1}" "{2}") - ' format: { '${',var, '}' . self buildTarget } - ). - - vmGen cmd: 'add_dependencies' params: - vmGen moduleName , ' ' , self buildTarget! Item was removed: - ----- Method: SqueakCMFreetype2>>downloadURL (in category 'package properties') ----- - downloadURL - ^ 'http://ftp.igh.cnrs.fr/pub/nongnu/freetype/freetype-2.4.9.tar.gz' - ! Item was removed: - ----- Method: SqueakCMFreetype2>>includeDir (in category 'accessing') ----- - includeDir - "see setVariables" - - " `/include/freetype2' must be in your current inclusion path " - - - ^ '"${thirdpartyDir}/out/include" "${thirdpartyDir}/out/include/freetype2"'! Item was removed: - ----- Method: SqueakCMFreetype2>>libraryFileName (in category 'package properties') ----- - libraryFileName - ^ 'libfreetype.6.dylib'! Item was removed: - ----- Method: SqueakCMFreetype2>>setVariables (in category 'generating actions') ----- - setVariables - super setVariables. - - "add include path" - gen - set: #freetype2_includeDir toString: '${installPrefix}/include'; - set: #libraryFileName to: self libraryFileName; - set: #freetype2_location toString: '${externalModulesDir}/${libraryFileName}'; - set: #ft2config toString: '${libSourcesDir}/builds/unix/config.status'; - set: #ft2libInstalled toString: '${installPrefix}/lib/${libraryFileName}'! Item was removed: - ----- Method: SqueakCMFreetype2>>unpackedDirName (in category 'package properties') ----- - unpackedDirName - - ^ 'freetype-2.4.9'! Item was removed: - SqueakCMThirdpartyLibrary subclass: #SqueakCMOpenSSL - instanceVariableNames: '' - classVariableNames: '' - poolDictionaries: '' - category: 'CMakeVMMakerSqueak-Libs'! Item was removed: - ----- Method: SqueakCMOpenSSL class>>canonicalName (in category 'as yet unclassified') ----- - canonicalName - ^ 'openssl'! Item was removed: - CMThirdpartyLibrary subclass: #SqueakCMThirdpartyLibrary - instanceVariableNames: '' - classVariableNames: '' - poolDictionaries: '' - category: 'CMakeVMMakerSqueak-Libs'! - - !SqueakCMThirdpartyLibrary commentStamp: 'tty 12/8/2014 11:25' prior: 0! - N.B. tty: I have not parsed these in depth as of 2014.12.09 - - A SqueakCMThirdpartyLibrary is the root library for copies of classes in CMakeVMMaker-Libs. - I replace only the Squeak incompatible methods of my parent - - ! Item was removed: - ----- Method: SqueakCMThirdpartyLibrary class>>canonicalName (in category 'as yet unclassified') ----- - canonicalName - "answer the library canonical name, like - 'freetype2' - or 'cairo' - etc. - - Note , this method is used to find the corresponding library - from all subclasses of CMThirdpartyLibrary - " - ^ self subclassResponsibility! Item was removed: - ----- Method: SqueakCMThirdpartyLibrary class>>named:config: (in category 'as yet unclassified') ----- - named: aName config: aCPlatformConfig - - ^ (self allSubclasses detect: [:cls | - cls canonicalName = aName and: [ cls supports: aCPlatformConfig ] ]) - new! Item was removed: - ----- Method: SqueakCMThirdpartyLibrary class>>platformName (in category 'as yet unclassified') ----- - platformName - ^nil! Item was removed: - ----- Method: SqueakCMThirdpartyLibrary class>>supports: (in category 'as yet unclassified') ----- - supports: aConfig - "default implementation" - ^ self platformName = aConfig platformName ! Item was removed: - ----- Method: SqueakCMThirdpartyLibrary>>generateFor: (in category 'as yet unclassified') ----- - generateFor: aVMGenerator - - | libDir stream contents | - self flag:'tty'. "This l must be transformed to generateByTemplateFor: and the output converted to CMakeTemplates" - self break. - vmGen := aVMGenerator. - - gen := CMakeGeneratorForSqueak new - output: (String new writeStream). - - libDir := (aVMGenerator thirdpartyDir / self canonicalName) assureExistence. - - stream := String new writeStream. - - self generate. - - stream nextPutAll: (vmGen config fixLineEndsOf: gen output contents). - - contents := stream contents. - - (self isFile: (libDir / gen outputFileName) fullName hasContents: contents) ifFalse: [ - "contents changed, update the file. Because fucking cmake will force rebuild everything if we change its modification date - without changing its contents" - (FileStream forceNewFileNamed: (libDir / gen outputFileName) pathName) nextPutAll: contents; close. - ]. - - - vmGen addSubdirectory: vmGen thirdpartyDirName , '/' , self canonicalName. - self defineGlobalTargets. - ! Item was removed: - SqueakCMFreetype2 subclass: #SqueakCMWin32Freetype2 - instanceVariableNames: '' - classVariableNames: '' - poolDictionaries: '' - category: 'CMakeVMMakerSqueak-Libs'! - - !SqueakCMWin32Freetype2 commentStamp: '' prior: 0! - Some overrides to make freetype build on windows: - - Two artifacts to copy: - - libfreetype.dll.a - libfreetype-6.dll - - the first one is used at link time with FTPlugin to - designate the exported symbols of .dll as well as .dll file name. - - The second one is ready to use library produced by freetype makefiles. - - We pass - - -march=i686 - - instead of - - -arch i386 - - to freetype configure, because MSYS GCC on windows don't understands the -arch option. - ! Item was removed: - ----- Method: SqueakCMWin32Freetype2 class>>platformName (in category 'as yet unclassified') ----- - platformName - ^'win32'! Item was removed: - ----- Method: SqueakCMWin32Freetype2>>copyArtefacts (in category 'generating actions') ----- - copyArtefacts - - gen puts: - 'add_custom_command( - OUTPUT "${externalModulesDir}/${libraryFileName}" - COMMAND cp "${ft2libInstalled}" "${externalModulesDir}" - COMMAND cp "${ft2binInstalled}" "${externalModulesDir}" - DEPENDS "${ft2libInstalled}" - )'! Item was removed: - ----- Method: SqueakCMWin32Freetype2>>defaultConfigurationFlags (in category 'settings') ----- - defaultConfigurationFlags - ^#( - 'CFLAGS=''-march=i686''' - 'LDFLAGS=''-march=i686''')! Item was removed: - ----- Method: SqueakCMWin32Freetype2>>defineGlobalTargets (in category 'generating actions') ----- - defineGlobalTargets - | var | - var := self canonicalName , '_LIB'. - vmGen set: var toString: self targetForLinking. - " - define a library as imported one - and make it depend from it's build target - " - vmGen - puts: - ('add_library("{1}" STATIC IMPORTED GLOBAL) - set_target_properties("{1}" PROPERTIES IMPORTED_LOCATION "{1}") - add_dependencies("{1}" "{2}") - ' format: { '${',var, '}' . self buildTarget } - ). - - vmGen cmd: 'add_dependencies' params: - vmGen moduleName , ' ' , self buildTarget! Item was removed: - ----- Method: SqueakCMWin32Freetype2>>libraryFileName (in category 'package properties') ----- - libraryFileName - ^ 'libfreetype.dll.a'! Item was removed: - ----- Method: SqueakCMWin32Freetype2>>setVariables (in category 'generating actions') ----- - setVariables - super setVariables. - - "add include path" - gen - set: #freetype2_includeDir toString: '${installPrefix}/include'; - set: #libraryFileName to: self libraryFileName; - set: #freetype2_location toString: '${externalModulesDir}/${libraryFileName}'; - set: #ft2config toString: '${libSourcesDir}/builds/unix/config.status'; - set: #ft2libInstalled toString: '${installPrefix}/lib/${libraryFileName}'; - set: #ft2binInstalled toString: '${installPrefix}/bin/libfreetype-6.dll'. - ! Item was removed: - SqueakCMOpenSSL subclass: #SqueakCMWin32OpenSSL - instanceVariableNames: '' - classVariableNames: '' - poolDictionaries: '' - category: 'CMakeVMMakerSqueak-Libs'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL class>>platformName (in category 'as yet unclassified') ----- - platformName - ^'win32'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>archiveMD5Sum (in category 'as yet unclassified') ----- - archiveMD5Sum - "answer the MD5 checksum (in string) for downloaded library archive - (to check that downloaded file is not corrupt). - - You can take this sum by issuing: - md5 filename - from command line - " - ^ 'ae412727c8c15b67880aef7bd2999b2e'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>build (in category 'as yet unclassified') ----- - build - - gen - puts: - ' - add_custom_command(OUTPUT "${libSourcesDir}/Makefile" - COMMAND ./config shared --prefix=''${installPrefix}'' - WORKING_DIRECTORY "${libSourcesDir}" - DEPENDS "${unpackTarget}" - ) - - add_custom_command(OUTPUT "${installPrefix}/bin/libeay32.dll" "${installPrefix}/bin/ssleay32.dll" - COMMAND make - COMMAND make install - WORKING_DIRECTORY "${libSourcesDir}" - DEPENDS "${libSourcesDir}/Makefile" - COMMENT "Building ${libName}" - ) - ' - ! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>configurationFlags (in category 'as yet unclassified') ----- - configurationFlags - ^ 'shared'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>copyArtefacts (in category 'as yet unclassified') ----- - copyArtefacts - - self copy: '${installPrefix}/bin/libeay32.dll' to: '${externalModulesDir}/libeay32.dll'. - self copy: '${installPrefix}/bin/ssleay32.dll' to: '${externalModulesDir}/ssleay32.dll'. - " self copy: '${installPrefix}/lib/libssl.dll.a' to: '${externalModulesDir}/libssl.dll.a'. - self copy: '${installPrefix}/lib/libcrypto.dll.a' to: '${externalModulesDir}/libcrypto.dll.a'. - " - " - 'libcrypto.dll.a' 'libssl.dll.a'. - "! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>defineAsTarget (in category 'as yet unclassified') ----- - defineAsTarget - - gen puts: - 'add_custom_target(', self buildTarget , ' - DEPENDS - "${externalModulesDir}/libeay32.dll" - "${externalModulesDir}/ssleay32.dll" - )' - - "${externalModulesDir}/${libraryFileName}" - ! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>defineGlobalTargets (in category 'as yet unclassified') ----- - defineGlobalTargets - - ! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>downloadURL (in category 'as yet unclassified') ----- - downloadURL - ^'http://www.openssl.org/source/openssl-1.0.1c.tar.gz'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>includeDir (in category 'as yet unclassified') ----- - includeDir - - ^ '"${thirdpartyDir}/out/include"'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>libraryFileName (in category 'as yet unclassified') ----- - libraryFileName - ^ 'libssl.dll.a'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>setVariables (in category 'as yet unclassified') ----- - setVariables - super setVariables. - - gen - set: #libraryFileName to: self libraryFileName; - set: #libInstalled to: '${installPrefix}/lib/${libraryFileName}'! Item was removed: - ----- Method: SqueakCMWin32OpenSSL>>unpackedDirName (in category 'as yet unclassified') ----- - unpackedDirName - ^ 'openssl-1.0.1c'! Item was changed: ----- Method: SqueakCMakeVMMakerAbstractBuilder>>enableMessageTracking: (in category 'building') ----- enableMessageTracking: aBoolean + (config isKindOf: CPlatformConfigForSqueak) - (config isKindOf: CPlatformConfig) ifTrue:[config enabledebugmessages: aBoolean] ! Item was changed: ----- Method: SqueakCMakeVMMakerAbstractBuilder>>generateSources (in category 'building') ----- generateSources + (config isKindOf: CPlatformConfigForSqueak) - self flag: 'tty'. "This used to work, but it looks like CPlaformConfig>>generateSources breaks at 'maker cogitClass: cg'" - self error:'Pharo CPlatformConfig is broken. Will fix later'. - (config isKindOf: CPlatformConfig) ifTrue:[config generateSources] ! Item was changed: ----- Method: SqueakMacintoshConfig>>cmakeWriteDirectoriesDotCmake: (in category 'cmake') ----- cmakeWriteDirectoriesDotCmake: aMaker |temp o| "We could put these inline, but other components include the directories.cmake file. So, we continue that convention" o := String new writeStream. temp := OrderedCollection new. temp addLast: ((CMakeSet new) variable: 'topDir' quotedValue: (self topDir fullName)); addLast: ((CMakeSet new) variable: 'buildDir' quotedValue: (self buildDir ifNil: ['${topDir}/build'] ifNotNil: [self buildDir fullName])); addLast: ((CMakeSet new) variable: 'thirdpartyDir' quotedValue: '${buildDir}/thirdParty'); + addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self dirPlatforms)); - addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self platformsDir)); addLast: ((CMakeSet new) variable: 'srcDir' quotedValue: (self dirSource pathName)); "where the vm source directory lives" addLast: ((CMakeSet new) variable: 'cogDir' quotedValue: (self cogDir pathName)); "oscogvm/src for historical reasons" addLast: ((CMakeSet new) variable: 'srcPluginsDir' quotedValue: (pluginsDir ifNil: [ '${cogDir}/plugins' ])); "plugin source directory only in oscogvm/src/plugins" addLast: ((CMakeSet new) variable: 'srcVMDir' quotedValue: '${srcDir}/vm'); addLast: ((CMakeSet new) variable: 'platformName' quotedValue: (self platformName)); addLast: ((CMakeSet new) variable: 'targetPlatform' quotedValue: '${platformsDir}/${platformName}'); addLast: ((CMakeSet new) variable: 'crossDir' quotedValue: '${platformsDir}/Cross'); addLast: ((CMakeSet new) variable: 'platformVMDir' quotedValue: '${targetPlatform}/vm}'); addLast: ((CMakeSet new) variable: 'outputDir' quotedValue: (self outputDir fullName)); addLast: ((CMakeSet new) variable: 'externalModulesDir' quotedValue: (self externalModulesDir)). temp do: [:each | o nextPutAll: (each content); cr]. self write: (o contents) toFile: 'directories.cmake'. (enabledebugmessages) ifTrue:[ templates addLast:((CMakeMessage new) message: (self class name), ' setDirectories: aMaker' ) ]. templates addLast: ((CMakeInclude new) file: 'directories.cmake'). ! Item was removed: - ----- Method: SqueakMacintoshConfig>>defaultDirectoriesFromGitDir: (in category 'accessing') ----- - defaultDirectoriesFromGitDir: gitRepository - "Set the default values for all necessary directories taking into account the Git repostiory. An example to use this method is: - MTCocoaIOSCogJitDebugConfig new - defaultDirectoriesFromGitDir: '/Users/mariano/Pharo/vm/git/cogVM/blessed'; - generateSources; - generate. - " - | gitRepositoryString | - self flag:'tty'. "Squeak don't git" - gitRepositoryString := gitRepository, '/'. - self srcDir: gitRepositoryString, self srcDirName. - self platformsDir: gitRepositoryString, self platformsDirName. - self buildDir: gitRepositoryString, self buildDirName. - self resourcesDir: gitRepositoryString, self resourcesDirName. - self outputDir: gitRepositoryString, self outputDirName. - - - ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuild (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuild - ^ thirdpartyLibs ifNil: [ thirdpartyLibs := OrderedCollection new ].! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildAssert (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildAssert - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildAssertITimerHeartbeat - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildDebug (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildDebug - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildDebugITimerHeartbeat - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildITimerHeartbeat - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildMultiThreaded (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreaded - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreadedAssert - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakMacintoshConfig>>thirdpartyLibsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreadedDebug - ^ self thirdpartyLibs ! Item was changed: ----- Method: SqueakUnixConfig>>cmakeWriteDirectoriesDotCmake: (in category 'cmake') ----- cmakeWriteDirectoriesDotCmake: aMaker |temp o| "We could put these inline, but other components include the directories.cmake file. So, we continue that convention" o := String new writeStream. temp := OrderedCollection new. temp addLast: ((CMakeSet new) variable: 'topDir' quotedValue: (self topDir fullName)); addLast: ((CMakeSet new) variable: 'buildDir' quotedValue: (self buildDir ifNil: ['${topDir}/build'] ifNotNil: [self buildDir fullName])); addLast: ((CMakeSet new) variable: 'thirdpartyDir' quotedValue: '${buildDir}/thirdParty'); + addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self dirPlatforms)); - addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self platformsDir)); addLast: ((CMakeSet new) variable: 'srcDir' quotedValue: (self dirSource pathName)); "where the vm source directory lives" addLast: ((CMakeSet new) variable: 'cogDir' quotedValue: (self cogDir pathName)); "oscogvm/src for historical reasons" addLast: ((CMakeSet new) variable: 'srcPluginsDir' quotedValue: (pluginsDir ifNil: [ '${cogDir}/plugins' ])); "plugin source directory only in oscogvm/src/plugins" addLast: ((CMakeSet new) variable: 'srcVMDir' quotedValue: '${srcDir}/vm'); addLast: ((CMakeSet new) variable: 'platformName' quotedValue: (self platformName)); addLast: ((CMakeSet new) variable: 'targetPlatform' quotedValue: '${platformsDir}/${platformName}'); addLast: ((CMakeSet new) variable: 'crossDir' quotedValue: '${platformsDir}/Cross'); addLast: ((CMakeSet new) variable: 'platformVMDir' quotedValue: '${targetPlatform}/vm}'); addLast: ((CMakeSet new) variable: 'outputDir' quotedValue: (self outputDir fullName)); addLast: ((CMakeSet new) variable: 'externalModulesDir' quotedValue: (self externalModulesDir)). temp do: [:each | o nextPutAll: (each content); cr]. self write: (o contents) toFile: 'directories.cmake'. (enabledebugmessages) ifTrue:[ templates addLast:((CMakeMessage new) message: (self class name), ' setDirectories: aMaker' ) ]. templates addLast: ((CMakeInclude new) file: 'directories.cmake'). ! Item was removed: - ----- Method: SqueakUnixConfig>>thirdpartyLibsBuild (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuild - ^ thirdpartyLibs ifNil: [ thirdpartyLibs := OrderedCollection new ].! Item was changed: ----- Method: SqueakWindowsConfig>>cmakeWriteDirectoriesDotCmake: (in category 'cmake') ----- cmakeWriteDirectoriesDotCmake: aMaker |temp o| "We could put these inline, but other components include the directories.cmake file. So, we continue that convention" o := String new writeStream. temp := OrderedCollection new. temp addLast: ((CMakeSet new) variable: 'topDir' quotedValue: (self topDir fullName)); addLast: ((CMakeSet new) variable: 'buildDir' quotedValue: (self buildDir ifNil: ['${topDir}/build'] ifNotNil: [self buildDir fullName])); addLast: ((CMakeSet new) variable: 'thirdpartyDir' quotedValue: '${buildDir}/thirdParty'); + addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self dirPlatforms)); - addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self platformsDir)); addLast: ((CMakeSet new) variable: 'srcDir' quotedValue: (self dirSource pathName)); "where the vm source directory lives" addLast: ((CMakeSet new) variable: 'cogDir' quotedValue: (self cogDir pathName)); "oscogvm/src for historical reasons" addLast: ((CMakeSet new) variable: 'srcPluginsDir' quotedValue: (pluginsDir ifNil: [ '${cogDir}/plugins' ])); "plugin source directory only in oscogvm/src/plugins" addLast: ((CMakeSet new) variable: 'srcVMDir' quotedValue: '${srcDir}/vm'); addLast: ((CMakeSet new) variable: 'platformName' quotedValue: (self platformName)); addLast: ((CMakeSet new) variable: 'targetPlatform' quotedValue: '${platformsDir}/${platformName}'); addLast: ((CMakeSet new) variable: 'crossDir' quotedValue: '${platformsDir}/Cross'); addLast: ((CMakeSet new) variable: 'platformVMDir' quotedValue: '${targetPlatform}/vm}'); addLast: ((CMakeSet new) variable: 'outputDir' quotedValue: (self outputDir fullName)); addLast: ((CMakeSet new) variable: 'externalModulesDir' quotedValue: (self externalModulesDir)). temp do: [:each | o nextPutAll: (each content); cr]. self write: (o contents) toFile: 'directories.cmake'. (enabledebugmessages) ifTrue:[ templates addLast:((CMakeMessage new) message: (self class name), ' setDirectories: aMaker' ) ]. templates addLast: ((CMakeInclude new) file: 'directories.cmake'). ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuild (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuild - ^ thirdpartyLibs ifNil: [ thirdpartyLibs := OrderedCollection new ].! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildAssert (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildAssert - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildAssertITimerHeartbeat - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildDebug (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildDebug - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildDebugITimerHeartbeat - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildITimerHeartbeat - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildMultiThreaded (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreaded - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreadedAssert - ^ self thirdpartyLibs ! Item was removed: - ----- Method: SqueakWindowsConfig>>thirdpartyLibsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- - thirdpartyLibsBuildMultiThreadedDebug - ^ self thirdpartyLibs ! From eliot.miranda at gmail.com Sat Jun 18 21:16:00 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Jun 18 21:16:03 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: Hi Fabio, On Sat, Jun 18, 2016 at 2:04 AM, Fabio Niephaus wrote: > > > -- > > On Sat, Jun 18, 2016 at 5:28 AM Eliot Miranda > wrote: > >> >> Hi Ben, >> >> On Fri, Jun 17, 2016 at 8:27 AM, Ben Coman wrote: >> >>> >>> On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda >>> wrote: >>> > >>> >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff < >>> timfelgentreff@gmail.com> wrote: >>> >> >>> >>> On 16 June 2016 at 22:07, Eliot Miranda >>> wrote: >>> >>> Hi All, >>> >>> >>> >>> so after fixing "git remote get-url origin" to fail over to "git >>> remote >>> >>> show origin | filter and munge" the culture shock of "git commit -a" >>> (git >>> >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable >>> version >>> >>> info: >>> >>> >>> >>> >>> /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak >>> >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT >>> Compiler: >>> >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM] >>> >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: >>> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >>> >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: >>> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >>> >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu >>> Jun 16 >>> >>> 12:53:33 2016 -0700 $ >>> >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ >>> >>> >>> >>> Which begs the question how do I differentiate this from something >>> built >>> >>> officially via Travis? Arguably the URL is wrong, and should only >>> say >>> >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and perhaps >>> should >>> >>> just include my local hostname and current directory when I make any >>> kind of >>> >>> local modification. So the above would read >>> >>> >>> >>> ... >>> >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 >>> 12:53:33 >>> >>> 2016 -0700 $ >>> >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ >>> >>> >>> >>> Alternatively we could add another field, or modify one of the >>> existing >>> >>> fields to say "I'm official" however one would do that. I don't >>> know how, I >>> >>> just know we need this. I shouldn't be able to pollute the VM pool >>> by >>> >>> putting some VM on some site somewhere that i just happened to build >>> after >>> >>> several sherries and some cannabis brownies that looks to all >>> intents and >>> >>> purposes just like a VM built by our official Travis slaves. Hic. >>> Chillin' >>> >>> I just discovered git-describe, which seems like it could be useful... >>> >>> http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html >>> >>> So if Travis created "r201606161953" as an *official* tag for >>> successful builds like this... >>> https://github.com/travis-ci/travis-ci/issues/1476 >>> >>> then `git describe` would produce "r201606161953" for that build, and >>> after a couple of commits in my personal repo would produce >>> "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish >>> non-official builds. >>> >>> In addition, I can now copy-paste a VM's output revision string >>> to directly do "git checkout r201606161953" >>> instead of "git checkout master@{2016-06-16 19:53} which I read is >>> only viable for 90 days anyway, and has some complexity between >>> whether the given date is author commit date or merge date. >>> >>> But after doing "git checkout r201606161953" in my personal repo >>> git describe >>> ==> r201606161953 is indistinguishable from the Travis build >>> but... >>> git describe --long >>> ==> r201606161953-0-a264e03b is distinguishable. >>> >>> In addition, if I edit some files and rebuild before committing I >>> want to distinguish this from when I build a fresh check out , which >>> can be done with... >>> git describe --long --dirty ==> r201606161953-0-a264e03b-dirty >>> >>> So that last would be used to version personal builds, >>> while Travis would use "git describe" without any flags. >>> ==> r201606161953 >>> >> >> Sounds really good, but >> >> McStalker.oscogvm$ uname -a >> Darwin McStalker 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 >> PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 >> McStalker.oscogvm$ git --version >> git version 1.9.5 (Apple Git-50.3) >> McStalker.oscogvm$ git describe >> fatal: No names found, cannot describe anything. >> McStalker.oscogvm$ git describe --long >> fatal: No names found, cannot describe anything. >> McStalker.oscogvm$ >> >> >> how secure does this need to be? One way to differentiate the official >>> >> VMs is to sign them directly on Travis (which we'll want to do anyway, >>> >> just didn't get to it, yet). >>> >> >>> >> Another option is to just change the URL replacement code to do >>> >> something else when not running on Travis --- like adding your >>> >> hostname and path instead --- but this could be fairly easily messed >>> >> with. >>> >> >>> >> Not sure how much malicious intent we want to prevent. >>> >>> Later on we should have Travis signing its build artefacts, but for >>> now keep it simple. >>> >> >> The Mac builds already sign provided a certificate is installed and an >> environment variable set to point to it. See SIGNING_IDENTITY in >> build.macos*/common/Makefile.app >> > > Cool! Now we only need to decide whose certificate to use. We can encrypt > the cert securely, add it to the repository and install it during a build. > BTW: we are already doing this for the RSqueak VM [1] as well. > > [1] > https://github.com/HPI-SWA-Lab/RSqueak-App/blob/c8e28879a8a9da97fe06cd5cb82e9b9c3058924e/prepare.sh#L42-L46 > I'm happy to provide mine. I'm more than a little unclear as to how to go about adding it to the repository though. Perhaps we could talk early next week and sort this out. Would you be free to Skype on Monday and hold my hand as we try and get this to work? > >>> > None. I don't think there's malicious intent at all. I do think we >>> should differentiate between "personal" and Travis builds. It's more for >>> my own information, so u don't get confused, than to prevent >>> maliciousness. So do the simplest thing that could possibly work TSTTCPW. >>> I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm >>> (path relative to ~eliot). >>> >>> I think `git branch` is as important as `path`. >>> Username could come from `git config user.name | sed 's/ //g' >>> >>> cheers -ben >>> >> >> _,,,^..^,,,_ >> best, Eliot >> > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/dbdab2ed/attachment.htm From commits at source.squeak.org Sat Jun 18 23:28:36 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sat Jun 18 23:28:38 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz Message-ID: Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.126 Author: tty Time: 18 June 2016, 6:34:38.29686 pm UUID: 14b88b21-e134-49d5-9710-83d1f1204b71 Ancestors: CMakeVMMakerSqueak-tty.125 fixed path naming issue in directories.cmake generation involving platforms directory I need to get a repeatable pattern for topdir, srcdir platformsdir vs the dirXYZ name holders. This is a step in that direction. cmake outputs and builds w/o error. =============== Diff against CMakeVMMakerSqueak-tty.125 =============== Item was changed: ----- Method: CMakeVMGeneratorForSqueak>>generateByTemplate (in category 'code generation') ----- generateByTemplate "The bulk of CMake generation happens here. See CPlatformConfigForSqueak>>initialize for CMake output. that occurs prior to this method. (This may change on refactoring) Think Seaside renderOn composition. " | extPlugins intPlugins | self flag: 'tty'. "refactor so that the cascade reflects CMake terminilogy" output := String new writeStream. config templates: OrderedCollection new. config setGlobalOptions: self; cmakePrefixPath; cmakeIncludePath; cmakeLibraryPath; cmakeIncludeModules; cmakeCFlags; cmakeAddDefinitions; cmakeWriteDirectoriesDotCmake: self; cmakeIncludeDirectories: self; "<---" preferredIncludes; "<---why 3 of em?" standardIncludes; "<---" setGlobalOptionsAfterDetermineSystem: self; extraVMSettings: self; "<--catch-all method. os/platform specific" setCoreSources: self; setPlatformSources: self; setCrossSources: self; setExtraSources; cmakeSetSourceFilesProperties; cmakeListAppend:'LINKLIBS' elements: (config externalLibs); cmakeAddExecutableNameOptionSource: self; setExecutableOutputPath; addVMPlugins: self. config templates do: [:each | self puts: each content]. config templates: OrderedCollection new. extPlugins := self generatePluginConfigs: config internalPlugins internal: true. intPlugins := self generatePluginConfigs: config externalPlugins internal: false. self flag:'tty: pharo code would download and install libraries. I think detection belongs in CMake and user should set up their own system for squeak. '. " self processThirdpartyLibraries. " self processPlugins: intPlugins, extPlugins. self config templates addLast:((CMakeCommand new) command:'target_link_libraries' params:(self moduleName , ' ${LINKLIBS}')). " self cmd: 'target_link_libraries' params: self moduleName , ' ${LINKLIBS}'." config postBuildActions: self.. config templates do: [:each | self puts: each content]. self saveFile. self generateBuildScript! Item was added: + ----- Method: CPlatformConfigForSqueak>>platformsDir (in category 'cmake directory') ----- + platformsDir + ^ (self topDir directoryNamed: (self dirPlatforms) ) + ! Item was changed: ----- Method: SqueakUnixConfig>>cmakeWriteDirectoriesDotCmake: (in category 'cmake') ----- cmakeWriteDirectoriesDotCmake: aMaker |temp o| "We could put these inline, but other components include the directories.cmake file. So, we continue that convention" o := String new writeStream. temp := OrderedCollection new. temp addLast: ((CMakeSet new) variable: 'topDir' quotedValue: (self topDir fullName)); addLast: ((CMakeSet new) variable: 'buildDir' quotedValue: (self buildDir ifNil: ['${topDir}/build'] ifNotNil: [self buildDir fullName])); addLast: ((CMakeSet new) variable: 'thirdpartyDir' quotedValue: '${buildDir}/thirdParty'); + addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self platformsDir pathName)); - addLast: ((CMakeSet new) variable: 'platformsDir' quotedValue: (self dirPlatforms)); addLast: ((CMakeSet new) variable: 'srcDir' quotedValue: (self dirSource pathName)); "where the vm source directory lives" addLast: ((CMakeSet new) variable: 'cogDir' quotedValue: (self cogDir pathName)); "oscogvm/src for historical reasons" + addLast: ((CMakeSet new) variable: 'srcPluginsDir' quotedValue: '${cogDir}/plugins' ); "plugin source directory only in oscogvm/src/plugins" - addLast: ((CMakeSet new) variable: 'srcPluginsDir' quotedValue: (pluginsDir ifNil: [ '${cogDir}/plugins' ])); "plugin source directory only in oscogvm/src/plugins" addLast: ((CMakeSet new) variable: 'srcVMDir' quotedValue: '${srcDir}/vm'); addLast: ((CMakeSet new) variable: 'platformName' quotedValue: (self platformName)); addLast: ((CMakeSet new) variable: 'targetPlatform' quotedValue: '${platformsDir}/${platformName}'); addLast: ((CMakeSet new) variable: 'crossDir' quotedValue: '${platformsDir}/Cross'); addLast: ((CMakeSet new) variable: 'platformVMDir' quotedValue: '${targetPlatform}/vm}'); addLast: ((CMakeSet new) variable: 'outputDir' quotedValue: (self outputDir fullName)); addLast: ((CMakeSet new) variable: 'externalModulesDir' quotedValue: (self externalModulesDir)). temp do: [:each | o nextPutAll: (each content); cr]. self write: (o contents) toFile: 'directories.cmake'. (enabledebugmessages) ifTrue:[ templates addLast:((CMakeMessage new) message: (self class name), ' setDirectories: aMaker' ) ]. templates addLast: ((CMakeInclude new) file: 'directories.cmake'). ! From eliot.miranda at gmail.com Sat Jun 18 23:58:50 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Jun 18 23:58:53 2016 Subject: [Vm-dev] git mavens, shortcut please? Message-ID: Hi All, I find myself in this situation a lot: Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: platforms/Cross/plugins/IA32ABI/ia32abi.h modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c modified: platforms/Cross/plugins/IA32ABI/xabicc.c Untracked files: (use "git add ..." to include in what will be committed) platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp What's the one liner to add the modified files and ignore the untracked files? What's the one-liner to add and commit the modified files and ignore the untracked files? [hate the word "add" being used to mean "stage". This thing was written by a sadist]. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/1b47fc45/attachment-0001.htm From eliot.miranda at gmail.com Sun Jun 19 00:01:23 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun Jun 19 00:01:26 2016 Subject: [Vm-dev] Should I push or request a pull? Message-ID: Hi All, fixing callbacks on x64 and so too lazy/focussed elsewhere to check whether I should be pushing after each commit. What is the right process for uploading changes to OpenSmalltalk/vm? _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/bacdb104/attachment.htm From commits at source.squeak.org Sun Jun 19 00:21:52 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Jun 19 00:21:52 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.127.mcz Message-ID: Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.127.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.127 Author: tty Time: 18 June 2016, 7:27:55.972346 pm UUID: c8418b7c-0caf-4ddd-979c-4e9d1776947a Ancestors: CMakeVMMakerSqueak-tty.126 buildDir fix =============== Diff against CMakeVMMakerSqueak-tty.126 =============== Item was changed: ----- Method: CMakeVMGeneratorForSqueak>>generateByTemplate (in category 'code generation') ----- generateByTemplate "The bulk of CMake generation happens here. See CPlatformConfigForSqueak>>initialize for CMake output. that occurs prior to this method. (This may change on refactoring) Think Seaside renderOn composition. " | extPlugins intPlugins | self flag: 'tty'. "refactor so that the cascade reflects CMake terminilogy" output := String new writeStream. config templates: OrderedCollection new. config setGlobalOptions: self; cmakePrefixPath; cmakeIncludePath; cmakeLibraryPath; cmakeIncludeModules; cmakeCFlags; cmakeAddDefinitions; cmakeWriteDirectoriesDotCmake: self; cmakeIncludeDirectories: self; "<---" preferredIncludes; "<---why 3 of em?" standardIncludes; "<---" setGlobalOptionsAfterDetermineSystem: self; extraVMSettings: self; "<--catch-all method. os/platform specific" setCoreSources: self; setPlatformSources: self; setCrossSources: self; setExtraSources; cmakeSetSourceFilesProperties; cmakeListAppend:'LINKLIBS' elements: (config externalLibs); cmakeAddExecutableNameOptionSource: self; setExecutableOutputPath; addVMPlugins: self. config templates do: [:each | self puts: each content]. config templates: OrderedCollection new. extPlugins := self generatePluginConfigs: config internalPlugins internal: true. intPlugins := self generatePluginConfigs: config externalPlugins internal: false. self flag:'tty: pharo code would download and install libraries. I think detection belongs in CMake and user should set up their own system for squeak. '. " self processThirdpartyLibraries. " self processPlugins: intPlugins, extPlugins. self config templates addLast:((CMakeCommand new) command:'target_link_libraries' params:(self moduleName , ' ${LINKLIBS}')). " self cmd: 'target_link_libraries' params: self moduleName , ' ${LINKLIBS}'." config postBuildActions: self.. config templates do: [:each | self puts: each content]. self saveFile. self generateBuildScript! Item was changed: Object subclass: #CPlatformConfigForSqueak + instanceVariableNames: 'buildType cogDir generateBuild generateBuildAssert generateBuildAssertITimerHeartbeat generateBuildDebug generateBuildDebugITimerHeartbeat generateBuildDebugMultiThreaded generateBuildIHeartbeatTimer generateBuildMultiThreaded generateBuildMultiThreadedAssert generateBuildMultiThreadedDebug templates enabledebugmessages platformSources vmplugins outputDir buildDir topDir' - instanceVariableNames: 'buildType cogDir generateBuild generateBuildAssert generateBuildAssertITimerHeartbeat generateBuildDebug generateBuildDebugITimerHeartbeat generateBuildDebugMultiThreaded generateBuildIHeartbeatTimer generateBuildMultiThreaded generateBuildMultiThreadedAssert generateBuildMultiThreadedDebug templates enabledebugmessages platformSources vmplugins' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak'! CPlatformConfigForSqueak class instanceVariableNames: 'isAbstractBaseClass'! !CPlatformConfigForSqueak commentStamp: 'tty 12/8/2014 11:28' prior: 0! A CPlatformConfigForSqueak acts as a compatability layer for Squeak and an Abstract Base Class for extended functionality required for the Squeak CMakeVMMaker use-case. I make (very) heavy use of a specific design pattern for configuring myself and remaining compatible with pharo's CMakeVMMaker. The entry point for that pattern is my method 'configureForBuildType: aSymbol' . Each method send in there detects my buildType and routes the send to the approriate method for that buildType. Subclasses of me 'must' configure themselves for each build type per that pattern. However this can be very easy by just returning the base configuration. Tests are written to verify that this support infrastructure is in place. I have two important methods. excludeFromBuild and isAbstractBaseClass. excludeFromBuild is used to exclude a configuration from being built by a Builder. is used to exclude a configuration from Testing. isAbstractBaseClass is used by configurations that exclude themselves from being built by a Builder BUT need to be included in Testing. excludeFromBuild | isAbstractBaseClass | should build | should test T T NO YES T F NO NO F T YES YES F F YES YES The use-case is as follows. An abstract base class contains a lot of functionality that must be implemented and tested for the system to work, but it is not meant to be compiled. concrete classes of that AbstractBase class can exclude themselves from being built by builders and by doing so are not tested. However, once a concrete configuration is enabled to be built, it must pass all tests. Linux32x86Config is an example of an AbstractBase class that must pass all testing, but is not buildable. Its subclass Linux32x86SqueakCogV3Config needs testing, but a developer can toggle 'exclude from build' to hide it from Builders or make it available to them. Tests make the decision on what configurations to test. Here are some examples. (o excludeFromBuild not) & (configuration isAbstractBaseClass not) this is a concrete [Lang][VM][MemoryManager][etc] configuration that will be built. No platform classes considered (o excludeFromBuild) & (configuration isAbstractBaseClass not) This is a concrete [Lang][VM][MemoryManager][etc] configuration that will be NOT built. (o excludeFromBuild not) | (configuration isAbstractBaseClass) concrete implementation may depend on its [OS][VMWordSize][Processor] AbstractBaseClass for platform level methods. example: Linux32x86Config ccBuild has the '-m32' compiler flag that is common to all builds on that platform (o excludeFromBuild not) & (configuration isAbstractBaseClass) Not allowed. [OS][VMWordSize][Processor] AbstractBaseClasses should not be built. This is a useful test in its own right. (o excludeFromBuild) & (configuration isAbstractBaseClass) These are the AbstractBaseClasses. An AbstractBaseClass should always be excluded from a build HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp tty.! CPlatformConfigForSqueak class instanceVariableNames: 'isAbstractBaseClass'! Item was changed: ----- Method: CPlatformConfigForSqueak>>buildDir (in category 'cmake directory') ----- buildDir + ^ buildDir ifNil: [ buildDir := ( self topDir / self buildDirName) assureExistence]. ! - ^ buildDir ifNil: [ buildDir := ( self topDir / self buildDirName) assureExistence].! Item was changed: ----- Method: CPlatformConfigForSqueak>>outputDir (in category 'cmake directory') ----- outputDir "the directory where built binaries will be stored" + ^ outputDir ifNil: [ outputDir := (self topDir / self dirOutput / self dirBuildPlatform / self dirBuildLanguageVMMM / (buildType asString)) ] - ^ outputDir ifNil: [ outputDir := (self topDir / self dirOutput / self dirBuildPlatform / self dirBuildLanguageVMMM / (buildType asString)) ] ! Item was changed: ----- Method: CPlatformConfigForSqueak>>topDir (in category 'cmake directory') ----- topDir " topDir=oscogvm dirSource=[nsspur64src | nsspursrc |nsspurstack64src |nsspurstacksrc |spur64src |spursistasrc |spursrc | spurstack64src |spurstacksrc | src |stacksr] Configurations customize this srcDir=oscogvm/dirSource cogDir=oscogvm/src (needed by CMake for access to plugins source in oscogvm/src/plugins) " + ^ topDir ifNil: [ topDir := FileDirectory default directoryNamed: self oscogvm ] - ^ topDir ifNil: [ topDir := FileDirectory default directoryNamed: self oscogvm ] ! Item was changed: ----- Method: CPlatformConfigForSqueak>>write:toFile: (in category 'squeak compatability') ----- write: aContents toFile: aFileName "write a file to current output directory (buildDir). use line end convention appropriate for config platform" | bldDir | bldDir := self buildDir. bldDir isString ifTrue: [ bldDir := FileDirectory directoryEntryFor: bldDir ]. bldDir assureExistence. bldDir forceNewFileNamed: aFileName do: [:s | s nextPutAll: (self fixLineEndsOf: aContents)] ! From vonbecmann at gmail.com Sun Jun 19 00:24:30 2016 From: vonbecmann at gmail.com (Bernardo Ezequiel Contreras) Date: Sun Jun 19 00:24:32 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: Message-ID: Eliot, regarding how to ignore the untracked files, you could ignore those files by adding them to .gitignore, and they won't bother you again. here's the documentation https://git-scm.com/docs/gitignore On Sat, Jun 18, 2016 at 8:58 PM, Eliot Miranda wrote: > > Hi All, > > I find myself in this situation a lot: > > Changes not staged for commit: > (use "git add ..." to update what will be committed) > (use "git checkout -- ..." to discard changes in working directory) > > modified: platforms/Cross/plugins/IA32ABI/ia32abi.h > modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c > modified: platforms/Cross/plugins/IA32ABI/xabicc.c > > Untracked files: > (use "git add ..." to include in what will be committed) > > platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp > > What's the one liner to add the modified files and ignore the untracked > files? > What's the one-liner to add and commit the modified files and ignore the > untracked files? > > [hate the word "add" being used to mean "stage". This thing was written > by a sadist]. > _,,,^..^,,,_ > best, Eliot > > -- Bernardo E.C. Sent from a cheap desktop computer in South America. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160618/68180dd6/attachment.htm From tim at rowledge.org Sun Jun 19 00:41:21 2016 From: tim at rowledge.org (tim Rowledge) Date: Sun Jun 19 00:41:07 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: Message-ID: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works and need something in style of ?see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m?boots!' and so on. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ...now touch these wires to your tongue! From lists at fniephaus.com Sun Jun 19 01:13:33 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Sun Jun 19 01:13:47 2016 Subject: [squeak-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: <019048C7-80D5-4703-BC97-68A4A858FE4D@gmail.com> Message-ID: Yes, I have some time on Monday. What time would you prefer? On Sat, 18 Jun 2016 at 23:16, Eliot Miranda wrote: > > Hi Fabio, > > On Sat, Jun 18, 2016 at 2:04 AM, Fabio Niephaus > wrote: > >> >> >> -- >> >> On Sat, Jun 18, 2016 at 5:28 AM Eliot Miranda >> wrote: >> >>> >>> Hi Ben, >>> >>> On Fri, Jun 17, 2016 at 8:27 AM, Ben Coman wrote: >>> >>>> >>>> On Fri, Jun 17, 2016 at 3:40 PM, Eliot Miranda >>>> wrote: >>>> > >>>> >> On Jun 17, 2016, at 12:22 AM, Tim Felgentreff < >>>> timfelgentreff@gmail.com> wrote: >>>> >> >>>> >>> On 16 June 2016 at 22:07, Eliot Miranda >>>> wrote: >>>> >>> Hi All, >>>> >>> >>>> >>> so after fixing "git remote get-url origin" to fail over to >>>> "git remote >>>> >>> show origin | filter and munge" the culture shock of "git commit >>>> -a" (git >>>> >>> commit does nothing ?!?!?) I have a VM that outputs a reasonable >>>> version >>>> >>> info: >>>> >>> >>>> >>> >>>> /Users/eliot/oscogvm/build.macos32x86/squeak.cog.spur/CocoaFast.app/Contents/MacOS/Squeak >>>> >>> 5.0 5.0.201606161953 Mac OS X built on Jun 16 2016 12:56:52 PDT >>>> Compiler: >>>> >>> 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur >>>> VM] >>>> >>> CoInterpreter VMMaker.oscog-eem.1886 uuid: >>>> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >>>> >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1886 uuid: >>>> >>> d413db9f-37cc-4c5d-bfc6-87b11203ee96 Jun 16 2016 >>>> >>> VM: r201606161953 http://github.com/OpenSmalltalk/vm $ Date: Thu >>>> Jun 16 >>>> >>> 12:53:33 2016 -0700 $ >>>> >>> Plugins: r201606161953 http://github.com/OpenSmalltalk/vm $ >>>> >>> >>>> >>> Which begs the question how do I differentiate this from something >>>> built >>>> >>> officially via Travis? Arguably the URL is wrong, and should only >>>> say >>>> >>> "http://github.com/OpenSmalltalk/vm" for travis builds, and >>>> perhaps should >>>> >>> just include my local hostname and current directory when I make >>>> any kind of >>>> >>> local modification. So the above would read >>>> >>> >>>> >>> ... >>>> >>> VM: r201606161953 McStalker:?users/eliot/oscogvm $ Date: Thu Jun 16 >>>> 12:53:33 >>>> >>> 2016 -0700 $ >>>> >>> Plugins: r201606161953 McStalker:?users/eliot/oscogvm $ >>>> >>> >>>> >>> Alternatively we could add another field, or modify one of the >>>> existing >>>> >>> fields to say "I'm official" however one would do that. I don't >>>> know how, I >>>> >>> just know we need this. I shouldn't be able to pollute the VM pool >>>> by >>>> >>> putting some VM on some site somewhere that i just happened to >>>> build after >>>> >>> several sherries and some cannabis brownies that looks to all >>>> intents and >>>> >>> purposes just like a VM built by our official Travis slaves. Hic. >>>> Chillin' >>>> >>>> I just discovered git-describe, which seems like it could be useful... >>>> >>>> http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html >>>> >>>> So if Travis created "r201606161953" as an *official* tag for >>>> successful builds like this... >>>> https://github.com/travis-ci/travis-ci/issues/1476 >>>> >>>> then `git describe` would produce "r201606161953" for that build, and >>>> after a couple of commits in my personal repo would produce >>>> "r201606161953-2-g169d02a". The "-2-g169d02a" would distinguish >>>> non-official builds. >>>> >>>> In addition, I can now copy-paste a VM's output revision string >>>> to directly do "git checkout r201606161953" >>>> instead of "git checkout master@{2016-06-16 19:53} which I read is >>>> only viable for 90 days anyway, and has some complexity between >>>> whether the given date is author commit date or merge date. >>>> >>>> But after doing "git checkout r201606161953" in my personal repo >>>> git describe >>>> ==> r201606161953 is indistinguishable from the Travis build >>>> but... >>>> git describe --long >>>> ==> r201606161953-0-a264e03b is distinguishable. >>>> >>>> In addition, if I edit some files and rebuild before committing I >>>> want to distinguish this from when I build a fresh check out , which >>>> can be done with... >>>> git describe --long --dirty ==> r201606161953-0-a264e03b-dirty >>>> >>>> So that last would be used to version personal builds, >>>> while Travis would use "git describe" without any flags. >>>> ==> r201606161953 >>>> >>> >>> Sounds really good, but >>> >>> McStalker.oscogvm$ uname -a >>> Darwin McStalker 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 >>> 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 >>> McStalker.oscogvm$ git --version >>> git version 1.9.5 (Apple Git-50.3) >>> McStalker.oscogvm$ git describe >>> fatal: No names found, cannot describe anything. >>> McStalker.oscogvm$ git describe --long >>> fatal: No names found, cannot describe anything. >>> McStalker.oscogvm$ >>> >>> >> how secure does this need to be? One way to differentiate the official >>>> >> VMs is to sign them directly on Travis (which we'll want to do >>>> anyway, >>>> >> just didn't get to it, yet). >>>> >> >>>> >> Another option is to just change the URL replacement code to do >>>> >> something else when not running on Travis --- like adding your >>>> >> hostname and path instead --- but this could be fairly easily messed >>>> >> with. >>>> >> >>>> >> Not sure how much malicious intent we want to prevent. >>>> >>>> Later on we should have Travis signing its build artefacts, but for >>>> now keep it simple. >>>> >>> >>> The Mac builds already sign provided a certificate is installed and an >>> environment variable set to point to it. See SIGNING_IDENTITY in >>> build.macos*/common/Makefile.app >>> >> >> Cool! Now we only need to decide whose certificate to use. We can encrypt >> the cert securely, add it to the repository and install it during a build. >> BTW: we are already doing this for the RSqueak VM [1] as well. >> >> [1] >> https://github.com/HPI-SWA-Lab/RSqueak-App/blob/c8e28879a8a9da97fe06cd5cb82e9b9c3058924e/prepare.sh#L42-L46 >> > > I'm happy to provide mine. I'm more than a little unclear as to how to go > about adding it to the repository though. Perhaps we could talk early next > week and sort this out. Would you be free to Skype on Monday and hold my > hand as we try and get this to work? > > > >>>> > None. I don't think there's malicious intent at all. I do think we >>>> should differentiate between "personal" and Travis builds. It's more for >>>> my own information, so u don't get confused, than to prevent >>>> maliciousness. So do the simplest thing that could possibly work TSTTCPW. >>>> I like username,host name,path as in an scp, eg eliot@McStalker:oscogvm >>>> (path relative to ~eliot). >>>> >>>> I think `git branch` is as important as `path`. >>>> Username could come from `git config user.name | sed 's/ //g' >>>> >>>> cheers -ben >>>> >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160619/2552cf52/attachment-0001.htm From btc at openinworld.com Sun Jun 19 01:57:40 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 19 01:58:03 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: On Sun, Jun 19, 2016 at 8:01 AM, Eliot Miranda wrote: > > Hi All, > > fixing callbacks on x64 and so too lazy/focussed elsewhere to check whether I should be pushing after each commit. What is the right process for uploading changes to OpenSmalltalk/vm? > _,,,^..^,,,_ > best, Eliot > In any case, you need to push the changes from your local repo up to the github repo. If you cloned from the official-repo (as you probably are), and... A. you are working in the Cog branch, then all you need to do is push. B. you are working in a MyFeature branch, then after pushing to github, you would also make a github pull request from MyFeature branch to the Cog branch. Alternatively, you can merge MyFeature branch into your local Cog branch (rather than rely on github doing in a pull request) and continue with A. If (like me) the local repo was cloned from a personal-fork of the project (on github), and... C. I am are working in the Cog branch, then I do B. D. I am working in a MyFeature branch, I do B. After any push to github, I find it useful to verify what what github thinks has happened by reviewing https://github.com/OpenSmalltalk/vm/network. There may be a few minute delay as the graph is queued to be rebuilt. cheers -ben From pbpublist at gmail.com Sun Jun 19 05:16:16 2016 From: pbpublist at gmail.com (Phil (list)) Date: Sun Jun 19 05:16:21 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: <1466313376.19725.85.camel@gmail.com> On Sat, 2016-06-18 at 17:01 -0700, Eliot Miranda wrote: > ? > Hi All, > > ? ? fixing callbacks on x64 and so too lazy/focussed elsewhere to > check whether I should be pushing after each commit.? What is the > right process for uploading changes to OpenSmalltalk/vm? > _,,,^..^,,,_ > best,?Eliot Push when you want the world to see your changes. ?You don't need to be 1:1 on commits to pushes (i.e. you can batch up multiple commits and then push them all at once if that's your preference, the public repo will still record each separate commit) ?It's also handy if you're going to be disconnected for a while so you can commit locally as often as needed and then push them when you get back online. From btc at openinworld.com Sun Jun 19 05:22:50 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 19 05:23:13 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: Message-ID: On Sun, Jun 19, 2016 at 7:58 AM, Eliot Miranda wrote: > > Hi All, > > I find myself in this situation a lot: > > Changes not staged for commit: > (use "git add ..." to update what will be committed) > (use "git checkout -- ..." to discard changes in working directory) > > modified: platforms/Cross/plugins/IA32ABI/ia32abi.h > modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c > modified: platforms/Cross/plugins/IA32ABI/xabicc.c > > Untracked files: > (use "git add ..." to include in what will be committed) > > platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp > > What's the one liner to add the modified files and ignore the untracked files? git stage -u (i.e. git stage --update) > What's the one-liner to add and commit the modified files and ignore the untracked files? git commit -a > > [hate the word "add" being used to mean "stage". This thing was written by a sadist]. > _,,,^..^,,,_ > best, Eliot > From pbpublist at gmail.com Sun Jun 19 05:37:26 2016 From: pbpublist at gmail.com (Phil (list)) Date: Sun Jun 19 05:37:31 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: <1466314646.19725.92.camel@gmail.com> On Sat, 2016-06-18 at 17:41 -0700, tim Rowledge wrote: > ? > Actually, calling all git mavens - please, please, point the rest of > us to some documentation that might possibly be understood by humans. > Some of us have no idea at all how this works and need something in > style of ?see spot download some code. See spot build it. Run it, > spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now > save the code. Now pour the custard in m?boots!' and so on. > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > ...now touch these wires to your tongue! > > There's a *lot* of content out there for migrating from svn (and other systems) to git. ?This looks like a good 'I know how to do it in svn, now how do I do it in git?' basics page:?http://git.or.cz/course/svn.ht ml?and here's a version that might look nicer in hard copy form:?https: //www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/ From maxleske at gmail.com Sun Jun 19 09:03:03 2016 From: maxleske at gmail.com (Max Leske) Date: Sun Jun 19 09:03:07 2016 Subject: [Vm-dev] System and user processes Message-ID: Hi, In Pharo and Squeak we have no separation between processes that belong to the IDE, tools etc. and processes that are spawned as part of an application. I?d like to know your opinion on the following (rough) idea: 1. We introduce two subclasses of Process: SystemProcess and UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We introduce #newSystemProcess and #newUserProcess 4. We deprecate #newProcess and delegate to #newUserProcess (thereby modifying all users of #forkXXX to yield instances of UserProcess) Of the following I?m less sure: 5. We introduce #forkSystemProcess et. al I?ve tried this out in Pharo 6 and there seem to be no problems with the VM. The benefit would be improved separation between system and user space. It would allow us to implement stuff for processes in general (e.g. for the debugger) which we do not want to affect system processes like the UI process or the background process. One concrete example: the process browser could hide all system processes and make them visible on demand (that would greatly improve the view because you can now better find your own processes). I?m looking forward to your comments. Cheers, Max From tudor at tudorgirba.com Sun Jun 19 09:13:12 2016 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun Jun 19 09:13:18 2016 Subject: [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: <4C5040CF-6250-4D8C-92F1-81F7FFA386A0@gmail.com> Message-ID: <22C9706E-35BA-4F74-8DB1-E351146CDA8E@tudorgirba.com> Hi, > On Jun 16, 2016, at 7:31 PM, Cl?ment Bera wrote: > > > > On Thu, Jun 16, 2016 at 6:28 PM, Eliot Miranda wrote: > > Hi Cl?ment, > > On Jun 16, 2016, at 1:21 AM, Cl?ment Bera wrote: > >> Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ? > > Definitely only overflowing arguments. > >> >> I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ? > > My analysis is that handling only overflow arguments provides more graceful degradation, why? > > When using this overflow scheme both the send, because of the creation of the argument vector, and argument access in the method, because arguments are indirectly accessed through the array, are slower. If all arguments are passed in the array then there is a big step down in performance from 14 to 15 arguments. But if only arguments greater than the 14th are passed in the array, fewer arguments have to be consed into the array, and arguments 1 through 14 can still be accessed directly. > > But the killer is disambiguating 1 argument methods. If all arguments are passed by the array then a 1 argument method may either by a 1 argument method or a greater than 14 argument method, and that must be disambiguated, slowing down or increasing the size of the very common case of a 1 argument method. If only arguments 25 and above are sent we only have to disambiguate the uncommon case of a 15 or more argument method. > > That second point convinced me. +1 Doru > > > _,,,^..^,,,_ (phone) > >> >> On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier wrote: >> >> For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments. >> This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru. >> I don't know if it's the case for other 3rd party code, but it would be worth inquiring... >> >> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html >> http://bugs.squeak.org/view.php?id=2918 >> >> The (Old) Compiler code is at >> >> http://www.squeaksource.com/Smallapack.html >> Smallapack-Compiler.trunk-nice.6.mcz >> >> >> >> 2016-06-16 8:10 GMT+02:00 Cl?ment Bera : >> >> Hi everyone. >> >> It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks. >> >> I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change. >> >> The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments. >> >> The normal calling convention in the Smalltalk bytecode is as follows: >> >> push receiver >> push arg 1 >> push arg 2 >> .... >> push arg N >> send selector >> >> N is limited to 15 arguments due compiled method header & bytecode encoding. >> >> In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors. >> >> The convention will look like that: >> >> push receiver >> push arg 1 >> push arg 2 >> .... >> push arg N >> popIntoArray N-15 values >> send selector >> >> The compilation of a method with more than 15 arguments is then changed: >> - As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg. >> - the compiled method header is still marked with 15 arguments >> >> In addition one needs to change CompiledMethod to: >> - allow larger frames (instead of 56 we could allow 128 or 256) >> - have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon. >> >> And to change the fall-back of a couple primitives, such as: >> - Object>>perform: withArgs: >> - Object>>perform: withArgs:inSupedClass: >> - BlockClosure>>valueWithArgs: >> >> This design would allow methods to up to 141 arguments. >> >> What do you guys think ? >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar." From bert at freudenbergs.de Sun Jun 19 14:44:01 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Sun Jun 19 14:44:03 2016 Subject: get-url fails on Mac OS X [Was Re: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC] In-Reply-To: References: Message-ID: On Thu, Jun 16, 2016 at 9:46 PM, Eliot Miranda wrote: > > Hi Perlers, > > in .git_filters/RevDateURL.smudge the URL is obtained with "git remote > get-url origin", but that doesn't work on Mac OS X git version 1.9.5 (Apple > Git-50.3). Instead one has to use git remote show origin. > > I'm modifying .git_filters/RevDateURL.smudge to read > > $url=`git remote get-url origin 2>/dev/null`; > if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: > //' 2>/dev/null` } > $url =~ s/\s+$//m; > This should work everywhere: git config --get remote.origin.url I just committed that. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160619/09eb151a/attachment.htm From jakob.reschke at student.hpi.de Sun Jun 19 14:53:08 2016 From: jakob.reschke at student.hpi.de (Jakob Reschke) Date: Sun Jun 19 14:53:31 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: I think Ben meant to post `git add -u` (there is no "stage" command, but you can create aliases). Long post follows, tl;dr/toc: a book recommendation; do not rely on svn-to-git tables forever; a possible explanation for why add is called add; a use case for staging (for those who might see it as an unnecessary complication); remember the "stash" command; you might like "bisect" for bug-hunting. What documentation have you already read except for the manpages? I liked the book mentioned on the git Homepage: https://git-scm.com/book/en/v2 But I don't remember how good I knew git already when I read parts of it. I found the Git Internals chapter to be particularly enlightening, but I understand if you do not wish to deal with the internals just to get going with it. :-) Although SVN to Git migration guides and "translation" tables might be what you look for in the beginning, you should definitely adjust to Git's vocabulary for a happier life (at least happier on condition that you work with Git). Regarding the "add" for "stage": imagine that you do not track files with git, but content (that's also how its database is built like). So you "add" changes to Git's knowledge of your content. The really nice part about the staging, by the way, is that it allows you to commit only part of your changes, for smaller and more focused commits even after you "went into the flow", fixed a hundred bugs, and added ten features along the way, including that nifty utility function that everyone ought to have on their branches (and want to cherry-pick)... You can even can add individual lines from changed files instead of the whole file (git add -p/--patch). I use it all the time in my (non-Smalltalk) projects, but SVN cannot do that. I figure it does not help so much with Smalltalk code, but could be handy for all that C. Also, if you ever happen to be working on something you do not want to commit yet (even though you commit locally), but you have to switch branches or merge something anyway (which svn update forces on you all the time), you should remember the "git stash" command. It basically puts aside local changes to tracked files for later retrieval. I would say this is a must-know because Git won't in general let you perform destructive operations on files with uncommitted changes (merge and checkout are probably the most common ones), so you don't accidentally lose any changes. Git is really quite good at not letting you lose something, but it takes time to get used to it and appreciate that it only wants to help. And you still have to know the commands to get stuff back after you made a wrong decision. ;-) But remember that you won't get something back you have never "added" to Git. For the bug spotting part in tim's story, you might find the bisect command interesting, when you have some time to read up about it. If you are really proficient with that, you can make it automatically search the history for a commit that introduced a bug you just discovered. But I guess we would need some tooling to exploit that to its fullest. Well, I think that's enough text for today, sorry. ;-) 2016-06-19 7:37 GMT+02:00 Phil (list) : > > On Sat, 2016-06-18 at 17:41 -0700, tim Rowledge wrote: >> >> Actually, calling all git mavens - please, please, point the rest of >> us to some documentation that might possibly be understood by humans. >> Some of us have no idea at all how this works and need something in >> style of ?see spot download some code. See spot build it. Run it, >> spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now >> save the code. Now pour the custard in m?boots!' and so on. >> >> tim >> -- >> tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim >> ...now touch these wires to your tongue! >> >> > > There's a *lot* of content out there for migrating from svn (and other > systems) to git. This looks like a good 'I know how to do it in svn, > now how do I do it in git?' basics page: http://git.or.cz/course/svn.ht > ml and here's a version that might look nicer in hard copy form: https: > //www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/ From btc at openinworld.com Sun Jun 19 14:57:34 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 19 14:57:58 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: On Sun, Jun 19, 2016 at 10:53 PM, Jakob Reschke wrote: > > I think Ben meant to post `git add -u` (there is no "stage" command, > but you can create aliases). oh but there is ;) see `man git-stage` ? I was surprised to find it. btw, git version 2.1.4 cheers -ben From jakob.reschke at student.hpi.de Sun Jun 19 15:15:59 2016 From: jakob.reschke at student.hpi.de (Jakob Reschke) Date: Sun Jun 19 15:16:21 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: 2016-06-19 16:57 GMT+02:00 Ben Coman : > > On Sun, Jun 19, 2016 at 10:53 PM, Jakob Reschke > wrote: >> >> I think Ben meant to post `git add -u` (there is no "stage" command, >> but you can create aliases). > > oh but there is ;) > see `man git-stage` ? > I was surprised to find it. > btw, git version 2.1.4 > > cheers -ben Oops, you're right! I had never seen that. Although it already exists since 1.6.1... I stand corrected -- suspected a typo before. From pdebruic at gmail.com Sun Jun 19 16:04:28 2016 From: pdebruic at gmail.com (Paul DeBruicker) Date: Sun Jun 19 16:44:18 2016 Subject: [Vm-dev] Re: git mavens, shortcut please? In-Reply-To: References: Message-ID: <1466352268684-4901809.post@n4.nabble.com> git commit -a will add all the modified files and open an editor where you can write the commit message. Once the editor exits it git will complete the commit. git commit -am"Here is my commit message" will add all modified files to the commit, make the commit message 'Here is my commit message' and then commit. To configure a specific editor (e.g. emacs, vim, textmate) that can be used when writing lengthier commit messages by one time per computer running git config --global core.editor "emacsclient" Eliot Miranda-2 wrote > Hi All, > > I find myself in this situation a lot: > > Changes not staged for commit: > (use "git add > > ..." to update what will be committed) > (use "git checkout -- > > ..." to discard changes in working directory) > > modified: platforms/Cross/plugins/IA32ABI/ia32abi.h > modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c > modified: platforms/Cross/plugins/IA32ABI/xabicc.c > > Untracked files: > (use "git add > > ..." to include in what will be committed) > > platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp > > What's the one liner to add the modified files and ignore the untracked > files? > What's the one-liner to add and commit the modified files and ignore the > untracked files? > > [hate the word "add" being used to mean "stage". This thing was written > by > a sadist]. > _,,,^..^,,,_ > best, Eliot -- View this message in context: http://forum.world.st/git-mavens-shortcut-please-tp4901724p4901809.html Sent from the Squeak VM mailing list archive at Nabble.com. From btc at openinworld.com Sun Jun 19 17:00:46 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 19 17:01:08 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge wrote: > > Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works I found these Atlassian tutorials really nice (and often refer to them)... * https://www.atlassian.com/git/tutorials Github Help "Fork a repo" provides a scratch repo for you to practice on without fear. * https://help.github.com/ git - the simple guide (I only just bumped into this, looks good) * http://rogerdudler.github.io/git-guide/ > and need something in style of ?see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m?boots!' and so on. Okay Spot. Here is a proposed recipe. This is for those having having write access to the official repository and cloned that to work in. I'll follow up with an adaption for forked repos tomorrow. 1. Go to https://github.com/OpenSmalltalk/vm 2. Click the green button. (If you've already set up your SSH keys, click "Use SSH".) then copy the url to the clipboard. 3. Clone to your local machine $ git clone #paste url from the clipboard here $ cd vm $ git remove -v origin git@github.com:OpenSmalltalk/vm.git (fetch) origin git@github.com:OpenSmalltalk/vm.git (push) or... origin https://github.com/OpenSmalltalk/vm.git (fetch) origin https://github.com/OpenSmalltalk/vm.git (push) ...depending on ssh or https clone respectively 4. Create a branch to work on... $ git fetch #updates all branches to latest $ git checkout -b SomeBug Cog 5. Edit, compile, test cycle. Commit often along the way. * make required changes $ git stage -u $ git diff ; git diff HEAD $ git commit -m "SomeBug - part way there" Repeat as necessary 6. Ready to submit. Clean up *local* history (since we committed quite often) $ git rebase -i # Squash inconsequential commits. Rebase is okay before publishing. Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview 7. Catch up to official Cog branch $ git fetch # updates origin/* $ git log HEAD..origin/Cog # review other updates $ git diff origin/Cog # review other updates Depending on whether the final history should be linear (more like SVN??) $ git rebase origin/Cog # rebase okay since not yet published or show the branching... $ get merge origin/Cog ...might depend on whether its a small fix or a larger feature added. 8. Submit for review $ git push # to server You will see... fatal: The current branch SomeBug has no upstream branch. which is because the SomeBug branch only exists locally, not on the github server. The following creates the branch on the "origin" server and sets things so subsequently this branch only requires "git push". $ git push --set-upstream origin SomeBug * On github, from the pulldown button, select your SomeBug branch. * Click button. For more detail refer... https://help.github.com/articles/using-pull-requests/ (In the meantime, work on some other branch) 7. Reviewers can download PR to test locally as described here... https://help.github.com/articles/checking-out-pull-requests-locally/ (though I've not done that since I've not been on the receiving side of a pull request before) 8. Respond to reviewer comments. Edit, compile, test, resubmit. $ git checkout SomeBug * make required changes $ git stage -u $ git commit -m "changed per feedback " $ git push # Pull request auto updated (Repeat as required) 9. Pull request acceptable. Optionally (and some policy discussion required) squash changes from review period. $ git rebase -i $ git push -f Note this does rewrite the history of the published SomeBug branch, but presumably the branch is thrown away after integration so no real foul. But forcing pushing may be risk for accidentally doing it to the Cog or master branches. (btw, has the force protection on those two branches been tested?) 10. On github, integrator accepts pull request. 11. Delete branch. From sean at clipperadams.com Sun Jun 19 17:00:59 2016 From: sean at clipperadams.com (Sean P. DeNigris) Date: Sun Jun 19 17:40:50 2016 Subject: [Vm-dev] Re: Methods with more than 15 args sketch In-Reply-To: References: Message-ID: <1466355659866-4901817.post@n4.nabble.com> tim Rowledge wrote > Nononono. > Bad design to use huge parameter lists One of my favorite things about Smalltalk is what I understand to be a fundamental principle: to trust users with as much power as possible, not to place limits to prevent them from doing things that don't seem like a good idea like most systems. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Methods-with-more-than-15-args-sketch-tp4901127p4901817.html Sent from the Squeak VM mailing list archive at Nabble.com. From gettimothy at zoho.com Sun Jun 19 17:57:41 2016 From: gettimothy at zoho.com (gettimothy) Date: Sun Jun 19 17:57:44 2016 Subject: [Vm-dev] Speaking of git and git books.... Message-ID: <15569cf9c99.e05cb1de12409.4216625053762496504@zoho.com> I know that everybody is busy with the vm and git. I just want to through this out there The Tex/LaTex source code for some Squeak books is available. I have the SqueakByExample-english source code on my computer (I forget where I got it). That have one that I used as a model for my Programming The Squeak Virtual Machines...than I am (was) writing as I try (tried) to understand the Interpreter stuff. The transition to git provides an opportunity to upload the source code for those books so as to provide for more dispersed community development access point. Editing would "merely" be a matter of merging in changes and new branches. The content could grow a bit more quickly with that model. cheers, tty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160619/a4cb8876/attachment.htm From commits at source.squeak.org Mon Jun 20 00:42:22 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Jun 20 00:42:23 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.128.mcz Message-ID: Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.128.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.128 Author: tty Time: 19 June 2016, 7:48:27.621979 pm UUID: d60fe794-87a2-4a70-88e7-2852d3eab8e5 Ancestors: CMakeVMMakerSqueak-tty.127 Writing a terse guide as I build a Linux64x64SqueakCogSpurConfig from scratch Started a refactoring sweep . Refactored compilerFlags, compilerDefinitions linker flags methods to use the redirect pattern. wrote tests to check new methods consider this a stage save. I have more to do on this line of attack Left a note to myself to add a method protocol named "customizable" or something to cue the end-user that these methods should be customized by them. I expect the number of redirect method constructs to drastically reduce and the number of redirect methods that are directly customizable to increase. =============== Diff against CMakeVMMakerSqueak-tty.127 =============== Item was changed: ----- Method: CMakePluginVm>>template (in category 'accessing') ----- template |temp sourcesString cflags| cflags:= String streamContents: [:stream | config compilerFlags asStringOn: stream delimiter: ' ' ]. cflags := '"' , cflags , '"'. sourcesString := String streamContents: [:stream | sources asStringOn: stream delimiter: ' ' ]. temp := OrderedCollection new. temp addLast: ((CMakeHeader new) configurationName: config class name ); addLast: ((CMakeProject new)variable: module ); addLast: ((CMakeMinimumRequired new) version: '2.8.12'); addLast: ((CMakeInclude new) file: ((config buildDir fullName), FileDirectory slash, 'directories.cmake')) ; addLast:((CMakeAddDefinitions new) definitions: config compilerDefinitions asOrderedCollection); addLast:((CMakeAddDefinitions new) definitions: config compilerFlags asOrderedCollection); addLast:((CMakeAddDefinitions new) definitions: definitions); " addLast:((CMakeSet new) variable:'sources' quotedValue: sourcesString);" addLast:((CMakeSet new) variable:'sources' value: sourcesString); addLast:((CMakeAddLibrary new) library: module type: 'SHARED' sources: (OrderedCollection with: '${sources}')); addLast: ((CMakeIncludeDirectories new) dirs: includedirectories); addLast:((CMakeSet new) variable: 'LIBRARY_OUTPUT_PATH' quotedValue: (config outputDir fullName)); " addLast:((CMakeListAppend new) list: 'LINKLIBS' elements: (config externalLibs));" addLast:((CMakeTargetLinkLibraries new) target: module items: (OrderedCollection with: '${LINKLIBS}')); addLast:((CMakeSetTargetProperties new) target: module propertiesandvalues: (OrderedCollection with: 'PREFIX "" ' with: 'SUFFIX "" ' with: 'LINK_FLAGS ' , cflags)) . ^temp! Item was added: + ----- Method: CMakeVMMakerSqueakCommonConfigTest>>testCustomizeVMPlugins (in category 'as yet unclassified') ----- + testCustomizeVMPlugins + #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig) + do:[:each | + (Smalltalk at:each) + allSubclassesDo:[:configuration | | o buildTypes| + o:= configuration basicNew. + (o excludeFromBuild not) & (configuration isAbstractBaseClass not) + ifTrue:[ + buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). + buildTypes do:[:buildType | + o configureForBuildType: buildType. + o initializeVMPlugins. + self assert:(o vmplugins isKindOf:Collection)]]]] + + + + + + ! Item was added: + ----- Method: CMakeVMMakerSqueakCommonConfigTest>>testInitializeVMPlugins (in category 'as yet unclassified') ----- + testInitializeVMPlugins + #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig) + do:[:each | + (Smalltalk at:each) + allSubclassesDo:[:configuration | | o | + o:= configuration basicNew. + o initializeVMPlugins. + o excludeFromBuild not + ifTrue:[self assert:(o vmplugins isKindOf:Collection)]]] + + + + + + + + ! Item was added: + ----- Method: CMakeVMMakerSqueakRedirectMethodsTest>>testCompilerDefinitions (in category 'as yet unclassified') ----- + testCompilerDefinitions + #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) + do:[:each | + (Smalltalk at:each) + allSubclassesDo:[:configuration | | o buildTypes| + o:= configuration basicNew. + (o excludeFromBuild not) & (configuration isAbstractBaseClass not) + ifTrue:[ + buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). + buildTypes do:[:buildType | + o configureForBuildType: buildType. + self assert:(o compilerDefinitions isKindOf: Collection). + self assert:(o compilerDefinitions size > 0)]]]]. + + + + + + + + ! Item was changed: ----- Method: CMakeVMMakerSqueakRedirectMethodsTest>>testCompilerFlags (in category 'as yet unclassified') ----- testCompilerFlags #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) do:[:each | (Smalltalk at:each) allSubclassesDo:[:configuration | | o buildTypes| o:= configuration basicNew. (o excludeFromBuild not) & (configuration isAbstractBaseClass not) ifTrue:[ buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). buildTypes do:[:buildType | o configureForBuildType: buildType. self assert:(o compilerFlags isKindOf: Collection). self assert:(o compilerFlags size > 0)]]]]. ! Item was added: + ----- Method: CMakeVMMakerSqueakRedirectMethodsTest>>testLinkerFlags (in category 'as yet unclassified') ----- + testLinkerFlags + #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) + do:[:each | + (Smalltalk at:each) + allSubclassesDo:[:configuration | | o buildTypes| + o:= configuration basicNew. + (o excludeFromBuild not) & (configuration isAbstractBaseClass not) + ifTrue:[ + buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). + buildTypes do:[:buildType | + o configureForBuildType: buildType. + self assert:(o linkerFlags isKindOf: Collection). + self assert:(o linkerFlags size > 0)]]]]. + + + + + + + + ! Item was changed: ----- Method: CMakeVMMakerSqueakRedirectMethodsWithArgTest>>testExtraPluginSettings (in category 'as yet unclassified') ----- testExtraPluginSettings self flag:'tty'. "Is the self shouldnt sufficient?" #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) do:[:each | (Smalltalk at:each) allSubclassesDo:[:configuration | | o buildTypes vmGenerator pluginGenerator| o:= configuration basicNew. (o excludeFromBuild not) & (configuration isAbstractBaseClass not) ifTrue:[ buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). buildTypes do:[:buildType | o configureForBuildType: buildType. + o enabledebugmessages:true. + o templates: OrderedCollection new. vmGenerator:=CMakeVMGeneratorForSqueak new. vmGenerator config: o. vmGenerator output:(String new writeStream). pluginGenerator := CMakePluginGeneratorForSqueak new. pluginGenerator vmGenerator: vmGenerator. pluginGenerator isInternal: false. pluginGenerator output:(String new writeStream). pluginGenerator templates: OrderedCollection new. self shouldnt: [o extraPluginSettings: pluginGenerator] raise: Error]]]]. ! Item was added: + ----- Method: CMakeVMMakerSqueakRedirectMethodsWithArgTest>>testSetPlatformSources (in category 'as yet unclassified') ----- + testSetPlatformSources + #(#SqueakMacintoshConfig #SqueakUnixConfig #SqueakWindowsConfig ) + do:[:each | + (Smalltalk at:each) + allSubclassesDo:[:configuration | | o buildTypes vmGenerator| + o:= configuration basicNew. + (o excludeFromBuild not) & (configuration isAbstractBaseClass not) + ifTrue:[ + buildTypes:=o availableBuildTypes copyWithoutAll:#(#buildNone). + buildTypes do:[:buildType | + o configureForBuildType: buildType. + o enabledebugmessages: true. + o templates: OrderedCollection new. + o initializePlatformSources. + vmGenerator:=CMakeVMGeneratorForSqueak new. + vmGenerator config: o. + vmGenerator output:(String new writeStream). + self shouldnt: [o setPlatformSources: vmGenerator] raise: Error]]]]. + ! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>createTheConfiguration (in category 'pages') ----- createTheConfiguration ^HelpTopic title:'Create the Configuration' contents: 'Within the broad outline of this tutorial, you are here: 4. Create your Configuration Our new Concrete Configuration must be created as a subclass of our Platform''s Abstract Base Class. + SInce I am creating a Squeak Cog Spur config for the CMakeVMMakerSqueak-Linux64X86-32BitCompatibility Platform I choose the name*: - SInce I am creating a Squeak Cog Spur config for the CMakeVMMakerSqueak-Linux64X86-32BitCompatibility Platform I choose the name: Linux64x86w32BitSqueakCogSpurConfig. - (For a discussion on naming conventions evaluate: - HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp - ) To create it, I must subclass the Abstract Base Class for my Platform like so: Linux64x86w32BitConfigUsrLib subclass: #Linux64x86w32BitSqueakCogSpurConfig instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: ''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' However, being lazy, I am going to copy an existing Configuration that is similar to what I want. Today I choose Linux64x86w32BitSqueakCogV3Config from the CMakeVMMakerSqueak-Linux64X86-32BitCompatibility Platform category I copy the class and then change its name, parent and class category to get: Linux64x86w32BitConfigUsrLib subclass: #Linux64x86w32BitSqueakCogSpurConfig instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: ''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' I then query by Builder to see if it sees the new Configuration in the platform: SqueakLinux64x86w32CompatBuilder configurationsCategory --> ''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' SqueakLinux64x86w32CompatBuilder availableBuildConfigurations --> a SortedCollection(#Linux64x86w32BitSqueakCogSpurConfig #Linux64x86w32BitSqueakCogV3Config) "Here we see our new Configuration is visible to the Builder" SqueakLinux64x86w32CompatBuilder unAvailableBuildConfigurations --> a SortedCollection(#Linux64x86w32BitConfigUsrLib #Linux64x86w32BitConfigUsrLib32) "Our Abstract Base Classes are not available to be built" SqueakLinux64x86w32CompatBuilder availableBuildTypesFor: #Linux64x86w32BitSqueakCogSpurConfig --> an OrderedCollection(#build #buildAssert) "The Configuration I copied has two Build Types coded and available." SqueakLinux64x86w32CompatBuilder sourceDirectoryFor:#Linux64x86w32BitSqueakCogSpurConfig --> "src" "Where the vm source code is located (we will be changing this)" My new configuration is correctly named and in the correct place. At this point I re-run all my Tests. TestRunner open For me, all tests pass. In the next topic we cover how to hide our new Configuration from a builder. + *For a discussion on naming conventions evaluate: + HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp + + ' ! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>identifyBuilder (in category 'pages') ----- identifyBuilder ^HelpTopic title:'Identify Builder' contents: 'Within the broad outline of this tutorial, you are here: 3. What Builder to use My new Configuration will be managed by a Builder. Builders are located in the CMakeVMMakerSqueak-Builder class category. Builders are subclasses of SqueakCMakeVMMakerAbstractBuilder. SqueakCMakeVMMakerAbstractBuilder browseHierarchy + Builders are named* according to the Platform they manage. - Builders are named according to the Platform they manage. - (For a discussion on naming conventions evaluate: - HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp - ) - Builders manage configurations for one Platform in one class category. - My platform is Linux Linux64x86 with 32 bit compatability libs stored in /usr/lib (other linux use /usr/lib32 for this.) I suspect that the SqueakLinux64x86w32CompatBuilder as the Builder that will manage my new configuration. I confirm this by sending it the ''configurationsCategory'' message as shown below: SqueakLinux64x86w32CompatBuilder configurationsCategory -->''CMakeVMMakerSqueak-Linux64X86-32BitCompatibility'' <---this is the correct class category for my Platform. This is correct Builder for my new Configuration. I can query the Builder for some more information: SqueakLinux64x86w32CompatBuilder availableBuildConfigurations a SortedCollection(#Linux64x86w32BitSqueakCogV3Config) <--A Cog V3 configuration exists. SqueakLinux64x86w32CompatBuilder unAvailableBuildConfigurations --> a SortedCollection(#Linux64x86w32BitConfigUsrLib #Linux64x86w32BitConfigUsrLib32) <--these are platform specific Abstract Base Classes. Abstract Base Classes cannot be built, hence they are unavailable. - SqueakLinux64x86w32CompatBuilder buildDirectory - -->''cmake.build.linux64x86w32BitCompatibility'' <--this matches my platform - We will be using the SqueakLinux64x86w32CompatBuilder in tandem with Tests during Configuration development.' + We will be using the SqueakLinux64x86w32CompatBuilder in tandem with Tests during Configuration development. + + *For a discussion on naming conventions evaluate: + HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp + + ' + ! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>identifyPlatform (in category 'pages') ----- identifyPlatform ^HelpTopic title:'Identify Platform' contents: ' Within the broad outline of this tutorial, you are here: 2. Where to place your new Configuration My target platform is 64 bit Linux on X86 with 32 bit compatibility libraries stored in /usr/lib. I identify my Platform in the existing CMakeVMMakerSqueak-xyz class categories. + As of 2016.06.19 the class categories that correspond to target platforms are: + + CMakeVMMakerSqueak-IA32-Bochs + CMakeVMMakerSqueak-IOS + CMakeVMMakerSqueak-Linux32ARMv6 + CMakeVMMakerSqueak-Linux32x86 + CMakeVMMakerSqueak-Linux64X86-32BitCompatibility + CMakeVMMakerSqueak-Linux64x64 + CMakeVMMakerSqueak-MacOSPowerPC + CMakeVMMakerSqueak-MacOSX32x86 + CMakeVMMakerSqueak-SunOS32x86 + CMakeVMMakerSqueak-Win32x86 + + + If I wanted a configuration for MacOSX32x86, I would place my configuration in CMakeVMMakerSqueak-MacOSX32x86. If SunOSx3x86 then CMakeVMMakerSqueak-SunOS32x86. etc. + Sincy my target platform is 64 bit Linux on X86 with 32 bit compatibility libraries stored in /usr/lib. I choose + the class category CMakeVMMakerSqueak-Linux64X86-32BitCompatibility to contain my new configurartion + For a discussion on naming conventions evaluate: HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp '! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>identifyPlatformAbstractBaseClass (in category 'pages') ----- identifyPlatformAbstractBaseClass ^HelpTopic title:'Identify Abstract Base Class ' contents: 'Within the broad outline of this tutorial, you are here: 2. Where to place your new Configuration My new configuration must be a subclass of my Platform''s Abstract Base Class. A Platform Abstract Base Class encapsulates common platform information. In CMakeVMMakerSqueak-Linux64X86-32BitCompatibility class category I see two Abstract Base Classes (typically there is only one). They are: Linux64x86w32BitConfigUsrLib Linux64x86w32BitConfigUsrLib32 The Suffixes ''UsrLib'' and ''UsrLib32'' refer to the location of the 32 bit compatablity libs. + Some systems (Ubuntu?) place their 32 bit compatability libs in /usr/lib32. + On my system (Slackware) they are in /usr/lib, so I choose Linux64x86w32BitConfigUsrLib as my Abstract Base Class - On my system they are in /usr/lib, so I choose Linux64x86w32BitConfigUsrLib as my Abstract Base Class Examples of Abstract Base Classes in other class categories include: CMakeVMMakerSqueak-BSD32x86 -> SqueakBSD32x86Config CMakeVMMakerSqueak-IA32-Bochs -> SqueakIA32BochsConfig CMakeVMMakerSqueak-IOS -> SqueakIOSConfig CMakeVMMakerSqueak-IOS -> SqueakIOSConfig CMakeVMMakerSqueak-Linux32ARMv6 -> Linux32ARMv6Config CMakeVMMakerSqueak-Linux64x64 -> Linux64x64Config CMakeVMMakerSqueak-MacOSPowerPC -> SqueakMacOSXPowerPCConfig CMakeVMMakerSqueak-MacOSX32x86 -> SqueakMacOSX32x86Config CMakeVMMakerSqueak-SunOS32x86 -> SqueakSunOS32x86Config CMakeVMMakerSqueak-Win32x86 -> SqueakWin32x86Config I can identify the Abstract Base Class in several ways 1. It is a topmost class in the class heirarchy for that platform/class category 2. It is named after its platform 3. It answers #true to the message isAbstractBaseClass Linux64x86w32BitConfigUsrLib isAbstractBaseClass --> true In this workflow example I ideduce that the AbstractBaseClass for my Platform is Linux64x86w32BitConfigUsrLib'! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>initializeVMPlugins (in category 'pages') ----- initializeVMPlugins + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #initializeVMPlugins" ^HelpTopic + title: 'Initialize VM Plugins' + contents: - title:'Initialize VM Plugins' - contents: 'Within the broad outline of this tutorial, you are here: 8. Customizing your Configuration. VM Pluings are a type of plugin that is unique to Unix. Their directories exist in the Cog/Platforms/unix directory Shown here: bash-4.2$ ls -1d Cog/platforms/unix/vm-* Cog/platforms/unix/vm-display-Quartz Cog/platforms/unix/vm-display-X11 Cog/platforms/unix/vm-display-custom Cog/platforms/unix/vm-display-fbdev Cog/platforms/unix/vm-display-null Cog/platforms/unix/vm-sound-ALSA Cog/platforms/unix/vm-sound-MacOSX Cog/platforms/unix/vm-sound-NAS Cog/platforms/unix/vm-sound-OSS Cog/platforms/unix/vm-sound-Sun Cog/platforms/unix/vm-sound-custom Cog/platforms/unix/vm-sound-null Cog/platforms/unix/vm-sound-pulse ToolSet browse: CPlatformConfigForSqueak selector: #initializeVMPlugins is a hard-coded list of these VM Plugins but expressed as a list of encapsulating objects. These objects are just data buckets for carrying information that will be used to build them. CMakeVMPlugin browseHierarchy + On initialization, the CPlatformConfigForSqueak stores them in its vmplugins instance variable where we will customize them later. + !!' readStream nextChunkText! - On initialization, the CPlatformConfgiForSqueak stores them in its vmplugins instance variable where we will customize them later. - '! Item was added: + ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>isAbstractBaseClass (in category 'pages') ----- + isAbstractBaseClass + ^HelpTopic + title:'Is Abstract Base Class' + contents: + 'Within the broad outline of this tutorial, you are here: + 5. Interaction of the Builder and your Configuration + + Configurations must identify themselves as NOT being an Abstract Base Class + + The default, inhereted from CPlatformConfigForSqueak is that a Configuration IS an Abstract Base Class. + + CPlatformConfigForSqueak class browse + + isAbstractBaseClass + ^true + + If we look at our new configuration that we just copied from an existing, we see + Linux64x86w32BitSqueakCogSpurConfig class browse + + isAbstractBaseClass + ^false + + + + + + + ^false "build this configuration" + " ^true do not build this configuration" + + In our case, the Builder shows us that Linux32x86SqueakCogSpurConfig is capable of being built (I had copied an existing, working Configuration): + + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogSpurConfig #Linux64x86w32BitSqueakCogV3Config) + + + To exclude it, override (or alter) the Configurations ''excludeFromBuild'' method + + Linux64x86w32BitSqueakCogSpurConfig >>excludeFromBuild + "over-ride to exclude yourself from a build" + ^true + + And the Configuration is hidden from the Builder... + + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogV3Config) + + + However, since I am developing locally, I need it to be visible to the Builder , so I set it as so: + + Linux64x86w32BitSqueakCogSpurConfig >>excludeFromBuild + "over-ride to exclude yourself from a build" + ^false + + And my Builder can see it again... + + SqueakLinux64x86w32CompatBuilder availableBuildConfigurations + --> a SortedCollection(#Linux64x86w32BitSqueakCogSpurConfig #Linux64x86w32BitSqueakCogV3Config) + + + N.B. tty. My opinion is that this is a weak way of doing this, but I have not thought through how to do this elegantly. + This functionality is included with an eye towards easing automated builds for all platforms and configurations.'! Item was added: + ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>isAbstractBaseClassAndExcludeFromBuild (in category 'pages') ----- + isAbstractBaseClassAndExcludeFromBuild + ^HelpTopic + title:'ExcludeFrom Build and Abstract Base Class' + contents: + 'Within the broad outline of this tutorial, you are here: + 5. Interaction of the Builder and your Configuration + + + A bit of explanation about excludeFromBuild and isAbstractBaseClass is in order. + + Both Builders and Tests use the truth values of these methods to determine if a Configuration should be tested or built or queried + + The Class comment for CPlatformConfigForSqueak explains the interaction in full. + + ClassCommentVersionsBrowser browseCommentOf:CPlatformConfigForSqueak + + '! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>pages (in category 'accessing') ----- pages "platformSources...cogitClass...src vs vmsrc" ^#( overview tests identifyPlatform identifyPlatformAbstractBaseClass identifyBuilder createTheConfiguration excludingConfigFromBuilds + isAbstractBaseClass + isAbstractBaseClassAndExcludeFromBuild + setAvailableBuildTypes firstCMakeGeneration tackingStockOne cPlatformConfigForSqueak methodRedirectPattern theVMGenerator tackingStockTwo cPlatformConfigForSqueakInitialize initializePlatformSources customizePlatformSources initializeVMPlugins customizeVMPlugins configGenerateByTemplate specifyCogitClass - vmsrc specifyDirectories dirBuildLanguageVMMM setGlobalOptions cmakePrefixPath cmakeIncludePath cmakeLibraryPath cmakeIncludeModules cmakeCFlags cmakeAddDefinitions cmakeWriteDirectoriesDotCmake cmakeIncludeDirectories preferredIncludes standardIncludes setGlobalOptionsAfterDetermineSystem extraVMSettings setCoreSources setPlatformSources setCrossSources setExtraSources cmakeSetSourceFilesProperties cmakeListAppendLINKLIBSelements cmakeAddExecutableNameOptionSource setExecutableOutputPath addVMPlugins generatePluginConfigs specifyPlugins processPlugins postBuildActions generateBuildScript fin ) ! Item was removed: - ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>vmsrc (in category 'pages') ----- - vmsrc - ^HelpTopic - title:'vmsrc' - contents: - 'Within the broad outline of this tutorial, you are here: - 8. Customizing your Configuration. - - - write me. - '! Item was changed: ----- Method: CMakeVMakerConfigurationInfo>>visit: (in category 'visiting') ----- visit: aVisitor |v| "I am being visited by a CMakeVMMakerSqueak configuration class. Extract its information and store it in myself" + self flag:'tty dirSource and dirBuildPlatform an instance of an irritating difference in idioms when dealing with directory paths'. - self flag:'tty'. "why am I not storing the instances itself?does this visit stuff really make sense? I am thinking its 'lightweight'. hmmm" v:= aVisitor basicNew. (v class isAbstractBaseClass) ifTrue:[ isAbstractBaseClass := true. excludeFromBuild := true] ifFalse:[ availableBuildTypes := v availableBuildTypes. + dirBuildPlatform := v dirBuildPlatform . "dirBuildPlatform is a String" + dirSource := v dirSource fullName. "dirSource is a FileDirectory, so convert to string" - dirBuildPlatform := v dirBuildPlatform. excludeFromBuild := v excludeFromBuild. isAbstractBaseClass := false]. ! Item was changed: Object subclass: #CPlatformConfigForSqueak + instanceVariableNames: 'buildType cogDir generateBuild generateBuildAssert generateBuildAssertITimerHeartbeat generateBuildDebug generateBuildDebugITimerHeartbeat generateBuildDebugMultiThreaded generateBuildIHeartbeatTimer generateBuildMultiThreaded generateBuildMultiThreadedAssert generateBuildMultiThreadedDebug templates enabledebugmessages platformSources vmplugins outputDir buildDir topDir internalPlugins externalPlugins' - instanceVariableNames: 'buildType cogDir generateBuild generateBuildAssert generateBuildAssertITimerHeartbeat generateBuildDebug generateBuildDebugITimerHeartbeat generateBuildDebugMultiThreaded generateBuildIHeartbeatTimer generateBuildMultiThreaded generateBuildMultiThreadedAssert generateBuildMultiThreadedDebug templates enabledebugmessages platformSources vmplugins outputDir buildDir topDir' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMakerSqueak'! CPlatformConfigForSqueak class instanceVariableNames: 'isAbstractBaseClass'! !CPlatformConfigForSqueak commentStamp: 'tty 12/8/2014 11:28' prior: 0! A CPlatformConfigForSqueak acts as a compatability layer for Squeak and an Abstract Base Class for extended functionality required for the Squeak CMakeVMMaker use-case. I make (very) heavy use of a specific design pattern for configuring myself and remaining compatible with pharo's CMakeVMMaker. The entry point for that pattern is my method 'configureForBuildType: aSymbol' . Each method send in there detects my buildType and routes the send to the approriate method for that buildType. Subclasses of me 'must' configure themselves for each build type per that pattern. However this can be very easy by just returning the base configuration. Tests are written to verify that this support infrastructure is in place. I have two important methods. excludeFromBuild and isAbstractBaseClass. excludeFromBuild is used to exclude a configuration from being built by a Builder. is used to exclude a configuration from Testing. isAbstractBaseClass is used by configurations that exclude themselves from being built by a Builder BUT need to be included in Testing. excludeFromBuild | isAbstractBaseClass | should build | should test T T NO YES T F NO NO F T YES YES F F YES YES The use-case is as follows. An abstract base class contains a lot of functionality that must be implemented and tested for the system to work, but it is not meant to be compiled. concrete classes of that AbstractBase class can exclude themselves from being built by builders and by doing so are not tested. However, once a concrete configuration is enabled to be built, it must pass all tests. Linux32x86Config is an example of an AbstractBase class that must pass all testing, but is not buildable. Its subclass Linux32x86SqueakCogV3Config needs testing, but a developer can toggle 'exclude from build' to hide it from Builders or make it available to them. Tests make the decision on what configurations to test. Here are some examples. (o excludeFromBuild not) & (configuration isAbstractBaseClass not) this is a concrete [Lang][VM][MemoryManager][etc] configuration that will be built. No platform classes considered (o excludeFromBuild) & (configuration isAbstractBaseClass not) This is a concrete [Lang][VM][MemoryManager][etc] configuration that will be NOT built. (o excludeFromBuild not) | (configuration isAbstractBaseClass) concrete implementation may depend on its [OS][VMWordSize][Processor] AbstractBaseClass for platform level methods. example: Linux32x86Config ccBuild has the '-m32' compiler flag that is common to all builds on that platform (o excludeFromBuild not) & (configuration isAbstractBaseClass) Not allowed. [OS][VMWordSize][Processor] AbstractBaseClasses should not be built. This is a useful test in its own right. (o excludeFromBuild) & (configuration isAbstractBaseClass) These are the AbstractBaseClasses. An AbstractBaseClass should always be excluded from a build HelpBrowser openOn: CMakeVMMakerSqueakDeveloperHelp tty.! CPlatformConfigForSqueak class instanceVariableNames: 'isAbstractBaseClass'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>buildDir (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>buildDir (in category 'cmake directory') ----- buildDir ^ buildDir ifNil: [ buildDir := ( self topDir / self buildDirName) assureExistence]. ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>buildDirName (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>buildDirName (in category 'cmake directory') ----- buildDirName buildType isNil ifTrue:[^self dirBuildPlatform, FileDirectory slash, self dirBuildLanguageVMMM, FileDirectory slash, 'build'] ifFalse:[^self dirBuildPlatform, FileDirectory slash, self dirBuildLanguageVMMM, FileDirectory slash, buildType asString]! Item was changed: ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitions (in category 'cmake buildType redirects') ----- cmakeAddDefinitions + self subclassResponsibility. + ! - "Route this message send to the message appropriate for my buildType " - |d | - d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. - d - at: #build put: [self cmakeAddDefinitionsBuild]; - at: #buildAssert put: [self cmakeAddDefinitionsBuildAssert]; - at: #buildAssertITimerHeartbeat put: [self cmakeAddDefinitionsBuildAssertITimerHeartbeat]; - at:#buildDebug put: [self cmakeAddDefinitionsBuildDebug]; - at: #buildDebugITimerHeartbeat put: [self cmakeAddDefinitionsBuildDebugITimerHeartbeat ]; - at: #buildITimerHeartbeat put: [self cmakeAddDefinitionsBuildITimerHeartbeat]; - at: #buildMultiThreaded put: [self cmakeAddDefinitionsBuildMultiThreaded]; - at: #buildMultiThreadedAssert put: [self cmakeAddDefinitionsBuildMultiThreadedAssert]; - at: #buildMultiThreadedDebug put: [self cmakeAddDefinitionsBuildMultiThreadedDebug ]; - at: #buildNone put:[self cmakeAddDefinitionsNoBuildType]. - ^(d at: buildType) value! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuild (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuild - "" - self subclassResponsibility! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildAssert - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildAssertITimerHeartbeat - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildDebug (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildDebug - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildDebugITimerHeartbeat - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildITimerHeartbeat - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildMultiThreaded (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildMultiThreaded - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildMultiThreadedAssert - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildMultiThreadedDebug - "override default for custom buildType. " - ^self cmakeAddDefinitionsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeAddDefinitionsNoBuildType (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsNoBuildType - "SHOULD NOT GET HERE" - self shouldNotImplement. - ! Item was changed: ----- Method: CPlatformConfigForSqueak>>cmakeCFlags (in category 'cmake buildType redirects') ----- cmakeCFlags + self subclassResponsibility + ! - "Route this message send to the message appropriate for my buildType " - |d | - d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. - d - at: #build put: [self cmakeCFlagsBuild]; - at: #buildAssert put: [self cmakeCFlagsBuildAssert]; - at: #buildAssertITimerHeartbeat put: [self cmakeCFlagsBuildAssertITimerHeartbeat]; - at:#buildDebug put: [self cmakeCFlagsPathBuildDebug]; - at: #buildDebugITimerHeartbeat put: [self cmakeCFlagsBuildDebugITimerHeartbeat ]; - at: #buildITimerHeartbeat put: [self cmakeCFlagsBuildITimerHeartbeat]; - at: #buildMultiThreaded put: [self cmakeCFlagsBuildMultiThreaded]; - at: #buildMultiThreadedAssert put: [self cmakeCFlagsBuildMultiThreadedAssert]; - at: #buildMultiThreadedDebug put: [self cmakeCFlagsBuildMultiThreadedDebug ]; - at: #buildNone put:[self cmakeCFlagsNoBuildType]. - ^(d at: buildType) value! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuild (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuild - " - convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType. - - cmake --help-variable CMAKE_C_FLAGS - cmake --help-variable CMAKE_C_FLAGS_DEBUG - cmake --help-variable CMAKE_C_FLAGS_RELEASE - - cmake --help-variable CMAKE_CXX_FLAGS - cmake --help-variable CMAKE_CXX_FLAGS_DEBUG - cmake --help-variable CMAKE_CXX_FLAGS_RELEASE - - NOTE: be careful not to clobber existing flags unless you intend to. - You can avoid that with this form: set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall -m32) which is created via cmake templates with - templates - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS' value: '${CMAKE_CXX_FLAGS} -Wall -m32'); - - - - - SystemNavigation default browseMethodsWhoseNamesContain: 'cmakeCFlagsBuild' - " - self subclassResponsibility.! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildAssert (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildAssert - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildAssertITimerHeartbeat - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildDebugITimerHeartbeat - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildITimerHeartbeat - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildMultiThreaded (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildMultiThreaded - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildMultiThreadedAssert - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuildMultiThreadedDebug - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsNoBuildType (in category 'cmake buildType redirects') ----- - cmakeCFlagsNoBuildType - "SHOULD NOT GET HERE" - self shouldNotImplement. - ! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeCFlagsPathBuildDebug (in category 'cmake buildType redirects') ----- - cmakeCFlagsPathBuildDebug - "convenience method for customizing CMAKE_C_FLAGS CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG variables based on #buildType." - ^self cmakeCFlagsBuild! Item was changed: ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesProperties (in category 'cmake buildType redirects') ----- cmakeSetSourceFilesProperties + self subclassResponsibility + " + cmake --help-command set_source_files_properties + set_source_files_properties + --------------------------- + + Source files can have properties that affect how they are built. + + :: + + set_source_files_properties([file1 [file2 [...]]] + PROPERTIES prop1 value1 + [prop2 value2 [...]]) + + Set properties associated with source files using a key/value paired + list. See properties documentation for those known to CMake. + Unrecognized properties are ignored. Source file properties are + visible only to targets added in the same directory (CMakeLists.txt). + + ." + + ! - "Route this message send to the message appropriate for my buildType " - |d | - d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. - d - at: #build put: [self cmakeSetSourceFilesPropertiesBuild]; - at: #buildAssert put: [self cmakeSetSourceFilesPropertiesBuildAssert]; - at: #buildAssertITimerHeartbeat put: [self cmakeSetSourceFilesPropertiesBuildAssertITimerHeartbeat]; - at:#buildDebug put: [self cmakeSetSourceFilesPropertiesBuildDebug]; - at: #buildDebugITimerHeartbeat put: [self cmakeSetSourceFilesPropertiesBuildDebugITimerHeartbeat ]; - at: #buildITimerHeartbeat put: [self cmakeSetSourceFilesPropertiesBuildITimerHeartbeat]; - at: #buildMultiThreaded put: [self cmakeSetSourceFilesPropertiesBuildMultiThreaded]; - at: #buildMultiThreadedAssert put: [self cmakeSetSourceFilesPropertiesBuildMultiThreadedAssert]; - at: #buildMultiThreadedDebug put: [self cmakeSetSourceFilesPropertiesBuildMultiThreadedDebug ]; - at: #buildNone put:[self cmakeSetSourceFilesPropertiesNoBuildType]. - ^(d at: buildType) value! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuild (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuild - " - cmake --help-command set_source_files_properties - set_source_files_properties - --------------------------- - - Source files can have properties that affect how they are built. - - :: - - set_source_files_properties([file1 [file2 [...]]] - PROPERTIES prop1 value1 - [prop2 value2 [...]]) - - Set properties associated with source files using a key/value paired - list. See properties documentation for those known to CMake. - Unrecognized properties are ignored. Source file properties are - visible only to targets added in the same directory (CMakeLists.txt). - - ." - - self subclassResponsibility.! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildAssert (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildAssert - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildAssertITimerHeartbeat - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildDebug (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildDebug - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildDebugITimerHeartbeat - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildITimerHeartbeat - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildMultiThreaded (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildMultiThreaded - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildMultiThreadedAssert - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuildMultiThreadedDebug - "convenience method for cusomizing for different buildType " - ^self cmakeSetSourceFilesPropertiesBuild! Item was removed: - ----- Method: CPlatformConfigForSqueak>>cmakeSetSourceFilesPropertiesNoBuildType (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesNoBuildType - "SHOULD NOT GET HERE" - self shouldNotImplement. - ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>cogDir (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>cogDir (in category 'cmake directory') ----- cogDir " topDir=oscogvm dirSource=[nsspur64src | nsspursrc |nsspurstack64src |nsspurstacksrc |spur64src |spursistasrc |spursrc | spurstack64src |spurstacksrc | src |stacksr] Configurations customize this srcDir=oscogvm/dirSource cogDir=oscogvm/src (needed by CMake for access to plugins source in oscogvm/src/plugins) " ^ cogDir ifNil: [ cogDir := (self src) ] ! Item was changed: ----- Method: CPlatformConfigForSqueak>>compilerDefinitions (in category 'compiling') ----- compilerDefinitions "-DNDEBUG -DGNU_SOURCE...etc . cmakeAddDefinitions(buildType) replaces this" + "Route this message send to the message appropriate for my buildType " + |d | + d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. + d + at: #build put: [self compilerDefinitionsBuild]; + at: #buildAssert put: [self compilerDefinitionsBuildAssert]; + at: #buildAssertITimerHeartbeat put: [self compilerDefinitionsBuildAssertITimerHeartbeat]; + at:#buildDebug put: [self compilerDefinitionsBuildDebug]; + at: #buildDebugITimerHeartbeat put: [self compilerDefinitionsBuildDebugITimerHeartbeat ]; + at: #buildITimerHeartbeat put: [self compilerDefinitionsBuildITimerHeartbeat]; + at: #buildMultiThreaded put: [self compilerDefinitionsBuildMultiThreaded]; + at: #buildMultiThreadedAssert put: [self compilerDefinitionsBuildMultiThreadedAssert]; + at: #buildMultiThreadedDebug put: [self compilerDefinitionsBuildMultiThreadedDebug ]; + at: #buildNone put:[self compilerDefinitionsNoBuildType]. + ^(d at: buildType) value! - self deprecated: 'Legacy method from pharo approach. We need different definitions for each buildType'. - self subclassResponsibility! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuild (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuild + + self subclassResponsibility. + + + ! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildAssert + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildAssertITimerHeartbeat + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildDebug (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildDebug + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildDebugITimerHeartbeat + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildITimerHeartbeat + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildMultiThreaded (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildMultiThreaded + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildMultiThreadedAssert + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildMultiThreadedDebug + ^self compilerDefinitionsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerDefinitionsNoBuildType (in category 'cmake buildType redirects') ----- + compilerDefinitionsNoBuildType + + self shouldNotImplement. + ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>compilerFlags (in category 'cmake buildType redirects') ----- - ----- Method: CPlatformConfigForSqueak>>compilerFlags (in category 'compiling') ----- compilerFlags + "Route this message send to the message appropriate for my buildType " + |d | + d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. + d + at: #build put: [self compilerFlagsBuild]; + at: #buildAssert put: [self compilerFlagsBuildAssert]; + at: #buildAssertITimerHeartbeat put: [self compilerFlagsBuildAssertITimerHeartbeat]; + at:#buildDebug put: [self compilerFlagsBuildDebug]; + at: #buildDebugITimerHeartbeat put: [self compilerFlagsBuildDebugITimerHeartbeat ]; + at: #buildITimerHeartbeat put: [self compilerFlagsBuildITimerHeartbeat]; + at: #buildMultiThreaded put: [self compilerFlagsBuildMultiThreaded]; + at: #buildMultiThreadedAssert put: [self compilerFlagsBuildMultiThreadedAssert]; + at: #buildMultiThreadedDebug put: [self compilerFlagsBuildMultiThreadedDebug ]; + at: #buildNone put:[self compilerFlagsNoBuildType]. + ^(d at: buildType) value! - self deprecated:' this catchall method has been split into dedicated methods: cmakePrefixPath cmakeIncludePath cmakeLibraryPath cmakeIncludeModules; cmakeCFlags; '. "see method ''generate'' in CMakeVMGeneratorForSqueak browse for old call. " - self cmakeCFlags. - - - "The old CMakeVMMaker loaded all kinds of stuff in compilerflags that where really pre-processor definitions etc. - I have factored them out in the interest of clarity and simplicity. - "! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuild (in category 'cmake buildType redirects') ----- + compilerFlagsBuild + + self subclassResponsibility. + + + " ^#('-Wall' + '-w' + '-m32' + '-msse2' + '-g3' + '-O1' + '-fno-caller-saves' + '-fno-tree-pre')" + ! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildAssert (in category 'cmake buildType redirects') ----- + compilerFlagsBuildAssert + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- + compilerFlagsBuildAssertITimerHeartbeat + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildDebug (in category 'cmake buildType redirects') ----- + compilerFlagsBuildDebug + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- + compilerFlagsBuildDebugITimerHeartbeat + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- + compilerFlagsBuildITimerHeartbeat + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildMuliThreadedDebug (in category 'cmake buildType redirects') ----- + compilerFlagsBuildMuliThreadedDebug + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildMultiThreaded (in category 'cmake buildType redirects') ----- + compilerFlagsBuildMultiThreaded + ^self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- + compilerFlagsBuildMultiThreadedAssert + ^ self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- + compilerFlagsBuildMultiThreadedDebug + ^ self compilerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>compilerFlagsNoBuildType (in category 'cmake buildType redirects') ----- + compilerFlagsNoBuildType + + self shouldNotImplement. + ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirARMv6 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirARMv6 (in category 'cmake directory') ----- dirARMv6 ^'cmake.build.arm.v6'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirAndroid (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirAndroid (in category 'cmake directory') ----- dirAndroid ^'Do Not Build. See Class Comment'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBSD32x86 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBSD32x86 (in category 'cmake directory') ----- dirBSD32x86 ^'cmake.build.bsd32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuild (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuild (in category 'cmake directory') ----- dirBuild ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #build! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildAssert (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildAssert (in category 'cmake directory') ----- dirBuildAssert ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildAssert! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildAssertITimerHeartbeat (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildAssertITimerHeartbeat (in category 'cmake directory') ----- dirBuildAssertITimerHeartbeat ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildAssertITimerHeartbeat! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildDebug (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildDebug (in category 'cmake directory') ----- dirBuildDebug ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #debug! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildDebugITimerHeartbeat (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildDebugITimerHeartbeat (in category 'cmake directory') ----- dirBuildDebugITimerHeartbeat ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #debugITimerHeartbeat! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildDebugMultiThreaded (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildDebugMultiThreaded (in category 'cmake directory') ----- dirBuildDebugMultiThreaded ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #debugMultiThreaded! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildITimerHeartbeat (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildITimerHeartbeat (in category 'cmake directory') ----- dirBuildITimerHeartbeat ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildITimerHeartbeat! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildLanguageVMMM (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildLanguageVMMM (in category 'cmake directory') ----- dirBuildLanguageVMMM "the directory under buildPlatformDir example: newspeak.cog.spur. " self subclassResponsibility! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreaded (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreaded (in category 'cmake directory') ----- dirBuildMultiThreaded ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildMultiThreaded! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedAssert (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedAssert (in category 'cmake directory') ----- dirBuildMultiThreadedAssert ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildMultiThreadedAssert! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedDebug (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildMultiThreadedDebug (in category 'cmake directory') ----- dirBuildMultiThreadedDebug ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #buildMultiThreadedDebug! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirBuildPlatform (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirBuildPlatform (in category 'cmake directory') ----- dirBuildPlatform "the directory for the platform. example: build.linux32x86" self subclassResponsibility! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirIA32Bochs (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirIA32Bochs (in category 'cmake directory') ----- dirIA32Bochs ^'cmake.build.ia32bochs'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirIOS (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirIOS (in category 'cmake directory') ----- dirIOS ^'cmake.build.ios'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux32Armv6 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux32Armv6 (in category 'cmake directory') ----- dirLinux32Armv6 ^'cmake.build.linux32armv6'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux32x86 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux32x86 (in category 'cmake directory') ----- dirLinux32x86 ^'cmake.build.linux32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux64x64 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux64x64 (in category 'cmake directory') ----- dirLinux64x64 ^'cmake.build.linux64x64'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirLinux64x86w32BitCompatibility (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirLinux64x86w32BitCompatibility (in category 'cmake directory') ----- dirLinux64x86w32BitCompatibility ^'cmake.build.linux64x86w32BitCompatibility'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirMacOS (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirMacOS (in category 'cmake directory') ----- dirMacOS ^'cmake.build.macos'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirMacOSPowerPC (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirMacOSPowerPC (in category 'cmake directory') ----- dirMacOSPowerPC ^'cmake.build.macospowerpc'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirMacOSX32x86 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirMacOSX32x86 (in category 'cmake directory') ----- dirMacOSX32x86 ^'cmake.build.macosx32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirOutput (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirOutput (in category 'cmake directory') ----- dirOutput ^'cmake.products'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirPlatforms (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirPlatforms (in category 'cmake directory') ----- dirPlatforms ^'platforms'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirSource (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>dirSource (in category 'cmake directory') ----- dirSource " dirSource=[nsspur64src | nsspursrc | nsspurstack64src |nsspurstacksrc |spur64src |spursistasrc |spursrc | spurstack64src |spurstacksrc | src |stacksr] Configurations must customize this srcDir=oscogvm/dirSource cogDir=oscogvm/src (needed by CMake for access to plugins source in oscogvm/src/plugins) " self subclassResponsibility ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirSunOS32x86 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirSunOS32x86 (in category 'cmake directory') ----- dirSunOS32x86 ^'cmake.build.sunos32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>dirWin32x86 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>dirWin32x86 (in category 'cmake directory') ----- dirWin32x86 ^'cmake.build.win32x86'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>externalModulesDir (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>externalModulesDir (in category 'cmake directory') ----- externalModulesDir "answer the location in VM bundle, where plugins and rest of dynamic libs will be copied, " self subclassResponsibility! Item was changed: + ----- Method: CPlatformConfigForSqueak>>linkerFlags (in category 'cmake buildType redirects') ----- - ----- Method: CPlatformConfigForSqueak>>linkerFlags (in category 'compiling') ----- linkerFlags - self flag:'tty'. "Does this need to be ported to the redirect design pattern with linkerFlagsBuild, linkerFlagsDebug etc?" - " - linkerFlags - ^#( '-Wl' - '-z' - 'now' - ) - " + "Route this message send to the message appropriate for my buildType " + |d | + d:= SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo copy. + d + at: #build put: [self linkerFlagsBuild]; + at: #buildAssert put: [self linkerFlagsBuildAssert]; + at: #buildAssertITimerHeartbeat put: [self linkerFlagsBuildAssertITimerHeartbeat]; + at:#buildDebug put: [self linkerFlagsBuildDebug]; + at: #buildDebugITimerHeartbeat put: [self linkerFlagsBuildDebugITimerHeartbeat ]; + at: #buildITimerHeartbeat put: [self linkerFlagsBuildITimerHeartbeat]; + at: #buildMultiThreaded put: [self linkerFlagsBuildMultiThreaded]; + at: #buildMultiThreadedAssert put: [self linkerFlagsBuildMultiThreadedAssert]; + at: #buildMultiThreadedDebug put: [self linkerFlagsBuildMultiThreadedDebug ]; + at: #buildNone put:[self linkerFlagsNoBuildType]. + ^(d at: buildType) value. + ! - - self subclassResponsibility! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuild (in category 'cmake buildType redirects') ----- + linkerFlagsBuild + "in + cat usr/src/smalltalk/cogspur64/oscogvm/build.linux64x64/squeak.cog.spur/build/mvm + we want the LDFLAGS line here. + + " + + " + ^#( + '-Wl' + '-z' + 'now' + ) + " + self subclassResponsibility! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildAssert (in category 'cmake buildType redirects') ----- + linkerFlagsBuildAssert + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildAssertITimerHeartbeat (in category 'cmake buildType redirects') ----- + linkerFlagsBuildAssertITimerHeartbeat + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildDebug (in category 'cmake buildType redirects') ----- + linkerFlagsBuildDebug + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildDebugITimerHeartbeat (in category 'cmake buildType redirects') ----- + linkerFlagsBuildDebugITimerHeartbeat + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildITimerHeartbeat (in category 'cmake buildType redirects') ----- + linkerFlagsBuildITimerHeartbeat + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildMultiThreaded (in category 'cmake buildType redirects') ----- + linkerFlagsBuildMultiThreaded + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildMultiThreadedAssert (in category 'cmake buildType redirects') ----- + linkerFlagsBuildMultiThreadedAssert + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsBuildMultiThreadedDebug (in category 'cmake buildType redirects') ----- + linkerFlagsBuildMultiThreadedDebug + ^self linkerFlagsBuild! Item was added: + ----- Method: CPlatformConfigForSqueak>>linkerFlagsNoBuildType (in category 'cmake buildType redirects') ----- + linkerFlagsNoBuildType + "SHOULD NOT GET HERE" + self shouldNotImplement. + + + ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakCogSpur (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakCogSpur (in category 'cmake directory') ----- newspeakCogSpur ^'newspeak.cog.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakCogV3 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakCogV3 (in category 'cmake directory') ----- newspeakCogV3 ^'newspeak.cog.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakSistaSpur (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakSistaSpur (in category 'cmake directory') ----- newspeakSistaSpur ^'newspeak.sista.Spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakSistaV3 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakSistaV3 (in category 'cmake directory') ----- newspeakSistaV3 ^'newspeak.sista.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakStackSpur (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakStackSpur (in category 'cmake directory') ----- newspeakStackSpur ^'newspeak.stack.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>newspeakStackV3 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>newspeakStackV3 (in category 'cmake directory') ----- newspeakStackV3 ^'newspeak.stack.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>nsspur64src (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>nsspur64src (in category 'cmake directory') ----- nsspur64src ^ (self topDir directoryNamed: 'nsspur64src')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>nsspursrc (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>nsspursrc (in category 'cmake directory') ----- nsspursrc ^ (self topDir directoryNamed: 'nsspursrc')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>nsspurstack64src (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>nsspurstack64src (in category 'cmake directory') ----- nsspurstack64src ^ (self topDir directoryNamed: 'nsspurstack64src')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>nsspurstacksrc (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>nsspurstacksrc (in category 'cmake directory') ----- nsspurstacksrc ^ (self topDir directoryNamed: 'nsspurstacksrc')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>oscogvm (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>oscogvm (in category 'cmake directory') ----- oscogvm ^'oscogvm'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>outputDir (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>outputDir (in category 'cmake directory') ----- outputDir "the directory where built binaries will be stored" ^ outputDir ifNil: [ outputDir := (self topDir / self dirOutput / self dirBuildPlatform / self dirBuildLanguageVMMM / (buildType asString)) ] ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>outputDirName (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>outputDirName (in category 'cmake directory') ----- outputDirName ^ 'products'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>platformsDir (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>platformsDir (in category 'cmake directory') ----- platformsDir ^ (self topDir directoryNamed: (self dirPlatforms) ) ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>spur64src (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>spur64src (in category 'cmake directory') ----- spur64src ^ (self topDir directoryNamed: 'spur64src')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>spursistasrc (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>spursistasrc (in category 'cmake directory') ----- spursistasrc ^ (self topDir directoryNamed: 'spursistasrc')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>spursrc (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>spursrc (in category 'cmake directory') ----- spursrc ^ (self topDir directoryNamed: 'spursrc')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>spurstack64src (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>spurstack64src (in category 'cmake directory') ----- spurstack64src ^ (self topDir directoryNamed: 'spurstack64src')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>spurstacksrc (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>spurstacksrc (in category 'cmake directory') ----- spurstacksrc ^ (self topDir directoryNamed: 'spurstacksrc')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakCogSpur (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>squeakCogSpur (in category 'cmake directory') ----- squeakCogSpur ^'squeak.cog.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakCogV3 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>squeakCogV3 (in category 'cmake directory') ----- squeakCogV3 ^'squeak.cog.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakSistaSpur (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>squeakSistaSpur (in category 'cmake directory') ----- squeakSistaSpur ^'squeak.sista.Spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakSistaV3 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>squeakSistaV3 (in category 'cmake directory') ----- squeakSistaV3 ^'squeak.sista.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakStackSpur (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>squeakStackSpur (in category 'cmake directory') ----- squeakStackSpur ^'squeak.stack.spur'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>squeakStackV3 (in category 'cmake directory strings') ----- - ----- Method: CPlatformConfigForSqueak>>squeakStackV3 (in category 'cmake directory') ----- squeakStackV3 ^'squeak.stack.v3'! Item was changed: + ----- Method: CPlatformConfigForSqueak>>src (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>src (in category 'cmake directory') ----- src "where cog lives" ^ (self topDir directoryNamed: 'src')! Item was changed: + ----- Method: CPlatformConfigForSqueak>>srcDir (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>srcDir (in category 'cmake directory') ----- srcDir "pharo legacy naming convention. used in some cmake scripts like 'directories.cmake' topDir=oscogvm dirSource=[nsspur64src | nsspursrc |nsspurstack64src |nsspurstacksrc |spur64src |spursistasrc |spursrc | spurstack64src |spurstacksrc | src |stacksr] Configurations customize this srcDir=oscogvm/dirSource cogDir=oscogvm/src (needed by CMake for access to plugins source in oscogvm/src/plugins) " ^ self dirSource ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>stacksrc (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>stacksrc (in category 'cmake directory') ----- stacksrc ^ (self topDir directoryNamed: 'stacksrc' ) ! Item was changed: + ----- Method: CPlatformConfigForSqueak>>topDir (in category 'cmake directory objects') ----- - ----- Method: CPlatformConfigForSqueak>>topDir (in category 'cmake directory') ----- topDir " topDir=oscogvm dirSource=[nsspur64src | nsspursrc |nsspurstack64src |nsspurstacksrc |spur64src |spursistasrc |spursrc | spurstack64src |spurstacksrc | src |stacksr] Configurations customize this srcDir=oscogvm/dirSource cogDir=oscogvm/src (needed by CMake for access to plugins source in oscogvm/src/plugins) " ^ topDir ifNil: [ topDir := FileDirectory default directoryNamed: self oscogvm ] ! Item was added: + ----- Method: Linux32x86Config>>linkerFlagsBuild (in category 'cmake buildType redirects') ----- + linkerFlagsBuild + ^#( '-Wl' + '-z' + 'now' + ) + ! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>cmakeAddDefinitionsBuild (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuild - |c d o| - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuild') - ] . - c := self compilerFlags asOrderedCollection. - d := self compilerDefinitions asOrderedCollection. - o:= OrderedCollection new. - o addAllLast: c; addAllLast: d. - templates - addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). "see my self flag below" - ! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>cmakeAddDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildAssert - |c d o| - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuildAssert') - ] . - c := self compilerFlagsAssert asOrderedCollection. - d := self compilerDefinitionsAssert asOrderedCollection. - o:= OrderedCollection new. - o addAllLast: c; addAllLast: d. - templates - addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitionsAssert asOrderedCollection)). "see my self flag below" - ! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>cmakeCFlagsBuild (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuild - |cflags| - self flag:'tty'. "#build should have -O2" - cflags:= String streamContents: [:stream | (self compilerFlags) asStringOn: stream delimiter: ' ' ]. - cflags:='"', cflags, '"'. - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeCFlagsBuild') - ] . - templates - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS' value: '${CMAKE_C_FLAGS} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ',cflags); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS' value: '${CMAKE_CXX_FLAGS} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ', cflags ). - - (enabledebugmessages) "take a peek at em" - ifTrue:[ templates - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}'); - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_DEBUG=${CMAKE_CXX_FLAGS_DEBUG}'); - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_RELEASE=${CMAKE_CXX_FLAGS_RELEASE}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS=${CMAKE_C_FLAGS}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_DEBUG=${CMAKE_C_FLAGS_DEBUG}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_RELEASE=${CMAKE_C_FLAGS_RELEASE}') - ] . - - - ! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>cmakeSetSourceFilesPropertiesBuild (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuild - |cflags| - cflags:=String streamContents: [:stream | (self compilerFlags) asStringOn: stream - delimiter: ' ' ]. - cflags := '"' , cflags , '"'. - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeSetSourceFilesPropertiesBuild') - ] . - templates - addLast:((CMakeSetSourceFilesProperties new) - files: (OrderedCollection with: '${srcVMDir}/cogit.c') - propertiesandvalues:{'COMPILE_FLAGS' . cflags}); - addLast:((CMakeSetSourceFilesProperties new) - files: (OrderedCollection with: '${targetPlatform}/vm/sqUnixHeartbeat.c') - propertiesandvalues:{'COMPILE_FLAGS' . cflags}).! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>compilerDefinitions (in category 'compiling') ----- - compilerDefinitions - self deprecated: 'Legacy method from pharo approach. We need different definitions for each buildType'. - ^#( - '-DNDEBUG' - '-DDEBUGVM=0' - ' -DLSB_FIRST=1' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - " '-DUSE_GLOBAL_STRUCT=0'" - '-DCOGMTVM=0') - ! Item was added: + ----- Method: Linux32x86SqueakCogV3Config>>compilerDefinitionsBuild (in category 'compiling') ----- + compilerDefinitionsBuild + ^#( + '-DNDEBUG' + '-DDEBUGVM=0' + ' -DLSB_FIRST=1' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + " '-DUSE_GLOBAL_STRUCT=0'" + '-DCOGMTVM=0') + ! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>compilerFlags (in category 'compiling') ----- - compilerFlags - ^#("'-Wall'" - '-w' - '-m32' - '-msse2' - " '-g3' extra debugging info" - '-O1' - " '-fno-caller-saves' - '-fno-tree-pre'") - ! Item was added: + ----- Method: Linux32x86SqueakCogV3Config>>compilerFlagsBuild (in category 'cmake buildType redirects') ----- + compilerFlagsBuild + ^#("'-Wall'" + '-w' + '-m32' + '-msse2' + " '-g3' extra debugging info" + '-O1' + " '-fno-caller-saves' + '-fno-tree-pre'") + ! Item was changed: ----- Method: Linux32x86SqueakCogV3Config>>excludeFromBuild (in category 'cmake') ----- excludeFromBuild + ^true "build this configuration" - ^false "build this configuration" " ^true" ! Item was removed: - ----- Method: Linux32x86SqueakCogV3Config>>linkerFlags (in category 'compiling') ----- - linkerFlags - ^#( '-Wl' - '-z' - 'now' - ) - ! Item was added: + ----- Method: Linux32x86SqueakCogV3Config>>setPlatformSourcesBuild: (in category 'cmake buildType redirects') ----- + setPlatformSourcesBuild:aMaker + |mysubset iwantonly| + + "trim the platformSources collection .c files I want. for this OS/platform" + self flag:'tty. go through the Cog svn tree and see exactly what files should be included here.'. + iwantonly := #( + 'aio.c' + 'debug.c' + 'osExports.c' + 'sqUnixCharConv.c' + 'sqUnixExternalPrims.c' + 'sqUnixHeartbeat.c' + 'sqUnixMain.c' + 'sqUnixMemory.c' + 'sqUnixThreads.c' + 'sqUnixVMProfile.c' + ). + mysubset := platformSources select: [:c | 0 < (iwantonly occurrencesOf: c)]. + platformSources := mysubset. + super setPlatformSourcesBuild:aMaker! Item was added: + ----- Method: Linux64x64Config>>externalLibraries (in category 'compiling') ----- + externalLibraries + ^#( + + 'uuid' "" + 'ssl' "" + 'crypto' "" + 'm' "C math library" + 'dl' "dynamic linking library" + 'pthread' "POSIX threads library" + 'SM' "session management library for X11" + 'ICE' "ICE is the Inter Client Exchange protocol, part of X11" + 'GL' "libGL implements the GLX interface as well as the main OpenGL API entrypoints" + 'X11' + 'nsl' "network services library" + ) + ! Item was added: + ----- Method: Linux64x64Config>>linkerFlagsBuild (in category 'cmake buildType redirects') ----- + linkerFlagsBuild + ^#( '-Wl' + '-z' + 'now' + ) + ! Item was added: + Linux64x64Config subclass: #Linux64x64SqueakCogSpurConfig + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'CMakeVMMakerSqueak-Linux64x64'! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig class>>isAbstractBaseClass (in category 'accessing') ----- + isAbstractBaseClass + ^false + ! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>availableBuildTypes (in category 'cmake') ----- + availableBuildTypes + "2.14.12.09 only buildType implemented is #build so I remove #build from the below OrderedCollection." + ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildAssert #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>cogitClass (in category 'source generation') ----- + cogitClass + ^ StackToRegisterMappingCogit + ! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>compilerDefinitionsBuild (in category 'source generation') ----- + compilerDefinitionsBuild + "cat oscogvm/build.linux64x64/squeak.cog.spur/build/mvm and get values from there" + ^#( + '-DNDEBUG' + '-DDEBUGVM=0' + ' -DLSB_FIRST=1' + '-D_GNU_SOURCE' + '-DCOGMTVM=0') . + ! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>compilerFlagsBuild (in category 'source generation') ----- + compilerFlagsBuild + "cat oscogvm/build.linux64x64/squeak.cog.spur/build/mvm and get values from there" + self flag:'tty: O1 or O2 depends on gcc version. How can CMake set this for us?'. + ^#('-g' + '-O1' + '-msse2' + '-fwrapv' + '-m64') + + + " ^#('-g' + '-O2' + '-m64') " + ! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>dirBuildLanguageVMMM (in category 'cmake') ----- + dirBuildLanguageVMMM + ^self squeakCogSpur! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>dirSource (in category 'cmake directory objects') ----- + dirSource + ^self spursrc! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>excludeFromBuild (in category 'cmake') ----- + excludeFromBuild + "over-ride to exclude yourself from a build or not" + ^false! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>externalLibsBuild (in category 'cmake buildType redirects') ----- + externalLibsBuild + ^self externalLibraries asOrderedCollection. + ! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>interpreterClass (in category 'source generation') ----- + interpreterClass + ^ CoInterpreter! Item was added: + ----- Method: Linux64x64SqueakCogSpurConfig>>setPlatformSourcesBuild: (in category 'cmake buildType redirects') ----- + setPlatformSourcesBuild:aMaker + |mysubset iwantonly| + + "trim the platformSources collection .c files I want. for this OS/platform" + self flag:'tty. go through the Cog svn tree and see exactly what files should be included here. debug.c feels wrong'. + iwantonly := #( + 'aio.c' + 'debug.c' + 'osExports.c' + 'sqUnixCharConv.c' + 'sqUnixExternalPrims.c' + 'sqUnixHeartbeat.c' + 'sqUnixMain.c' + 'sqUnixMemory.c' + 'sqUnixSpurMemory.c' + 'sqUnixThreads.c' + 'sqUnixVMProfile.c' + ). + mysubset := platformSources select: [:c | 0 < (iwantonly occurrencesOf: c)]. + platformSources := mysubset. + super setPlatformSourcesBuild:aMaker! Item was added: + ----- Method: Linux64x86w32BitConfigUsrLib>>linkerFlagsBuild (in category 'cmake buildType redirects') ----- + linkerFlagsBuild + ^#( '-Wl' + '-z' + 'now' + ) + ! Item was added: + ----- Method: Linux64x86w32BitConfigUsrLib32>>linkerFlagsBuild (in category 'cmake buildType redirects') ----- + linkerFlagsBuild + ^#( '-Wl' + '-z' + 'now' + ) + ! Item was changed: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>availableBuildTypes (in category 'cmake') ----- - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>availableBuildTypes (in category 'as yet unclassified') ----- availableBuildTypes "2.14.12.09 only buildType implemented is #build so I remove #build from the below OrderedCollection." ^SqueakCMakeVMMakerAbstractBuilder default allBuildTypes copyWithoutAll: #( #buildAssertITimerHeartbeat #buildDebug #buildDebugITimerHeartbeat #buildITimerHeartbeat #buildMultiThreaded #buildMultiThreadedAssert #buildMultiThreadedDebug #buildNone)! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeAddDefinitionsBuild (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuild - |definitions| - definitions:=#( - '-DNDEBUG' - '-DDEBUGVM=0' - ' -DLSB_FIRST=1' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - " '-DUSE_GLOBAL_STRUCT=0'" - '-DCOGMTVM=0') . - - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuild') - ] . - templates - addLast:((CMakeAddDefinitions new) definitions: definitions). - - " templates - addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). <--this was the old pharo deprecated legacy code approach that is unsuitable for the multiple buildTypes each Configuration must support" - - ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeAddDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildAssert - |definitions| - "copy-n-paste from /build.linux32x86/squeak.cog.v3/build.assert/mvm file" - definitions:=#( - '-DDEBUGVM=0' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - '-DCOGMTVM=0' - ) . - - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuildAssert') - ] . - templates - addLast:((CMakeAddDefinitions new) definitions: definitions). - - " templates - addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). <--this was the old pharo deprecated legacy code approach that is unsuitable for the multiple buildTypes each Configuration must support" - - ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeCFlagsBuild (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuild - |cflags| - self flag:'tty'. "#build should have -O2" - cflags:= String streamContents: [:stream | (self compilerFlags) asStringOn: stream delimiter: ' ' ]. - cflags:='"', cflags, '"'. - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeCFlagsBuild') - ] . - templates - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS' value: '${CMAKE_C_FLAGS} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ',cflags); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS' value: '${CMAKE_CXX_FLAGS} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ', cflags ). - - (enabledebugmessages) "take a peek at em" - ifTrue:[ templates - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}'); - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_DEBUG=${CMAKE_CXX_FLAGS_DEBUG}'); - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_RELEASE=${CMAKE_CXX_FLAGS_RELEASE}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS=${CMAKE_C_FLAGS}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_DEBUG=${CMAKE_C_FLAGS_DEBUG}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_RELEASE=${CMAKE_C_FLAGS_RELEASE}') - ] . - - - ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>cmakeSetSourceFilesPropertiesBuild (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuild - |cflags| - cflags:=String streamContents: [:stream | (self compilerFlags) asStringOn: stream - delimiter: ' ' ]. - cflags := '"' , cflags , '"'. - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeSetSourceFilesPropertiesBuild') - ] . - templates - addLast:((CMakeSetSourceFilesProperties new) - files: (OrderedCollection with: '${srcVMDir}/cogit.c') - propertiesandvalues:{'COMPILE_FLAGS' . cflags}); - addLast:((CMakeSetSourceFilesProperties new) - files: (OrderedCollection with: '${targetPlatform}/vm/sqUnixHeartbeat.c') - propertiesandvalues:{'COMPILE_FLAGS' . cflags}).! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerDefinitions (in category 'compiling') ----- - compilerDefinitions - - self deprecated: 'Legacy method from pharo approach. We need different definitions for each buildType'. - - ^#( - '-DNDEBUG' - '-DDEBUGVM=0' - ' -DLSB_FIRST=1' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - " '-DUSE_GLOBAL_STRUCT=0'" - '-DCOGMTVM=0') - ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerDefinitionsBuild (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuild + ^#( + '-DNDEBUG' + '-DDEBUGVM=0' + ' -DLSB_FIRST=1' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + " '-DUSE_GLOBAL_STRUCT=0'" + '-DCOGMTVM=0') . + + ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuildAssert + ^#( + '-DDEBUGVM=0' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + '-DCOGMTVM=0' + ) . + + ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerFlags (in category 'compiling') ----- - compilerFlags - ^#("'-Wall'" - '-w' - '-m32' - '-msse2' - " '-g3' extra debugging info" - '-O1' - " '-fno-caller-saves' - '-fno-tree-pre'") - ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>compilerFlagsBuild (in category 'cmake buildType redirects') ----- + compilerFlagsBuild + ^#("'-Wall'" + '-g' + '-m32' + '-msse2' + '-O1' + '-fwrapv' + ) + ! Item was changed: ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>dirSource (in category 'cmake') ----- dirSource + ^self spur64src! - ^self spursrc! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>linkerFlags (in category 'compiling') ----- - linkerFlags - ^#( '-Wl' - '-z' - 'now' - ) - ! Item was changed: ----- Method: Linux64x86w32BitSqueakCogSpurConfig>>setPlatformSourcesBuild: (in category 'cmake buildType redirects') ----- setPlatformSourcesBuild:aMaker |mysubset iwantonly| "trim the platformSources collection .c files I want. for this OS/platform" self flag:'tty. go through the Cog svn tree and see exactly what files should be included here. debug.c feels wrong'. iwantonly := #( 'aio.c' 'debug.c' 'osExports.c' 'sqUnixCharConv.c' 'sqUnixExternalPrims.c' 'sqUnixHeartbeat.c' 'sqUnixMain.c' 'sqUnixMemory.c' 'sqUnixSpurMemory.c' 'sqUnixThreads.c' 'sqUnixVMProfile.c' ). + mysubset := platformSources select: [:c | 0 < (iwantonly occurrencesOf: c)]. platformSources := mysubset. super setPlatformSourcesBuild:aMaker! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>cmakeAddDefinitionsBuild (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuild - |definitions| - definitions:=#( - '-DNDEBUG' - '-DDEBUGVM=0' - ' -DLSB_FIRST=1' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - " '-DUSE_GLOBAL_STRUCT=0'" - '-DCOGMTVM=0') . - - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuild') - ] . - templates - addLast:((CMakeAddDefinitions new) definitions: definitions). - - " templates - addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). <--this was the old pharo deprecated legacy code approach that is unsuitable for the multiple buildTypes each Configuration must support" - - ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>cmakeAddDefinitionsBuildAssert (in category 'cmake buildType redirects') ----- - cmakeAddDefinitionsBuildAssert - |definitions| - "copy-n-paste from /build.linux32x86/squeak.cog.v3/build.assert/mvm file" - definitions:=#( - '-DDEBUGVM=0' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - '-DCOGMTVM=0' - ) . - - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitionsBuildAssert') - ] . - templates - addLast:((CMakeAddDefinitions new) definitions: definitions). - - " templates - addLast:((CMakeAddDefinitions new) definitions: (self compilerDefinitions asOrderedCollection)). <--this was the old pharo deprecated legacy code approach that is unsuitable for the multiple buildTypes each Configuration must support" - - ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>cmakeCFlagsBuild (in category 'cmake buildType redirects') ----- - cmakeCFlagsBuild - |cflags| - self flag:'tty'. "#build should have -O2" - cflags:= String streamContents: [:stream | (self compilerFlags) asStringOn: stream delimiter: ' ' ]. - cflags:='"', cflags, '"'. - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeCFlagsBuild') - ] . - templates - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS' value: '${CMAKE_C_FLAGS} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ',cflags); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS' value: '${CMAKE_CXX_FLAGS} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); - addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ', cflags ). - - (enabledebugmessages) "take a peek at em" - ifTrue:[ templates - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}'); - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_DEBUG=${CMAKE_CXX_FLAGS_DEBUG}'); - addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_RELEASE=${CMAKE_CXX_FLAGS_RELEASE}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS=${CMAKE_C_FLAGS}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_DEBUG=${CMAKE_C_FLAGS_DEBUG}'); - addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_RELEASE=${CMAKE_C_FLAGS_RELEASE}') - ] . - - - ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>cmakeSetSourceFilesPropertiesBuild (in category 'cmake buildType redirects') ----- - cmakeSetSourceFilesPropertiesBuild - |cflags| - cflags:=String streamContents: [:stream | (self compilerFlags) asStringOn: stream - delimiter: ' ' ]. - cflags := '"' , cflags , '"'. - (enabledebugmessages) - ifTrue:[ templates - addLast:((CMakeMessage new) message: (self class name) , 'cmakeSetSourceFilesPropertiesBuild') - ] . - templates - addLast:((CMakeSetSourceFilesProperties new) - files: (OrderedCollection with: '${srcVMDir}/cogit.c') - propertiesandvalues:{'COMPILE_FLAGS' . cflags}); - addLast:((CMakeSetSourceFilesProperties new) - files: (OrderedCollection with: '${targetPlatform}/vm/sqUnixHeartbeat.c') - propertiesandvalues:{'COMPILE_FLAGS' . cflags}).! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>compilerDefinitions (in category 'compiling') ----- - compilerDefinitions - - self deprecated: 'Legacy method from pharo approach. We need different definitions for each buildType'. - - ^#( - '-DNDEBUG' - '-DDEBUGVM=0' - ' -DLSB_FIRST=1' - '-D_GNU_SOURCE' - '-D_FILE_OFFSET_BITS=64' - " '-DUSE_GLOBAL_STRUCT=0'" - '-DCOGMTVM=0') - ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogV3Config>>compilerDefinitionsBuild (in category 'cmake buildType redirects') ----- + compilerDefinitionsBuild + ^#( + '-DNDEBUG' + '-DDEBUGVM=0' + ' -DLSB_FIRST=1' + '-D_GNU_SOURCE' + '-D_FILE_OFFSET_BITS=64' + " '-DUSE_GLOBAL_STRUCT=0'" + '-DCOGMTVM=0') . + ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>compilerFlags (in category 'compiling') ----- - compilerFlags - ^#("'-Wall'" - '-w' - '-m32' - '-msse2' - " '-g3' extra debugging info" - '-O1' - " '-fno-caller-saves' - '-fno-tree-pre'") - ! Item was added: + ----- Method: Linux64x86w32BitSqueakCogV3Config>>compilerFlagsBuild (in category 'cmake buildType redirects') ----- + compilerFlagsBuild + ^#("'-Wall'" + '-w' + '-m32' + '-msse2' + " '-g3' extra debugging info" + '-O1' + " '-fno-caller-saves' + '-fno-tree-pre'") + ! Item was removed: - ----- Method: Linux64x86w32BitSqueakCogV3Config>>linkerFlags (in category 'compiling') ----- - linkerFlags - ^#( '-Wl' - '-z' - 'now' - ) - ! Item was removed: - ----- Method: SqueakCMakeVMMakerAbstractBuilder class>>buildDirectory (in category 'queries') ----- - buildDirectory - "buildDirectory is user friendly term. dirBuildPlatform is internal naming convention. " - ^self dirBuildPlatform - ! Item was added: + ----- Method: SqueakCMakeVMMakerAbstractBuilder class>>buildDirectoryFor: (in category 'queries') ----- + buildDirectoryFor: aSymbol + default ifNil:[default:= self new]. + ^default buildDirectoryFor: aSymbol! Item was added: + ----- Method: SqueakCMakeVMMakerAbstractBuilder class>>sourceDirectoryFor: (in category 'queries') ----- + sourceDirectoryFor: aSymbol + default ifNil:[default:= self new]. + ^default sourceDirectoryFor: aSymbol! Item was added: + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>buildDirectoryFor: (in category 'queries') ----- + buildDirectoryFor: aSymbol + "answer a subset of buildTypeAndDirectoryInfo based on the buildTypes the configuration supports " + [ + ((Smalltalk at: aSymbol) category) = (self configurationsCategory) "verify the class is handled by this concrete builder" + ifTrue:[^self buildDirectoryFor: aSymbol inCategory: ((Smalltalk at: aSymbol) category).] "if so, go get its info" + ifFalse:[^self userErrorInvalidTarget: aSymbol] + ] ifError:[^'buildDirectoryFor: ''', aSymbol , ''' not found' ]. + ^nil.! Item was added: + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>buildDirectoryFor:inCategory: (in category 'queries') ----- + buildDirectoryFor: aSymbol inCategory: aCategoryName + |info | + "extract the CMakeVMakerConfigurationInfo object for a configuration and return the sourceDirectory ." + info:=(self configurationDictionary:aCategoryName) at: aSymbol ifAbsent:[^SqueakCMakeVMMakerAbstractBuilder default userErrorNoSource:aSymbol]. + ^info dirBuildPlatform + + ! Item was added: + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>sourceDirectoryFor: (in category 'queries') ----- + sourceDirectoryFor: aSymbol + "answer a subset of buildTypeAndDirectoryInfo based on the buildTypes the configuration supports " + [ + ((Smalltalk at: aSymbol) category) = (self configurationsCategory) "verify the class is handled by this concrete builder" + ifTrue:[^self sourceDirectoryFor: aSymbol inCategory: ((Smalltalk at: aSymbol) category).] "if so, go get its info" + ifFalse:[^self userErrorInvalidTarget: aSymbol] + ] ifError:[^'sourceDirectoryFor: ''', aSymbol , ''' not found' ]. + ^nil.! Item was added: + ----- Method: SqueakCMakeVMMakerAbstractBuilder>>sourceDirectoryFor:inCategory: (in category 'queries') ----- + sourceDirectoryFor: aSymbol inCategory: aCategoryName + |info | + "extract the CMakeVMakerConfigurationInfo object for a configuration and return the sourceDirectory ." + info:=(self configurationDictionary:aCategoryName) at: aSymbol ifAbsent:[^SqueakCMakeVMMakerAbstractBuilder default userErrorNoSource:aSymbol]. + ^info dirSource + + ! Item was removed: - ----- Method: SqueakMacintoshConfig>>compilerFlags (in category 'compiling') ----- - compilerFlags - "Macintosh Common compiler flags" - self flag:'tty'. "cut-n-paste from representative pharo macOS configs" - ^ { - '-fmessage-length=0'. - '-Wno-trigraphs'. - '-fpascal-strings'. - '-fasm-blocks'. - '-mmacosx-version-min=10.5' } - ! Item was added: + ----- Method: SqueakMacintoshConfig>>compilerFlagsBuild (in category 'cmake buildType redirects') ----- + compilerFlagsBuild + "Macintosh Common compiler flags" + self flag:'tty'. "cut-n-paste from representative pharo macOS configs" + ^ { + '-fmessage-length=0'. + '-Wno-trigraphs'. + '-fpascal-strings'. + '-fasm-blocks'. + '-mmacosx-version-min=10.5' } + ! Item was added: + ----- Method: SqueakUnixConfig>>cmakeAddDefinitions (in category 'cmake buildType redirects') ----- + cmakeAddDefinitions + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeAddDefinitions') + ] . + templates + addLast:((CMakeAddDefinitions new) definitions: self compilerDefinitions). "this reroutes to self compilerDefinitionsBuild . This suggests that the cmakeAddDefinitionsBuild is redundant because compileDefinitiosn will rerroute based on buildType" + + ! Item was added: + ----- Method: SqueakUnixConfig>>cmakeCFlags (in category 'cmake buildType redirects') ----- + cmakeCFlags + |cflags| + cflags:= String streamContents: [:stream | (self compilerFlags) asStringOn: stream delimiter: ' ' ]. "buildType redirect to compilerFlagsBuildType" + cflags:='"', cflags, '"'. + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeCFlags') + ] . + templates + addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS' value: '${CMAKE_C_FLAGS} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_C_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ',cflags); + addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS' value: '${CMAKE_CXX_FLAGS} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_RELEASE' value: '${CMAKE_CXX_FLAGS_RELEASE} ', cflags ); + addLast:((CMakeSet new) variable:'CMAKE_CXX_FLAGS_DEBUG' value: '${CMAKE_CXX_FLAGS_DEBUG} ', cflags ). + + (enabledebugmessages) "take a peek at em" + ifTrue:[ templates + addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}'); + addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_DEBUG=${CMAKE_CXX_FLAGS_DEBUG}'); + addLast:((CMakeMessage new) message: 'CMAKE_CXX_FLAGS_RELEASE=${CMAKE_CXX_FLAGS_RELEASE}'); + addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS=${CMAKE_C_FLAGS}'); + addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_DEBUG=${CMAKE_C_FLAGS_DEBUG}'); + addLast:((CMakeMessage new) message: 'CMAKE_C_FLAGS_RELEASE=${CMAKE_C_FLAGS_RELEASE}') + ] . + + + ! Item was added: + ----- Method: SqueakUnixConfig>>cmakeSetSourceFilesProperties (in category 'cmake buildType redirects') ----- + cmakeSetSourceFilesProperties + |cflags| + self flag:'tty: this needs rethinking. It should be a standard template that has different elements injected based on buildType. This should not be a redirectPattern method'. + cflags:=String streamContents: [:stream | (self compilerFlags) asStringOn: stream "compilerFlags redirects based on buildType" + delimiter: ' ' ]. + cflags := '"' , cflags , '"'. + (enabledebugmessages) + ifTrue:[ templates + addLast:((CMakeMessage new) message: (self class name) , 'cmakeSetSourceFilesPoperties') + ] . + templates + addLast:((CMakeSetSourceFilesProperties new) "this should iterate over a set of sourceFiles that redirects on buildTypes instead of being hard-coded. " + files: (OrderedCollection with: '${srcVMDir}/cogit.c') + propertiesandvalues:{'COMPILE_FLAGS' . cflags}); + addLast:((CMakeSetSourceFilesProperties new) + files: (OrderedCollection with: '${targetPlatform}/vm/sqUnixHeartbeat.c') + propertiesandvalues:{'COMPILE_FLAGS' . cflags}).! Item was removed: - ----- Method: SqueakWindowsConfig>>compilerFlags (in category 'compiling') ----- - compilerFlags - "omit -ggdb2 to prevent generating debug info" - "Some flags explanation: - - STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). - DALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, - then FFI module needs to adjust that. It is NOT the case of mingw. - For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.html - " - ^ { - '-march=pentium4'. - '-mwindows'. - '-msse2'. - '-mthreads'. - '-mwin32'. - '-mno-rtd'. - '-mms-bitfields'. - '-mno-accumulate-outgoing-args ', self winVer }! Item was added: + ----- Method: SqueakWindowsConfig>>compilerFlagsBuild (in category 'cmake buildType redirects') ----- + compilerFlagsBuild + "omit -ggdb2 to prevent generating debug info" + "Some flags explanation: + + STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). + DALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, + then FFI module needs to adjust that. It is NOT the case of mingw. + For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.html + " + ^ { + '-march=pentium4'. + '-mwindows'. + '-msse2'. + '-mthreads'. + '-mwin32'. + '-mno-rtd'. + '-mms-bitfields'. + '-mno-accumulate-outgoing-args ', self winVer }! From btc at openinworld.com Mon Jun 20 03:26:43 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 20 03:27:06 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: Whoops, correction down below... On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman wrote: > On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge wrote: >> >> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works > > I found these Atlassian tutorials really nice (and often refer to them)... > * https://www.atlassian.com/git/tutorials > > Github Help "Fork a repo" provides a scratch repo for you to practice > on without fear. > * https://help.github.com/ > > git - the simple guide (I only just bumped into this, looks good) > * http://rogerdudler.github.io/git-guide/ > >> and need something in style of ?see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m?boots!' and so on. > > Okay Spot. Here is a proposed recipe. This is for those having having > write access to the official repository and cloned that to work in. > I'll follow up with an adaption for forked repos tomorrow. > > 1. Go to https://github.com/OpenSmalltalk/vm > > 2. Click the green button. > (If you've already set up your SSH keys, click "Use SSH".) > then copy the url to the clipboard. > > 3. Clone to your local machine > $ git clone #paste url from the clipboard here > $ cd vm !> $ git remove -v sorry, this should have been $ git remote -v > origin git@github.com:OpenSmalltalk/vm.git (fetch) > origin git@github.com:OpenSmalltalk/vm.git (push) > or... > origin https://github.com/OpenSmalltalk/vm.git (fetch) > origin https://github.com/OpenSmalltalk/vm.git (push) > ...depending on ssh or https clone respectively > > 4. Create a branch to work on... > $ git fetch #updates all branches to latest > $ git checkout -b SomeBug Cog > > 5. Edit, compile, test cycle. Commit often along the way. > * make required changes > $ git stage -u > $ git diff ; git diff HEAD > $ git commit -m "SomeBug - part way there" > Repeat as necessary > > 6. Ready to submit. Clean up *local* history (since we committed quite often) > $ git rebase -i # Squash inconsequential commits. Rebase is > okay before publishing. > Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ > https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview > > 7. Catch up to official Cog branch > $ git fetch # updates origin/* > $ git log HEAD..origin/Cog # review other updates > $ git diff origin/Cog # review other updates > Depending on whether the final history should be linear (more like SVN??) > $ git rebase origin/Cog # rebase okay since not yet published > or show the branching... > $ get merge origin/Cog > ...might depend on whether its a small fix or a larger feature added. > > 8. Submit for review > $ git push # to server > You will see... > fatal: The current branch SomeBug has no upstream branch. > which is because the SomeBug branch only exists locally, not on the > github server. The following creates the branch on the "origin" server > and sets things so subsequently this branch only requires "git push". > $ git push --set-upstream origin SomeBug > * On github, from the pulldown button, select your SomeBug branch. > * Click button. For more detail refer... > https://help.github.com/articles/using-pull-requests/ > > (In the meantime, work on some other branch) > > 7. Reviewers can download PR to test locally as described here... > https://help.github.com/articles/checking-out-pull-requests-locally/ > (though I've not done that since I've not been on the receiving side > of a pull request before) > > 8. Respond to reviewer comments. Edit, compile, test, resubmit. > $ git checkout SomeBug > * make required changes > $ git stage -u > $ git commit -m "changed per feedback " > $ git push # Pull request auto updated > (Repeat as required) > > 9. Pull request acceptable. Optionally (and some policy discussion > required) squash changes from review period. > $ git rebase -i > $ git push -f > Note this does rewrite the history of the published SomeBug branch, > but presumably the branch is thrown away after integration so no real > foul. But forcing pushing may be risk for accidentally doing it to > the Cog or master branches. (btw, has the force protection on those > two branches been tested?) > > 10. On github, integrator accepts pull request. > > 11. Delete branch. From bera.clement at gmail.com Mon Jun 20 07:17:46 2016 From: bera.clement at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Bera?=) Date: Mon Jun 20 07:18:09 2016 Subject: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch In-Reply-To: <1FB5ED99-0B8D-4362-A212-BE311FD2361E@inria.fr> References: <1FB5ED99-0B8D-4362-A212-BE311FD2361E@inria.fr> Message-ID: Hi, I think there was a misunderstanding Tim. The idea is not necessarily to let developers write code with this many arguments, the IDE could actually enforces the programmer not to write methods with too many arguments. It's really about non programmers, like code generating tools such as SmaCC. In Java for example, the "Clean code" code convention limits the number of arguments per method to 3, the "Code complete" code convention limits it to 7, but Java can compile methods up to 255 arguments for code generators. If you want to limit the number of arguments the programmer can write, enforce it in the IDE according to your code convention. *Please talk about the maximum number of arguments a developer can write in another thread, this is non related to the implementation discussed here.* As Jan said, there are already too many limitations in Smalltalk to write proper code generators. We've worked on those limitations already: - the SistaV1 bytecode set will go to production in Pharo 6 (likely Squeak at some point too) and it removes an important part of the limitations (jump sizes up to 65k instructions instead of 1024, ...). - Spur removed other limitations (methods with up to 32k literals instead of 255, behaviors with up to 65k inst vars instead of 255). The important limitations remaining are the max frame size (56), which in practice limits the number of temps to around 55, whereas we could have 64 temps or more, and the number of arguments of methods and blocks. This scheme is about solving those problems. There are 0.5% of methods using a large frame so we could grow from 56 to 128 or 256 without any significant problems. For arguments bytecode calling convention looks so much simpler than VM support. On Mon, Jun 20, 2016 at 8:30 AM, Marcus Denker wrote: > > > On 19 Jun 2016, at 11:35, Tudor Girba wrote: > > > > Hi, > > > > Does anyone want to pick this up on the Pharo image side? > > > > I took a brief look at this and while playing I noticed that the errors > when we send more than 15 arguments seem a bit strange. Take a look at this > snippet: > > http://ws.stfx.eu/958BXP5GR136 > > (you can paste it in Spotter to get the playground) > > > > In summary: > > - If we compile a method with a signature containing more than 15 > arguments we get: > > "SyntaxErrorNotification: Too many arguments??. > > This is good. > > > > - If we compile a method with a message send containing between 16-31 > arguments we get: > > "'InMidstOfFileinNotification??. > > Ok-ish. > > > > - If we compile a method with a message send containing more than 31 > arguments we get: > > "'Error: genSend:numArgs: numArgs index 32 is out of range 0 to > 31?" > > This is wrong. > > > > > > Did I misunderstand something? > > > > The VM does not support it, and as nobody is using it, the error messages > are not that perfect. > (to have them nicer, someone would have seen it and be bothered to fix it?) > > What Clement proposes is to implement support for more than 15 arguments > in the compiler. > (which means that instead of error messages, it would compile, with the > idea as he described > in the mail). > > Marcus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/665afdee/attachment.htm From norbert at hartl.name Mon Jun 20 07:53:31 2016 From: norbert at hartl.name (Norbert Hartl) Date: Mon Jun 20 07:53:27 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: > Am 19.06.2016 um 02:01 schrieb Eliot Miranda : > > Hi All, > > fixing callbacks on x64 and so too lazy/focussed elsewhere to check whether I should be pushing after each commit. What is the right process for uploading changes to OpenSmalltalk/vm? > _,,,^..^,,,_ > best, Eliot A commit is associated with a comment. So commits should be rather small and describing the change. Most of the time there are some changes/commits that only make sense when being together. This would be the view from the build server or from the process of having buildable artifacts all the time. So you can see it as freedom to have a commit that breaks the software which can be build after 5 more commits. So no problem for the world if you push 5 commits at once. Hope that helps, Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/901ff7f7/attachment.htm From holger at freyther.de Mon Jun 20 08:24:02 2016 From: holger at freyther.de (Holger Freyther) Date: Mon Jun 20 08:24:05 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: > On 20 Jun 2016, at 09:53, Norbert Hartl wrote: > > > > A commit is associated with a comment. So commits should be rather small and describing the change. Most of the time there are some changes/commits that only make sense when being together. This would be the view from the build server or from the process of having buildable artifacts all the time. So you can see it as freedom to have a commit that breaks the software which can be build after 5 more commits. So no problem for the world if you push 5 commits at once. This approach breaks tools like git bisect. If a user has something easy/quick to reproduce and a "good" version and "bad" one, he/she can identify the first broken commit almost automatically. If commits are small then it is quite easy for the maintainer to identify the issue and resolve it. Projects like Linux have the policy that each single commit needs to compile and for my GPRS/EDGE PCU[1] we have the same policy and I can point to a recent example of git bisect used by a user[2]. As a maintainer this reduces the work I have to do. In the context of spur there is a significant performance regression of our TCAP benchmark from one spur version to another and with git bisect I could do: git bisect start git bisect good git bisect bad and then commits from good to bad will be picked and all I need to do is: make bench and then decide to mark this commit as: git bisect bad git bisect good and eventually end with the first bad commit (or none if I track noise) It is obviously up to the maintainers if they want to support git bisect but thanks to git it is not really a burden. One can experiment with temporary branches and then rebase to a final and working patchset. With later git versions can be easily automated as well. git rebase -i --execute "./compile_and_test_all.sh" origin/master close the editor..and git starts compiling all your intermediate commits and stops if they fail kind regards holger [1] A GSM component that converts a LLC frame to smaller pieces. Decides on the coding scheme (error correction bits vs. data), schedules resources across several handsets. [2] http://lists.osmocom.org/pipermail/openbsc/2016-May/009139.html From timfelgentreff at gmail.com Mon Jun 20 09:55:13 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Mon Jun 20 09:55:39 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: I've pushed a CONTRIBUTING.md to the repository that we can iterate over and discuss. If you go to https://github.com/OpenSmalltalk/vm/commit/5052e307fda0369f04550966fcfdf0a372aeaf39 you can leave comments inline or at the end. On 19 June 2016 at 02:01, Eliot Miranda wrote: > > Hi All, > > fixing callbacks on x64 and so too lazy/focussed elsewhere to check whether I should be pushing after each commit. What is the right process for uploading changes to OpenSmalltalk/vm? > _,,,^..^,,,_ > best, Eliot > From commits at source.squeak.org Mon Jun 20 10:47:28 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Jun 20 10:47:28 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.129.mcz Message-ID: Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.129.mcz ==================== Summary ==================== Name: CMakeVMMakerSqueak-tty.129 Author: tty Time: 20 June 2016, 5:53:34.991847 am UUID: 76d700fa-1db5-4b32-911e-5dd98d003af9 Ancestors: CMakeVMMakerSqueak-tty.128 incremental refactor and addition as I work on the terse guide to Configuration creation =============== Diff against CMakeVMMakerSqueak-tty.128 =============== Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>dirBuildLanguageVMMM (in category 'pages') ----- dirBuildLanguageVMMM ^HelpTopic title:'Specify dirBuildLanguageVMMM' contents: 'Within the broad outline of this tutorial, you are here: 8. Customizing your Configuration. SystemNavigation new browseAllImplementorsOf: #dirBuildLanguageVMMM localTo:CPlatformConfigForSqueak. We scroll down to our Linux64x86w32BitSqueakCogSpurConfig which we copied from the existing Linux64x86w32BitSqueakCogV3Config. Looking at the dirBuildLanguageVMMM it initially reads (due to the copying of the existing class) dirBuildLanguageVMMM ^self squeakCogV3 Since this is a configuration for Squeak Cog Spur, I modify the method to return dirBuildLanguageVMMM ^self squeakCogSpur As a sanity check, I verify that the method squeakCogSpur exists... SystemNavigation new browseAllImplementorsOf: #squeakCogSpur And we see the method exists and will return the string ''squeak.cog.spur''. (CPlatformConfigForSqueak basicNew) squeakCogSpur + The result will be used in two places--in the build directory and the output directory relative to the directories we have specified. + The build directory at the platform level now looks like: "oscogvm/cmake.build.linux64x86w32BitCompatibility/squeak.cog.spur/ + The output directory at the platform level now looks like: "oscogvm/cmake.products/cmake.build.linux64x86w32BitCompatibility/squeak.cog.spur/ + + + + '! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>pages (in category 'accessing') ----- pages "platformSources...cogitClass...src vs vmsrc" ^#( overview tests identifyPlatform identifyPlatformAbstractBaseClass identifyBuilder createTheConfiguration excludingConfigFromBuilds isAbstractBaseClass isAbstractBaseClassAndExcludeFromBuild setAvailableBuildTypes firstCMakeGeneration tackingStockOne cPlatformConfigForSqueak methodRedirectPattern theVMGenerator tackingStockTwo cPlatformConfigForSqueakInitialize initializePlatformSources customizePlatformSources initializeVMPlugins customizeVMPlugins configGenerateByTemplate specifyCogitClass specifyDirectories + specifyTopDir + specifyDirOutput + specifyDirBuildPlatform dirBuildLanguageVMMM setGlobalOptions cmakePrefixPath cmakeIncludePath cmakeLibraryPath cmakeIncludeModules cmakeCFlags cmakeAddDefinitions cmakeWriteDirectoriesDotCmake cmakeIncludeDirectories preferredIncludes standardIncludes setGlobalOptionsAfterDetermineSystem extraVMSettings setCoreSources setPlatformSources setCrossSources setExtraSources cmakeSetSourceFilesProperties cmakeListAppendLINKLIBSelements cmakeAddExecutableNameOptionSource setExecutableOutputPath addVMPlugins generatePluginConfigs specifyPlugins processPlugins postBuildActions generateBuildScript fin ) ! Item was added: + ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>specifyDirBuildPlatform (in category 'pages') ----- + specifyDirBuildPlatform + ^HelpTopic + title: 'Specify dirBuildPlatform' + contents: + 'Within the broad outline of this tutorial, you are here: + 8. Customizing your Configuration. + + + Please evaluate: + SystemNavigation new browseAllImplementorsOf: #dirBuildPlatform + + Notice that the CPlatformForSqueak forces subclasses to implement his. + + Looking at the classes that do implement it, notice that they are all at the platform level; i.e. they correspond to the OperatingSystem/Processor the user is compiling for. + + Taking the Linux64x86w32BitConfigUsrLib Confiiguration, we see its implementation of "dirBuildPlatform" returns + ^self dirLinux64x86w32BitCompatibility + + SystemNavigation new browseAllImplementorsOf: #dirLinux64x86w32BitCompatibility + + Notice that return value is a "cmake directory string" method in CPlatformConfigForSqueak. + + + The result will be used in two places--in the build directory and the output directory relative to the directories we have specified. + + The build directory at the platform level now looks like: "oscogvm/cmake.build.linux64x86w32BitCompatibility + + The output directory at the platform level now looks like: "oscogvm/cmake.products/cmake.build.linux64x86w32BitCompatibility + + !!'! Item was added: + ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>specifyDirOutput (in category 'pages') ----- + specifyDirOutput + ^HelpTopic + title: 'Specify dirOutput' + contents: + 'Within the broad outline of this tutorial, you are here: + 8. Customizing your Configuration. + + SystemNavigation new browseAllImplementorsOf: #dirOutput + + Here, we see a "cmake directory string" returned. + + The system will use this to create the "oscogvm/cmake.products" directory which will store the compiled VM for your configuration. + + This will rarely, if ever, need customization. + + !!'! Item was changed: ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>specifyDirectories (in category 'pages') ----- specifyDirectories + "This method was automatically generated. Edit it using:" + "a HelpBrowser edit: #specifyDirectories" ^HelpTopic + title: 'Specify Directories Overview' + contents: - title:'Specify Directories' - contents: 'Within the broad outline of this tutorial, you are here: 8. Customizing your Configuration. Our new Configuration must correctly name two directory trees. The first is the cmake.build.* directory tree where the generated CMake output is placed. The second is the cmake.products/* directory tree where the compiled vm is placed. Correctly naming these is a courtesy you should extend as the system grows*. For this particular Configuration, we want a cmake.build.* directory that looks like this: oscogvm/cmake.products/cmake.build.linux64x86w32BitCompatibility/squeak.cog.spur and we want a cmake.products/* directory that looks like this: oscogvm/cmake.products/cmake.build.linux64x86w32BitCompatibility/squeak.cog.spur/build + Each directory in those trees is accessible via the the CPlatformConfigForSqueak method categories: ''cmake directory strings'' and "cmake directory objects" - Each directory in those trees is accessible viathe the CPlatformConfigForSqueak in the ''cmake directory'' category. + ToolSet browseClass: CPlatformConfigForSqueak category: ''cmake directory strings''. + ToolSet browseClass: CPlatformConfigForSqueak category: ''cmake directory objects''. - ToolSet browseClass: CPlatformConfigForSqueak category: ''cmake directory''. - There are two method variants. + Methods in "cmake directory strings" return strings. + Methods in "cmake directory objects" return FileDirectory objects. - The first variant is hardcoded in the method itself. For example the platform directories are stored as... + + In "cmake directory strings" there are two method variants. + + The first variant in "cmake directory strings" is hardcoded in the method itself. For example the platform directories are stored as... + dirLinux32Armv6 ^''cmake.build.linux32armv6'' or, for our configuration dirLinux64x86w32BitCompatibility ^''cmake.build.linux64x86w32BitCompatibility'' + The second variant in "cmake directory strings" accesses the name of a buildType directory via the SqueakCMakeVMMakerAbstractBuilder (do a printIt or doIt). - The second variant accesses the name of a buildType directory via the SqueakCMakeVMMakerAbstractBuilder (do a printIt or doIt). dirBuild ^SqueakCMakeVMMakerAbstractBuilder default buildTypeAndDirectoryInfo at: #build - - Each part of the directory tree is contained/accessible via these methods. It is our job to select the corect ones for our purposes. Here is an example of mapping this output directory path ''oscogvm/cmake.products/cmake.build.linux64x86w32BitCompatibility/squeak.cog.spur/build'' to the methods that output each part. |c| c:=(CPlatformConfigForSqueak basicNew). (c oscogvm), ''/'', (c dirOutput), ''/'', (c dirLinux64x86w32BitCompatibility), ''/'', (c squeakCogSpur), ''/'', (c dirBuild) The methods corresponding to each of the above directory names are: topDir dirOutput dirBuildPlatform dirBuildLanguageVMMM buildType (not a method,this is a private instance variable in the configuration) The first two, topDir and dirOutput are contained in CPlatformConfigForSqueak dirBuildPlatform is contained at the platform level SystemNavigation new browseAllImplementorsOf: #dirBuildPlatform localTo:CPlatformConfigForSqueak. dirBuildLangaugeVMMM is at the specific Configuration level SystemNavigation new browseAllImplementorsOf: #dirBuildLanguageVMMM localTo:CPlatformConfigForSqueak. buildType is set when we configure the Configuration for a particular buildType and is stored in the SqueakCMakeVMMakerAbstractBuilder at its initialization. SystemNavigation new browseAllImplementorsOf: #initializeBuildTypeAndDirectoryInfo It is this values that the CPlatformConfigForSqueak access via dirBuild, dirBuildAssert etc... SystemNavigation new browseAllImplementorsOf: #dirBuild Similarly, the build directory tree ''oscogvm/cmake.build.linux64x86w32BitCompatibility/squeak.cog.spur/build/'' has methods corresponding to each of the above directory names. they are: topDir dirBuildPlatform dirBuildLanguageVMMM buildType (not a method,this is a private instance variable in the configuration) It follows then, that for our Configuration we need to make the method dirBuildLanguageVMMM return ''squeak.cog.spur''. We cover that in the next Help page. *The naming convention is straightforward and convered in the ''Naming Convetions'' page of the Developer Guide Overview Help. + HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp) model showTopicThat: [:topic | topic key = #namingConventions]. - (HelpBrowser openOn: CMakeVMMakerSqueakOverviewHelp) model - showTopicThat: [:topic | topic key = #namingConventions]. + !!'! - - '! Item was added: + ----- Method: CMakeVMMakerSqueakTutorialNewConfigurationHelp class>>specifyTopDir (in category 'pages') ----- + specifyTopDir + ^HelpTopic + title: 'Specify TopDir' + contents: + 'Within the broad outline of this tutorial, you are here: + 8. Customizing your Configuration. + + topDir is the root at the top of the build tree and it is fitting it is in the top Configuration. + + SystemNavigation new browseAllImplementorsOf: #topDir + SystemNavigation new browseAllImplementorsOf: #oscogvm + + Here, we see a "cmake directory object" and "cmake directory string" used to create a FileDirectory object named ''oscogvm" + + This will rarely, if ever, need customization. + + !!'! From damien.pollet at gmail.com Mon Jun 20 12:26:31 2016 From: damien.pollet at gmail.com (Damien Pollet) Date: Mon Jun 20 12:27:01 2016 Subject: [Vm-dev] Speaking of git and git books.... In-Reply-To: <15569cf9c99.e05cb1de12409.4216625053762496504@zoho.com> References: <15569cf9c99.e05cb1de12409.4216625053762496504@zoho.com> Message-ID: All those books are maintained there: https://github.com/SquareBracketAssociates In particular, the following repo is there to gather new chapters for future books; feel free to contribute :) https://github.com/SquareBracketAssociates/PharoInProgress On 19 June 2016 at 19:57, gettimothy wrote: > > I know that everybody is busy with the vm and git. I just want to through > this out there > > The Tex/LaTex source code for some Squeak books is available. > > I have the SqueakByExample-english source code on my computer (I forget > where I got it). > > That have one that I used as a model for my Programming The Squeak > Virtual Machines...than I am (was) writing as I try (tried) to understand > the Interpreter stuff. > > The transition to git provides an opportunity to upload the source code > for those books so as to provide for more dispersed community development > access point. > > Editing would "merely" be a matter of merging in changes and new branches. > > The content could grow a bit more quickly with that model. > > cheers, > > tty > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/b67023e1/attachment.htm From asqueaker at gmail.com Mon Jun 20 17:48:50 2016 From: asqueaker at gmail.com (Chris Muller) Date: Mon Jun 20 17:49:31 2016 Subject: [Vm-dev] System and user processes In-Reply-To: References: Message-ID: Hi Max, I had a similar idea, and made a ClientProcess class. Its primary purpose is to provide a nice wrapping API for *users* to manage their "background running tasks" (i.e., #start, #stop, #pause, #resume, #progress, #priority adjustment), as well as a nice API for *developers* to report its progress via a simple signaling mechanism, which also gives the user all the performance stats for "free" too like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime, etc. On Sun, Jun 19, 2016 at 4:03 AM, Max Leske wrote: > > Hi, > > In Pharo and Squeak we have no separation between processes that belong to the IDE, tools etc. and processes that are spawned as part of an application. I?d like to know your opinion on the following (rough) idea: > > 1. We introduce two subclasses of Process: SystemProcess and UserProcess > 2. We define #isSystemProcess and #isUserProcess > 3. We introduce #newSystemProcess and #newUserProcess > 4. We deprecate #newProcess and delegate to #newUserProcess (thereby modifying all users of #forkXXX to yield instances of UserProcess) > > Of the following I?m less sure: > 5. We introduce #forkSystemProcess et. al > > I?ve tried this out in Pharo 6 and there seem to be no problems with the VM. The benefit would be improved separation between system and user space. It would allow us to implement stuff for processes in general (e.g. for the debugger) which we do not want to affect system processes like the UI process or the background process. One concrete example: the process browser could hide all system processes and make them visible on demand (that would greatly improve the view because you can now better find your own processes). > > > I?m looking forward to your comments. > > Cheers, > Max From tim at rowledge.org Mon Jun 20 18:09:57 2016 From: tim at rowledge.org (tim Rowledge) Date: Mon Jun 20 18:09:43 2016 Subject: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch In-Reply-To: References: <1FB5ED99-0B8D-4362-A212-BE311FD2361E@inria.fr> Message-ID: <56CE3534-3BBF-4558-A378-6DA6E9FD71B1@rowledge.org> > On 20-06-2016, at 12:17 AM, Cl?ment Bera wrote: > > I think there was a misunderstanding Tim. The idea is not necessarily to let developers write code with this many arguments, the IDE could actually enforces the programmer not to write methods with too many arguments. It's really about non programmers, like code generating tools such as SmaCC. Excellent point, nicely made. You have my permission to proceed :-J tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: REP: Randomly Execute Programmers From holger at freyther.de Mon Jun 20 20:06:28 2016 From: holger at freyther.de (Holger Freyther) Date: Mon Jun 20 20:06:30 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz Message-ID: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> > On 18 Jun 2016, at 23:28, commits@source.squeak.org wrote: > > > Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: > http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz Hi, I might be teared and feathered but what would it take to maintain the CMakeLists.txt directly in git and not of generate them from Smalltalk? From my limited point of view it seems cmake supports targeting multiple platforms/configurations from within the CMakeLists. And when trying to build the PharoVM on FreeBSD I had a lot of trouble[1] and waited[2] a bit too much. kind regards holger [1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. [2] I seem to have failed to just generate the CMakeLists.txt/* and decided to generate everything which took some time. E.g. the files not being truncated before they are written to From commits at source.squeak.org Mon Jun 20 20:35:47 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Jun 20 20:35:49 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1889.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1889.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1889 Author: eem Time: 20 June 2016, 1:33:14.0061 pm UUID: 24dcf481-d07a-4e68-a4bf-7d6d8ce2ae4f Ancestors: VMMaker.oscog-eem.1888 Fix a bug in Spur become validation, a regression from supporting copyHash properly. The check for there being available memroy for copies of all arguments should only occur in the two-way case, not in the one-way copyHash case. Refactor Clément's checker into ifOopInvalidForBecome:errorCodeInto: and use it to check all checked arguments. This fixes Bert's (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) case. In 1889 Herman Hollerith receives a patent for his electric tabulating machine in the United States, Vincent van Gogh paints The Starry Night at Saint-Rémy-de-Provence, and the Eiffel Tower is inaugurated and opens on May 6. At 300 m, its height exceeds the previous tallest structure in the world by 130 m. =============== Diff against VMMaker.oscog-eem.1888 =============== Item was changed: ----- Method: SpurMemoryManager>>become:with:twoWay:copyHash: (in category 'become api') ----- become: array1 with: array2 twoWay: twoWayFlag copyHash: copyHashFlag "All references to each object in array1 are swapped with all references to the corresponding object in array2. That is, all pointers to one object are replaced with with pointers to the other. The arguments must be arrays of the same length. Answers PrimNoErr if the primitive succeeds, otherwise a relevant error code." "Implementation: Uses lazy forwarding to defer updating references until message send." + | ec | self assert: becomeEffectsFlags = 0. self runLeakCheckerFor: GCModeBecome. (self isArray: array1) ifFalse: [^PrimErrBadReceiver]. ((self isArray: array2) and: [(self numSlotsOf: array1) = (self numSlotsOf: array2)]) ifFalse: [^PrimErrBadArgument]. + ec := self containsOnlyValidBecomeObjects: array1 and: array2 twoWay: twoWayFlag copyHash: copyHashFlag. - (twoWayFlag or: [copyHashFlag]) - ifTrue: - [ec := self containsOnlyValidBecomeObjects: array1 and: array2] - ifFalse: - [self followForwardedObjectFields: array2 toDepth: 0. - ec := self containsOnlyValidBecomeObjects: array1]. ec ~= 0 ifTrue: [becomeEffectsFlags := 0. ^ec]. coInterpreter preBecomeAction. twoWayFlag ifTrue: [self innerBecomeObjectsIn: array1 and: array2 copyHash: copyHashFlag] ifFalse: [self innerBecomeObjectsIn: array1 to: array2 copyHash: copyHashFlag]. self followSpecialObjectsOop. "N.B. perform coInterpreter's postBecomeAction: *before* postBecomeScanClassTable: to allow the coInterpreter to void method cache entries by spotting classIndices that refer to forwarded objects. postBecomeScanClassTable: follows forwarders in the table." coInterpreter postBecomeAction: becomeEffectsFlags. self postBecomeScanClassTable: becomeEffectsFlags. becomeEffectsFlags := 0. self assert: self validClassTableHashes. self runLeakCheckerFor: GCModeBecome. ^PrimNoErr "success"! Item was removed: - ----- Method: SpurMemoryManager>>containsOnlyValidBecomeObjects: (in category 'become implementation') ----- - containsOnlyValidBecomeObjects: array - "Answer 0 if the array contains only unpinned non-immediates. - Otherwise answer an informative error code. - Can't become: immediates!! Shouldn't become pinned objects." - | fieldOffset effectsFlags oop errCode | - fieldOffset := self lastPointerOfArray: array. - effectsFlags := 0. - "same size as array2" - [fieldOffset >= self baseHeaderSize] whileTrue: - [oop := self longAt: array + fieldOffset. - (self isOopForwarded: oop) ifTrue: - [oop := self followForwarded: oop. - self longAt: array + fieldOffset put: oop]. - (errCode := self isOopValidBecome: oop) = 0 ifFalse: [^ errCode]. - effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop). - fieldOffset := fieldOffset - self bytesPerOop]. - "only set flags after checking all args." - becomeEffectsFlags := effectsFlags. - ^0! Item was removed: - ----- Method: SpurMemoryManager>>containsOnlyValidBecomeObjects:and: (in category 'become implementation') ----- - containsOnlyValidBecomeObjects: array1 and: array2 - "Answer 0 if neither array contains only unpinned non-immediates. - Otherwise answer an informative error code. - Can't become: immediates!! Shouldn't become pinned objects." - | fieldOffset effectsFlags oop size | - fieldOffset := self lastPointerOf: array1. - effectsFlags := size := 0. - "same size as array2" - [fieldOffset >= self baseHeaderSize] whileTrue: - [oop := self longAt: array1 + fieldOffset. - (self isOopForwarded: oop) ifTrue: - [oop := self followForwarded: oop. - self longAt: array1 + fieldOffset put: oop]. - (self isImmediate: oop) ifTrue: [^PrimErrInappropriate]. - (self isPinned: oop) ifTrue: [^PrimErrObjectIsPinned]. - effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop). - size := size + (self bytesInObject: oop). - oop := self longAt: array2 + fieldOffset. - (self isOopForwarded: oop) ifTrue: - [oop := self followForwarded: oop. - self longAt: array2 + fieldOffset put: oop]. - (self isImmediate: oop) ifTrue: [^PrimErrInappropriate]. - (self isPinned: oop) ifTrue: [^PrimErrObjectIsPinned]. - effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop). - size := size + (self bytesInObject: oop). - fieldOffset := fieldOffset - self bytesPerOop]. - size >= (totalFreeOldSpace + (scavengeThreshold - freeStart)) ifTrue: - [^PrimErrNoMemory]. - "only set flags after checking all args." - becomeEffectsFlags := effectsFlags. - ^0! Item was added: + ----- Method: SpurMemoryManager>>containsOnlyValidBecomeObjects:and:twoWay:copyHash: (in category 'become implementation') ----- + containsOnlyValidBecomeObjects: array1 and: array2 twoWay: isTwoWay copyHash: copyHash + "Answer 0 if neither array contains an object inappropriate for the become operation. + Otherwise answer an informative error code for the first offending object found: + Can't become: immediates => PrimErrInappropriate + Shouldn't become pinned objects => PrimErrObjectIsPinned. + Shouldn't become immutable objects => PrimErrNoModification. + Can't copy hash into immediates => PrimErrInappropriate. + Two-way become may require memory to create copies => PrimErrNoMemory. + As a side-effect unforward any forwarders in the two arrays if answering 0." + + | fieldOffset effectsFlags oop1 oop2 size | + fieldOffset := self lastPointerOf: array1. + effectsFlags := size := 0. + "array1 is known to be the same size as array2" + [fieldOffset >= self baseHeaderSize] whileTrue: + [oop1 := self longAt: array1 + fieldOffset. + (self isOopForwarded: oop1) ifTrue: + [oop1 := self followForwarded: oop1. + self longAt: array1 + fieldOffset put: oop1]. + self ifOopInvalidForBecome: oop1 errorCodeInto: [:errCode| ^errCode]. + effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop1). + oop2 := self longAt: array2 + fieldOffset. + (self isOopForwarded: oop2) ifTrue: + [oop2 := self followForwarded: oop2. + self longAt: array2 + fieldOffset put: oop2]. + isTwoWay + ifTrue: + [self ifOopInvalidForBecome: oop2 errorCodeInto: [:errCode| ^errCode]. + size := size + (self bytesInObject: oop1) + (self bytesInObject: oop2). + effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop2)] + ifFalse: + [(copyHash and: [self isImmediate: oop2]) ifTrue: + [^PrimErrInappropriate]]. + fieldOffset := fieldOffset - self bytesPerOop]. + size >= (totalFreeOldSpace + (scavengeThreshold - freeStart)) ifTrue: + [^PrimErrNoMemory]. + "only set flags after checking all args." + becomeEffectsFlags := effectsFlags. + ^0! Item was added: + ----- Method: SpurMemoryManager>>ifOopInvalidForBecome:errorCodeInto: (in category 'become implementation') ----- + ifOopInvalidForBecome: oop errorCodeInto: aBlock + "Evaluates aBlock with an appropriate error if oop is invalid for become." + + (self isImmediate: oop) ifTrue: + [^aBlock value: PrimErrInappropriate]. + (self isPinned: oop) ifTrue: + [^aBlock value: PrimErrObjectIsPinned]. + (self isObjImmutable: oop) ifTrue: + [^aBlock value: PrimErrNoModification]! Item was removed: - ----- Method: SpurMemoryManager>>isOopValidBecome: (in category 'become implementation') ----- - isOopValidBecome: oop - "Answers 0 if the oop can be become. - Answers an error code in the other case" - (self isImmediate: oop) ifTrue: [^PrimErrInappropriate]. - (self isPinned: oop) ifTrue: [^PrimErrObjectIsPinned]. - (self isObjImmutable: oop) ifTrue: [^PrimErrNoModification]. - ^0! From eliot.miranda at gmail.com Mon Jun 20 20:36:20 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 20 20:36:23 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: Message-ID: Hi Bert, it was a regression in argument validation for become introduced in fixing argument validation for the one-way copy hash case. The code was erroneously checking that it had space to create copies of the input arguments, even though it was a one-way become. It's a copyHash become and that confused it. It's now fixed. I'll generate sources and push and new builds should appear shortly ;-) On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg wrote: > > I'm reading a 20MB text file. At some point it tries to convert the 20 MB > ByteString into an 80 MB WideString using forward become. This fails > resulting in an endless loop. The primitive failure code for > elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' > and it tries again after growing: > > ec == #'insufficient object memory' ifTrue: > [Smalltalk garbageCollect < 1048576 ifTrue: > [Smalltalk growMemoryByAtLeast: 1048576]. > ^self elementsForwardIdentityTo: otherArray]. > > but the growMemoryByAtLeast: does not actually grow the memory: > > {Smalltalk garbageCollect. > Smalltalk growMemoryByAtLeast: 1048576. > Smalltalk garbageCollect.} > > ==> #(58576608 16777216 58576608) > > 58 MB are not enough, but it doesn't grow any further. > > The question is, why does it try to allocate a new object at all? The > WideString exists already. I thought Spur would simply install a forwarder? > > To reproduce, execute > > (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) > > You probably want to follow that with a user interrupt (Cmd-period). > > This happens using the latest Spur VM from github (r201606160944) > > - Bert - > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/5490db05/attachment.htm From eliot.miranda at gmail.com Mon Jun 20 20:40:59 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 20 20:41:02 2016 Subject: [Vm-dev] Script needed; git mavens can you help? Message-ID: Hi git mavens, I've used a script called svnrevert in the svn version that reverts any changed file in its argument(s), which may be directories, /and/ sets the modification date to the date at which the file was last checked in. I'd like the same functionality in git. Her'es the subversion version: #!/bin/bash # Revert file(s) or all modified files in a directory # and touch them back to the checkin date for f in "$@" do if [ -d "$f" ]; then $0 `svn st "$f" | grep "^M" | sed 's/^M *//'` else if svn revert "$f"; then changed="`svn info \"$f\" | grep 'Last Changed Date:' | sed 's/ *(.*//'`" touch -t "`date -j -f 'Last Changed Date: %Y-%m-%d %H:%M:%S %z' \"$changed\" '+%Y%m%d%H%M.%S'`" "$f" fi fi done _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/85e39bcc/attachment.htm From Das.Linux at gmx.de Mon Jun 20 21:09:46 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon Jun 20 21:09:47 2016 Subject: [Vm-dev] Script needed; git mavens can you help? In-Reply-To: References: Message-ID: <782F6A84-EE6D-4DC7-BDE0-E3183C2321B2@gmx.de> On 20.06.2016, at 22:40, Eliot Miranda wrote: > Hi git mavens, > > I've used a script called svnrevert in the svn version that reverts any changed file in its argument(s), which may be directories, /and/ sets the modification date to the date at which the file was last checked in. I'd like the same functionality in git. Her'es the subversion version: without the modification-date requirement git checkout -- .... does what you want (given you have NOT staged/git-added it before). I'm curious, what's important about the last commit date? Best regards -Tobias > > #!/bin/bash > # Revert file(s) or all modified files in a directory > # and touch them back to the checkin date > for f in "$@" > do > if [ -d "$f" ]; then > $0 `svn st "$f" | grep "^M" | sed 's/^M *//'` > else > if svn revert "$f"; then > changed="`svn info \"$f\" | grep 'Last Changed Date:' | sed 's/ *(.*//'`" > touch -t "`date -j -f 'Last Changed Date: %Y-%m-%d %H:%M:%S %z' \"$changed\" '+%Y%m%d%H%M.%S'`" "$f" > fi > fi > done > > _,,,^..^,,,_ > best, Eliot From damien.pollet at gmail.com Mon Jun 20 21:11:31 2016 From: damien.pollet at gmail.com (Damien Pollet) Date: Mon Jun 20 21:12:03 2016 Subject: [Vm-dev] Script needed; git mavens can you help? In-Reply-To: References: Message-ID: To complete Tobias's answer, git checkout HEAD -- will restore files from the most recent commit even if changes were staged. In what situation do you use that script? People on stack overflow seem to have pretty polarized opinions about fiddling with timestamps? one of the answers has something close, but there might be a simpler way? http://stackoverflow.com/questions/1964470/whats-the-equivalent-of-use-commit-times-for-git On 20 June 2016 at 22:40, Eliot Miranda wrote: > > Hi git mavens, > > I've used a script called svnrevert in the svn version that reverts > any changed file in its argument(s), which may be directories, /and/ sets > the modification date to the date at which the file was last checked in. > I'd like the same functionality in git. Her'es the subversion version: > > #!/bin/bash > # Revert file(s) or all modified files in a directory > # and touch them back to the checkin date > for f in "$@" > do > if [ -d "$f" ]; then > $0 `svn st "$f" | grep "^M" | sed 's/^M *//'` > else > if svn revert "$f"; then > changed="`svn info \"$f\" | grep 'Last Changed Date:' | sed 's/ *(.*//'`" > touch -t "`date -j -f 'Last Changed Date: %Y-%m-%d %H:%M:%S %z' > \"$changed\" '+%Y%m%d%H%M.%S'`" "$f" > fi > fi > done > > _,,,^..^,,,_ > best, Eliot > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/abe9c59c/attachment.htm From lewis at mail.msen.com Mon Jun 20 23:05:23 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Mon Jun 20 23:05:25 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz In-Reply-To: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> References: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> Message-ID: <20160620230523.GA43508@shell.msen.com> On Mon, Jun 20, 2016 at 10:06:28PM +0200, Holger Freyther wrote: > > > > On 18 Jun 2016, at 23:28, commits@source.squeak.org wrote: > > > > > > Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: > > http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz > > Hi, > > I might be teared and feathered but what would it take to maintain the CMakeLists.txt directly in git and not of generate them from Smalltalk? > That is exactly how Ian Piumarta's CMake build system has been working for the last 6 years or so. It is done with a relatively small amount of CMake scripting code, and has been working reliably with only minimal maintenance since it was first put in place. My earlier comments on this topic are here (my references to the Subversion repository would now pertain to the new Github repository): http://lists.squeakfoundation.org/pipermail/vm-dev/2014-May/015313.html > From my limited point of view it seems cmake supports targeting multiple platforms/configurations from within the CMakeLists. And when trying to build the PharoVM on FreeBSD I had a lot of trouble[1] and waited[2] a bit too much. > Yes, that is the purpose of CMake. It is designed to be a platform independent build tool. If you find yourself creating large quantities of platform specific CMake scripts, it is a sign that something is wrong. So it certainly does make sense for the CMakeLists to be maintained and versioned along with the source code to which they apply. No need for any tar and feathers IMHO :-) Dave > kind regards > > holger > > > > [1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. > > [2] I seem to have failed to just generate the CMakeLists.txt/* and decided to generate everything which took some time. E.g. the files not being truncated before they are written to From gettimothy at zoho.com Tue Jun 21 00:02:33 2016 From: gettimothy at zoho.com (gettimothy) Date: Tue Jun 21 00:02:37 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz In-Reply-To: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> References: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> Message-ID: <155704402c1.12b326a72124292.3735289149539011470@zoho.com> Hi Holger. Whatever works for the team is fine by me. However, let me throw this out there. The git C source code is really located in the Smalltalk image with VMMaker.oscog installed. The engineer (Eliot) develops the VM in Smalltalk using Smalltalk and then outputs the C code from Smalltalk. The engineer then uses git to "upload" that C code to the git server. The CMakeVMakerSqueak does the same thing. It stores CMake Configurations as objects and then writes that information to standard CMake files in a directory structure that mimics the C directory structure. The CMake build tree can then be uploaded the same way. The model for the CMakeLists.txt is taken directly from Ian's code. Stated differently, Ian's CMake code is stored in Smalltalk. Now, this seques into a VERY IMPORTANT POINT... I think the CMake output I currently generate needs to be looked at with a critical eye and changes improvements made from a strictly CMake perspective (Like Ian did). I can then take those changes and store them in the CMakeVMMakerSqueak (if you want me to; we can discuss some ideas why it may make sense) Building CMakeLists.txt for Windows 32, Windows 64 MacOs, OSX, ARM6 ARM7 , Linux 32, Linux 64, Linux 62w32libs, SunOS, Plan9...etc. needs to be done too. Consider also the sheer scope of the CMakeLists.txt that need to be developed. in the Cog directory tree are build directories. Taking the build.linux32x86 directory as an example, we have a directory tree that looks like this: build.linux32x86/ |-- newspeak.cog.spur | |-- build | |-- build.assert | |-- build.assert.itimerheartbeat | |-- build.debug | |-- build.debug.itimerheartbeat | `-- build.itimerheartbeat |-- newspeak.cog.v3 | |-- build ......etc... . The FORM of this layout is : build.[PLATFORM]/ |-- [Language].[VM].[Memory Manager]/ | |-- [BuildType] So looking at the combinations of [PLATFORM][Language].[VM].[Memory Manager] [BuildType] you have [Windows 32, Windows 64 MacOs, OSX, ARM6 ARM7 , Linux 32, Linux 64, Linux 62w32libs, SunOS, Plan9...etc][squeak, newspeak] [stackVM cogVM][V3 Spur][build build.assert, etc....] [10 (at least) platforms] x [2 languages] x [2 VMs] x[2 Memory Models] x [6 build types] = 480 distinct build configurations that need supporting. IF the community decides that it is EASIER to work with just CMake Scripts and maintain those by hand, I am fine with that. If the community decides that it is BETTER to store them in Smalltalk, I am fine with that too. cheers, tty ---- On Mon, 20 Jun 2016 16:06:28 -0400 Holger Freyther <holger@freyther.de> wrote ---- > On 18 Jun 2016, at 23:28, commits@source.squeak.org wrote: > > > Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: > http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz Hi, I might be teared and feathered but what would it take to maintain the CMakeLists.txt directly in git and not of generate them from Smalltalk? >From my limited point of view it seems cmake supports targeting multiple platforms/configurations from within the CMakeLists. And when trying to build the PharoVM on FreeBSD I had a lot of trouble[1] and waited[2] a bit too much. kind regards holger [1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. [2] I seem to have failed to just generate the CMakeLists.txt/* and decided to generate everything which took some time. E.g. the files not being truncated before they are written to -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/fd590b06/attachment.htm From gettimothy at zoho.com Tue Jun 21 00:14:03 2016 From: gettimothy at zoho.com (gettimothy) Date: Tue Jun 21 00:14:08 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz In-Reply-To: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> References: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> Message-ID: <155704e8b74.121affb21124357.8747343458235732232@zoho.com> Hi Holger. For the BSD, just take a generated CMake build tree for linux, copy it over to a BSD directory structure and hack away. I will be happy to walk you through the steps. When you get a working BSD Cmake thing going, I can store it in Smalltalk (If we decide to go that route) Are you on a 64 bit machine or a 32 bit machine ? Same for all you ARM and Dos guys. cheers, tty ---- On Mon, 20 Jun 2016 16:06:28 -0400 Holger Freyther<holger@freyther.de> wrote ---- > On 18 Jun 2016, at 23:28, commits@source.squeak.org wrote: > > > Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: > http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz Hi, I might be teared and feathered but what would it take to maintain the CMakeLists.txt directly in git and not of generate them from Smalltalk? >From my limited point of view it seems cmake supports targeting multiple platforms/configurations from within the CMakeLists. And when trying to build the PharoVM on FreeBSD I had a lot of trouble[1] and waited[2] a bit too much. kind regards holger [1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. [2] I seem to have failed to just generate the CMakeLists.txt/* and decided to generate everything which took some time. E.g. the files not being truncated before they are written to -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/46f0237d/attachment.htm From timfelgentreff at gmail.com Tue Jun 21 05:39:32 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Tue Jun 21 05:39:39 2016 Subject: [Vm-dev] Script needed; git mavens can you help? In-Reply-To: References: Message-ID: Hi Eliot, When I did the migration I made a gitrevert script. It is in the scripts dir. Best, Tim Am 20.06.2016 23:12 schrieb "Damien Pollet" : > > To complete Tobias's answer, git checkout HEAD -- will restore > files from the most recent commit even if changes were staged. > > In what situation do you use that script? > > People on stack overflow seem to have pretty polarized opinions about > fiddling with timestamps? one of the answers has something close, but there > might be a simpler way? > > http://stackoverflow.com/questions/1964470/whats-the-equivalent-of-use-commit-times-for-git > > > > On 20 June 2016 at 22:40, Eliot Miranda wrote: > >> >> Hi git mavens, >> >> I've used a script called svnrevert in the svn version that reverts >> any changed file in its argument(s), which may be directories, /and/ sets >> the modification date to the date at which the file was last checked in. >> I'd like the same functionality in git. Her'es the subversion version: >> >> #!/bin/bash >> # Revert file(s) or all modified files in a directory >> # and touch them back to the checkin date >> for f in "$@" >> do >> if [ -d "$f" ]; then >> $0 `svn st "$f" | grep "^M" | sed 's/^M *//'` >> else >> if svn revert "$f"; then >> changed="`svn info \"$f\" | grep 'Last Changed Date:' | sed 's/ *(.*//'`" >> touch -t "`date -j -f 'Last Changed Date: %Y-%m-%d %H:%M:%S %z' >> \"$changed\" '+%Y%m%d%H%M.%S'`" "$f" >> fi >> fi >> done >> >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/19e3b9f9/attachment.htm From maxleske at gmail.com Tue Jun 21 06:13:48 2016 From: maxleske at gmail.com (Max Leske) Date: Tue Jun 21 06:13:57 2016 Subject: [Pharo-dev] [Vm-dev] System and user processes In-Reply-To: References: Message-ID: <6AA5B65F-4994-43EF-976E-E8FEFE99D4C4@gmail.com> > On 20 Jun 2016, at 19:48, Chris Muller wrote: > > Hi Max, I had a similar idea, and made a ClientProcess class. Its > primary purpose is to provide a nice wrapping API for *users* to > manage their "background running tasks" (i.e., #start, #stop, #pause, > #resume, #progress, #priority adjustment), as well as a nice API for > *developers* to report its progress via a simple signaling mechanism, > which also gives the user all the performance stats for "free" too > like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime, > etc. Very nice! So I don?t seem to be the only one to think there may be room for improvement :) Your idea focuses on a different aspect of course but both ideas would go well together I think. Is your code public somewhere? Just in case this gains some traction. Cheers, Max > > On Sun, Jun 19, 2016 at 4:03 AM, Max Leske wrote: >> >> Hi, >> >> In Pharo and Squeak we have no separation between processes that belong to the IDE, tools etc. and processes that are spawned as part of an application. I?d like to know your opinion on the following (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and UserProcess >> 2. We define #isSystemProcess and #isUserProcess >> 3. We introduce #newSystemProcess and #newUserProcess >> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby modifying all users of #forkXXX to yield instances of UserProcess) >> >> Of the following I?m less sure: >> 5. We introduce #forkSystemProcess et. al >> >> I?ve tried this out in Pharo 6 and there seem to be no problems with the VM. The benefit would be improved separation between system and user space. It would allow us to implement stuff for processes in general (e.g. for the debugger) which we do not want to affect system processes like the UI process or the background process. One concrete example: the process browser could hide all system processes and make them visible on demand (that would greatly improve the view because you can now better find your own processes). >> >> >> I?m looking forward to your comments. >> >> Cheers, >> Max > From holger at freyther.de Tue Jun 21 07:08:48 2016 From: holger at freyther.de (Holger Freyther) Date: Tue Jun 21 07:08:52 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz In-Reply-To: <155704402c1.12b326a72124292.3735289149539011470@zoho.com> References: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> <155704402c1.12b326a72124292.3735289149539011470@zoho.com> Message-ID: <80C140AF-B1F7-4230-9D73-2C873B9156EF@freyther.de> > On 21 Jun 2016, at 02:02, gettimothy wrote: > > Hi Holger. Good Morning tty, > The git C source code is really located in the Smalltalk image with VMMaker.oscog installed. The engineer (Eliot) develops the VM in Smalltalk using Smalltalk and then outputs the C code > from Smalltalk. The engineer then uses git to "upload" that C code to the git server. > > The CMakeVMakerSqueak does the same thing. It stores CMake Configurations as objects and then writes that information to standard CMake files in a directory structure that mimics the C directory structure. > The CMake build tree can then be uploaded the same way. I have only seen the CMake generation in Pharo and this single commit but from my point of view the VM and the CMake code seems very different: * The VM code is Smalltalk code and primarily developed with the simulator(?). We do not have a CMake simulator and I think it would not help to build one (the issues to expect are different compiler versions, flags, include paths, libraries, etc.) * The VM code is Smalltalk code as it provides a high level of abstraction. At least with the CMake generation in the PharoVM the level of abstraction is string concatenation. One CMakeLists.txt to target Unix and Windows will probably be _smaller_ than the Smalltalk subclasses (and metadata) to generate the variants. We can look at webkit, I think their cmake system targets {Gtk, EFL}x{OSX, Linux, FreeBSD, Windows, Haiku}x{x86, amd64, mips, ARMv5, THUMB2}x{tons of options}. With Pharo I felt the actual difference between building for Linux and FreeBSD was smaller than the amount of code (inheritance hierarchy, etc) needed in Smalltalk (and disabling X11 is no attribute of FreeBSD) * The VM code is debugged in Smalltalk (through the Simulator) while cmake will be trial-and-errored on the actual build environment ($EDITOR CMakeLists.txt CTRL+Z make fg repeat). Only if that works the change will be fed back into the image and then one needs to check if it generated the same CMakeLists.txt as the one, one edited by hand and then try again. > The model for the CMakeLists.txt is taken directly from Ian's code. Stated differently, Ian's CMake code is stored in Smalltalk. In 2014/2015 I built the PharoVM on FreeBSD and the pain came from fighting with the code in the image and not cmake itself. Make it possible to generate the source in one directory and compile it in another. https://github.com/pharo-project/pharo-vm/commit/4ee7ca5666b74e0540ad75dd6350db33ffc04e7f Add/Fix FreeBSD generator and disable X11 backend (not included in the 32bit compat and not necessary for my server deployment). https://github.com/pharo-project/pharo-vm/commit/216f47df008d0f73d24519bc3025ed15f605653f > 480 distinct build configurations that need supporting. yeah that is a lot but I think the memory managers, the type (debug, assert, release, etc) and stack/cog can be managed as options with a single cmake file? > IF the community decides that it is EASIER to work with just CMake Scripts and maintain those by hand, I am fine with that. > If the community decides that it is BETTER to store them in Smalltalk, I am fine with that too. sure. have a nice week holger From dionisiydk at gmail.com Tue Jun 21 09:05:42 2016 From: dionisiydk at gmail.com (Denis Kudriashov) Date: Tue Jun 21 09:06:03 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? Message-ID: Hi. Maybe I am super stupid. But I just tried to find new GitHub repository for VM and I can't. Of course I found it here but Google and GitHub not show me any results. At least GitHub surprised me. Is anything correct with repo settings? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/300daa39/attachment.htm From dionisiydk at gmail.com Tue Jun 21 09:08:16 2016 From: dionisiydk at gmail.com (Denis Kudriashov) Date: Tue Jun 21 09:08:38 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: Message-ID: And another question. Is Travis build server public? Where to find it? 2016-06-21 11:05 GMT+02:00 Denis Kudriashov : > Hi. > > Maybe I am super stupid. But I just tried to find new GitHub repository > for VM and I can't. > Of course I found it here but Google and GitHub not show me any results. > At least GitHub surprised me. Is anything correct with repo settings? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/56ab9fca/attachment.htm From kilon.alios at gmail.com Tue Jun 21 09:31:38 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Tue Jun 21 09:31:50 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: Message-ID: Sorry to reply with a stupid question but what is OpenSmalltalk ? First time I read about it. On Tue, Jun 21, 2016 at 12:08 PM Denis Kudriashov wrote: > > And another question. Is Travis build server public? Where to find it? > > 2016-06-21 11:05 GMT+02:00 Denis Kudriashov : > >> Hi. >> >> Maybe I am super stupid. But I just tried to find new GitHub repository >> for VM and I can't. >> Of course I found it here but Google and GitHub not show me any results. >> At least GitHub surprised me. Is anything correct with repo settings? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/134fee68/attachment.htm From pbpublist at gmail.com Tue Jun 21 09:35:03 2016 From: pbpublist at gmail.com (Phil (list)) Date: Tue Jun 21 09:35:08 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: Message-ID: <1466501703.2453.6.camel@gmail.com> On Tue, 2016-06-21 at 11:05 +0200, Denis Kudriashov wrote: > ? > Hi. > > Maybe I am super stupid. But I just tried to find new GitHub > repository for VM and I can't.? > Of course I found it here but Google and GitHub not show me any > results. > At least GitHub surprised me. Is anything correct with repo settings? Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result with Google. ?Since it's a new repo, perhaps it's still being added to the indexes and/or propagating out through their infrastructure and/or their algorithms are still deciding where it fits in the search results? ?GitHub can also take several days before new projects can be found via their search. From dionisiydk at gmail.com Tue Jun 21 09:37:32 2016 From: dionisiydk at gmail.com (Denis Kudriashov) Date: Tue Jun 21 09:37:53 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: <1466501703.2453.6.camel@gmail.com> References: <1466501703.2453.6.camel@gmail.com> Message-ID: 2016-06-21 11:35 GMT+02:00 Phil (list) : > Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result > with Google. Since it's a new repo, perhaps it's still being added to > the indexes and/or propagating out through their infrastructure and/or > their algorithms are still deciding where it fits in the search > results? GitHub can also take several days before new projects can be > found via their search. > Ok. I just checked that there is no incident option "not searchable" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/a40b8bf5/attachment.htm From kilon.alios at gmail.com Tue Jun 21 09:38:35 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Tue Jun 21 09:38:48 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: <1466501703.2453.6.camel@gmail.com> References: <1466501703.2453.6.camel@gmail.com> Message-ID: ah ok i see now, actually you will get empty results in the search because github searches for repo first openSmalltalk is not the name of a repo its the name of the user so you have to click to user and it will it to you so its both found by google and github On Tue, Jun 21, 2016 at 12:35 PM Phil (list) wrote: > > On Tue, 2016-06-21 at 11:05 +0200, Denis Kudriashov wrote: > > > > Hi. > > > > Maybe I am super stupid. But I just tried to find new GitHub > > repository for VM and I can't. > > Of course I found it here but Google and GitHub not show me any > > results. > > At least GitHub surprised me. Is anything correct with repo settings? > > Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result > with Google. Since it's a new repo, perhaps it's still being added to > the indexes and/or propagating out through their infrastructure and/or > their algorithms are still deciding where it fits in the search > results? GitHub can also take several days before new projects can be > found via their search. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/978e7490/attachment-0001.htm From estebanlm at gmail.com Tue Jun 21 10:08:08 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Tue Jun 21 10:08:13 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: Message-ID: <705BF4CC-1A69-4E10-A295-ABF2EACC71DB@gmail.com> is the new repository for the vm > On 21 Jun 2016, at 11:31, Dimitris Chloupis wrote: > > Sorry to reply with a stupid question but what is OpenSmalltalk ? First time I read about it. > > On Tue, Jun 21, 2016 at 12:08 PM Denis Kudriashov > wrote: > > And another question. Is Travis build server public? Where to find it? > > 2016-06-21 11:05 GMT+02:00 Denis Kudriashov >: > Hi. > > Maybe I am super stupid. But I just tried to find new GitHub repository for VM and I can't. > Of course I found it here but Google and GitHub not show me any results. > At least GitHub surprised me. Is anything correct with repo settings? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/f680e099/attachment.htm From gettimothy at zoho.com Tue Jun 21 10:39:41 2016 From: gettimothy at zoho.com (gettimothy) Date: Tue Jun 21 10:39:47 2016 Subject: [Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz In-Reply-To: <80C140AF-B1F7-4230-9D73-2C873B9156EF@freyther.de> References: <5B8EFC0A-1CB4-4BE7-B56F-121259599F97@freyther.de> <155704402c1.12b326a72124292.3735289149539011470@zoho.com> <80C140AF-B1F7-4230-9D73-2C873B9156EF@freyther.de> Message-ID: <155728b5453.b1be3302126775.5920584545949144377@zoho.com> Hi Holger, Good morning. I have only seen the CMake generation in Pharo and this single commit but from my point of view the VM and the CMake code seems very different: * The VM code is Smalltalk code and primarily developed with the simulator(?). We do not have a CMake simulator and I think it would not help to build one (the issues to expect are different compiler versions, flags, include paths, libraries, etc.) Yes and agreed. * The VM code is Smalltalk code as it provides a high level of abstraction. At least with the CMake generation in the PharoVM the level of abstraction is string concatenation. The Pharo code, yes. I found no benefit in string concatenation, and I found it needlessly confusing....so...I forked the project to use CMakeTemplates instead. CMakeTemplates are wrapper objects around CMake constructs--string concatenation and command output is handled by the template If you have ever programmed in Seaside, you know how easy it is to use Templates (The Seaside idiom is Components) to compose web-pages. Templates are objects that wrap CMake commands/etc. Generating valid CMake is now a matter of adding CMakeTemplates to a collection then asking those templates to write their content to a stream. For the programmer, the debugging is very easy and the composing is very intuitive. There is no string concatenation on the developer's part. In 2014/2015 I built the PharoVM on FreeBSD and the pain came from fighting with the code in the image and not cmake itself. Two points. 1. the current Smalltalk code is too complicated to maintain for a newbie. I am currently working on a Terse Help Topic for setting up a "linux 64x64 squeak.cog.spur build " component. With the release of the Terse guide, I will be in an "official" alpha release. I believe a goal should be to radically trim and normalize the CMake generation part of the framework. The current generation is handled in about 3 places with the bulk in VMGenerator>>generateBytemplate: NO PAIN is the goal. CMake DRIVES THE PROCESS is the MOTTO. 2 Here is what I am seeing from my work writing the documentation. There appear to be about generic steps. 1 Identify your platform and base configuration 2. Subclass it. 3. Set up directory paths 4. Set up Compiler Flags (-g -01 5. Set up Linker flags (now -foo) 6. Set up Compiler Directives (-D FOO -D BAR 7. Set up librarires 8 . Choose plugins 9. Generate CMake. 10 Debug CMake. The Generators have debugging tracers in them to identify where the generated CMake code was written from-- SqueakLinux64x86w32CompatBuilder <-Platform specific facade to the configurations configureA: #Linux64x86w32BitSqueakCogSpurConfig forBuildType:#build; <-each configuration can handle all build types (if they are coded, just set different flags based on #buildType and the code architecture should invoke the correct ones for the build) enableMessageTracking: true; <-toggle debugging messages generateByTemplate. <-collect and output using the CMakeTemplates The command above generates CMake that builds a working CMake build tree parallel to the existing build tree that generates a working squeak.cog.spur vm. Once these are setup, and (I hope and think) with the documentation in place, adding an entirely different platform or tweaking an existing platform should be less than 1/2 hour job. Make it possible to generate the source in one directory and compile it in another. https://github.com/pharo-project/pharo-vm/commit/4ee7ca5666b74e0540ad75dd6350db33ffc04e7f Done. The CMakeVMMaker for squeak generates a parallel structure on the fly to the existing oscogvm tree. for example: build.linux64/foo becomes cmake.build.linux64/foo w/ no changes to the existing stuff. Similarly the "products" directory becomes "cmake.products" again, parallel to the existing structure. Add/Fix FreeBSD generator and disable X11 backend (not included in the 32bit compat and not necessary for my server deployment). https://github.com/pharo-project/pharo-vm/commit/216f47df008d0f73d24519bc3025ed15f605653f My solution is, subclass an existing 32Bit compat Configuration. Override one method (whatever tells the compiler to not build in X11) Override another that tells what plugins to use. It automatically supports all buildTypes the parent has I think a good addition would be options to tell a Configuration what additional or new "flags" it should use Something like: SqueakLinux64x86w32CompatBuilder configureA: #Linux64x86w32BitSqueakCogSpurConfig forBuildType:#build; withoutPlugin: "X11" AddCFlags: #(...) RemoveCFlags: #(...) etc... enableMessageTracking: true; generateByTemplate. (This would be an awesome feature) I will add it to my todo list. cheers, tty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/e5fae856/attachment.htm From btc at openinworld.com Tue Jun 21 10:46:45 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 21 10:47:10 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> Message-ID: On Tue, Jun 21, 2016 at 5:38 PM, Dimitris Chloupis wrote: > > ah ok i see now, actually you will get empty results in the search because github searches for repo first > > openSmalltalk is not the name of a repo its the name of the user so you have to click to user and it will it to you > > so its both found by google and github Ahh. Thats quite an insight that I hadn't noticed before. Also the first 8 results searching github for "vm" are 8 different projects. One of the reasons for moving to github is get more visibility. I'm afraid like this that we'll be lost in the noise. Actually when I made my fork of the repo, I'd noticed the project seemed to lose its identity as... https://github.com/bencoman/vm but I didn't worry to much about it since "I" knew what it was. But confusion in the public arena on github is more serious. Since its still quite early days on github, can I ask consideration be given to renaming the repo so we have... https://github.com/OpenSmalltalk/opensmalltalk-vm https://github.com/bencoman/opensmalltalk-vm That it will show up in both searches for "smalltalk" and "vm" I think this is important to getting the most long term value out git & github. cheers -ben > > On Tue, Jun 21, 2016 at 12:35 PM Phil (list) wrote: >> >> >> On Tue, 2016-06-21 at 11:05 +0200, Denis Kudriashov wrote: >> > >> > Hi. >> > >> > Maybe I am super stupid. But I just tried to find new GitHub >> > repository for VM and I can't. >> > Of course I found it here but Google and GitHub not show me any >> > results. >> > At least GitHub surprised me. Is anything correct with repo settings? >> >> Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result >> with Google. Since it's a new repo, perhaps it's still being added to >> the indexes and/or propagating out through their infrastructure and/or >> their algorithms are still deciding where it fits in the search >> results? GitHub can also take several days before new projects can be >> found via their search. > > From btc at openinworld.com Tue Jun 21 10:55:09 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 21 10:55:34 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> Message-ID: On Tue, Jun 21, 2016 at 6:46 PM, Ben Coman wrote: > On Tue, Jun 21, 2016 at 5:38 PM, Dimitris Chloupis > wrote: >> >> ah ok i see now, actually you will get empty results in the search because github searches for repo first >> >> openSmalltalk is not the name of a repo its the name of the user so you have to click to user and it will it to you >> >> so its both found by google and github > > Ahh. Thats quite an insight that I hadn't noticed before. Also the > first 8 results searching github for "vm" are 8 different projects. > One of the reasons for moving to github is get more visibility. I'm > afraid like this that we'll be lost in the noise. > > Actually when I made my fork of the repo, I'd noticed the project > seemed to lose its identity as... > https://github.com/bencoman/vm > but I didn't worry to much about it since "I" knew what it was. But > confusion in the public arena on github is more serious. > > Since its still quite early days on github, can I ask consideration be > given to renaming the repo so we have... > https://github.com/OpenSmalltalk/opensmalltalk-vm > https://github.com/bencoman/opensmalltalk-vm > That it will show up in both searches for "smalltalk" and "vm" > I think this is important to getting the most long term value out git & github. Github help pages indicate existing infrastructure should continue to work to the old name, easing the transition. https://help.github.com/articles/renaming-a-repository/ For authorised users, this should link where the rename can be done.. https://github.com/OpenSmalltalk/vm/settings cheers -ben > > cheers -ben > >> >> On Tue, Jun 21, 2016 at 12:35 PM Phil (list) wrote: >>> >>> >>> On Tue, 2016-06-21 at 11:05 +0200, Denis Kudriashov wrote: >>> > >>> > Hi. >>> > >>> > Maybe I am super stupid. But I just tried to find new GitHub >>> > repository for VM and I can't. >>> > Of course I found it here but Google and GitHub not show me any >>> > results. >>> > At least GitHub surprised me. Is anything correct with repo settings? >>> >>> Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result >>> with Google. Since it's a new repo, perhaps it's still being added to >>> the indexes and/or propagating out through their infrastructure and/or >>> their algorithms are still deciding where it fits in the search >>> results? GitHub can also take several days before new projects can be >>> found via their search. >> >> From kilon.alios at gmail.com Tue Jun 21 11:42:44 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Tue Jun 21 11:42:57 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> Message-ID: Github wont give you automagically visibility, there 2 criteria you have to satisfy 1) you have to contribute some code in smalltalk so it appears as smalltalk 2) you have to add a sensible description that mentions smalltalk in some way The VM satisfies neither of those 2 criteria hence its not visible as Smalltalk but it is visible as C project. By the way if you want find smalltalk projects , enter the words relevant to your search and then add language:Smalltalk this will force to Github to search projects that either contain Smalltalk source files or that mention in the description you can also use the explore feature of github to see which Smalltalk projects are trending https://github.com/trending/smalltalk So as you can see yes the visibility is crystal clear for those that want to find Smalltalk projects. Its easy, its simple and its fast. On Tue, Jun 21, 2016 at 1:47 PM Ben Coman wrote: > > On Tue, Jun 21, 2016 at 5:38 PM, Dimitris Chloupis > wrote: > > > > ah ok i see now, actually you will get empty results in the search > because github searches for repo first > > > > openSmalltalk is not the name of a repo its the name of the user so you > have to click to user and it will it to you > > > > so its both found by google and github > > Ahh. Thats quite an insight that I hadn't noticed before. Also the > first 8 results searching github for "vm" are 8 different projects. > One of the reasons for moving to github is get more visibility. I'm > afraid like this that we'll be lost in the noise. > > Actually when I made my fork of the repo, I'd noticed the project > seemed to lose its identity as... > https://github.com/bencoman/vm > but I didn't worry to much about it since "I" knew what it was. But > confusion in the public arena on github is more serious. > > Since its still quite early days on github, can I ask consideration be > given to renaming the repo so we have... > https://github.com/OpenSmalltalk/opensmalltalk-vm > https://github.com/bencoman/opensmalltalk-vm > That it will show up in both searches for "smalltalk" and "vm" > I think this is important to getting the most long term value out git & > github. > > cheers -ben > > > > > On Tue, Jun 21, 2016 at 12:35 PM Phil (list) > wrote: > >> > >> > >> On Tue, 2016-06-21 at 11:05 +0200, Denis Kudriashov wrote: > >> > > >> > Hi. > >> > > >> > Maybe I am super stupid. But I just tried to find new GitHub > >> > repository for VM and I can't. > >> > Of course I found it here but Google and GitHub not show me any > >> > results. > >> > At least GitHub surprised me. Is anything correct with repo settings? > >> > >> Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result > >> with Google. Since it's a new repo, perhaps it's still being added to > >> the indexes and/or propagating out through their infrastructure and/or > >> their algorithms are still deciding where it fits in the search > >> results? GitHub can also take several days before new projects can be > >> found via their search. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/e784c4e6/attachment.htm From btc at openinworld.com Tue Jun 21 12:02:29 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 21 12:02:52 2016 Subject: [Vm-dev] git mavens, shortcut please? In-Reply-To: References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: Update for people working from a forked repository... (btw a tip, try using tab completion for repo names:) On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman wrote: > On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge wrote: >> >> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works > 1. Go to https://github.com/OpenSmalltalk/vm 1b. Click the button in the top right. You'll then be looking at https://github.com/YOURNAME/vm > 2. Click the green button. > (If you've already set up your SSH keys, click "Use SSH".) > then copy the url to the clipboard. > > 3. Clone to your local machine > $ git clone #paste-url-from-the-clipboard-here > $ cd vm # or opensmalltalk-vm if official repo is renamed > $ git remote -v > origin git@github.com:OpenSmalltalk/vm.git (fetch) > origin git@github.com:OpenSmalltalk/vm.git (push) > or... > origin https://github.com/OpenSmalltalk/vm.git (fetch) > origin https://github.com/OpenSmalltalk/vm.git (push) > ...depending on ssh or https clone respectively > 3b. Additionally, set up quick reference to the upstream repository $ git remote add OpenSmalltalk https://github.com/OpenSmalltalk/vm $ git remote -v OpenSmalltalk https://github.com/OpenSmalltalk/vm (fetch) OpenSmalltalk https://github.com/OpenSmalltalk/vm (push) origin git@github.com:bencoman/vm.git (fetch) origin git@github.com:bencoman/vm.git (push) > 4. Create a branch to work on... > $ git fetch #updates all branches to latest > $ git checkout -b SomeBug Cog 4. Instead, now do... $ git fetch OpenSmalltalk $ git checkout -b ABug OpenSmalltalk/Cog Good to create server repo straight away to avoid later "no upstream branch" error $ git push -u origin $ git branch --all # oldTrunk & plugin branches not shown for clarity * ABug Cog master remotes/OpenSmalltalk/Cog remotes/OpenSmalltalk/master remotes/origin/ABug remotes/origin/Cog remotes/origin/HEAD -> origin/Cog remotes/origin/master > 5. Edit, compile, test cycle. Commit often along the way. > * make required changes > $ git stage -u > $ git diff ; git diff HEAD > $ git commit -m "SomeBug - part way there" > Repeat as necessary > > 6. Ready to submit. Clean up *local* history (since we committed quite often) > $ git rebase -i # Squash inconsequential commits. Rebase is > okay before publishing. > Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ > https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview > > 7. Catch up to official Cog branch > $ git fetch # updates origin/* > $ git log HEAD..origin/Cog # review other updates > $ git diff origin/Cog # review other updates > Depending on whether the final history should be linear (more like SVN??) > $ git rebase origin/Cog # rebase okay since not yet published > or show the branching... > $ get merge origin/Cog > ...might depend on whether its a small fix or a larger feature added. 7. Instead now do... $ git fetch OpenSmalltalk $ dit diff OpenSmalltalk/Cog $ git rebase OpenSmalltalk/Cog or... $ git merge OpenSmalltalk/Cog > 8. Submit for review > $ git push # to server > You will see... > fatal: The current branch SomeBug has no upstream branch. > which is because the SomeBug branch only exists locally, not on the > github server. The following creates the branch on the "origin" server > and sets things so subsequently this branch only requires "git push". > $ git push --set-upstream origin SomeBug > * On github, from the pulldown button, select your SomeBug branch. > * Click button. For more detail refer... > https://help.github.com/articles/using-pull-requests/ > > (In the meantime, work on some other branch) > > 7. Reviewers can download PR to test locally as described here... > https://help.github.com/articles/checking-out-pull-requests-locally/ > (though I've not done that since I've not been on the receiving side > of a pull request before) > > 8. Respond to reviewer comments. Edit, compile, test, resubmit. > $ git checkout SomeBug > * make required changes > $ git stage -u > $ git commit -m "changed per feedback " > $ git push # Pull request auto updated > (Repeat as required) > > 9. Pull request acceptable. Optionally (and some policy discussion > required) squash changes from review period. > $ git rebase -i > $ git push -f > Note this does rewrite the history of the published SomeBug branch, > but presumably the branch is thrown away after integration so no real > foul. But forcing pushing may be risk for accidentally doing it to > the Cog or master branches. (btw, has the force protection on those > two branches been tested?) > > 10. On github, integrator accepts pull request. > > 11. Delete branch. cheers -ben From lewis at mail.msen.com Tue Jun 21 12:22:40 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Jun 21 12:22:42 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: <20160621122240.GA93611@shell.msen.com> Tim, Thank you for posting CONTRIBUTING.md, that seems to provide a very good overview. Dave On Mon, Jun 20, 2016 at 11:55:13AM +0200, Tim Felgentreff wrote: > > I've pushed a CONTRIBUTING.md to the repository that we can iterate > over and discuss. > > If you go to https://github.com/OpenSmalltalk/vm/commit/5052e307fda0369f04550966fcfdf0a372aeaf39 > you can leave comments inline or at the end. > > On 19 June 2016 at 02:01, Eliot Miranda wrote: > > > > Hi All, > > > > fixing callbacks on x64 and so too lazy/focussed elsewhere to check whether I should be pushing after each commit. What is the right process for uploading changes to OpenSmalltalk/vm? > > _,,,^..^,,,_ > > best, Eliot > > From maxleske at gmail.com Tue Jun 21 13:28:05 2016 From: maxleske at gmail.com (Max Leske) Date: Tue Jun 21 13:28:08 2016 Subject: [Vm-dev] Re: System and user processe In-Reply-To: <57692dc3.0480370a.e93a2.4ec8SMTPIN_ADDED_MISSING@mx.google.com> References: <57692dc3.0480370a.e93a2.4ec8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <68292823-0680-4CB8-BA4D-872A20F76B4B@gmail.com> > Max Leske wrote >> Hi, >> >> In Pharo and Squeak we have no separation between processes that belong to >> the IDE, tools etc. and processes that are spawned as part of an >> application. I?d like to know your opinion on the following (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and UserProcess >> 2. We define #isSystemProcess and #isUserProcess >> 3. We introduce #newSystemProcess and #newUserProcess >> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby >> modifying all users of #forkXXX to yield instances of UserProcess) >> >> Of the following I?m less sure: >> 5. We introduce #forkSystemProcess et. al >> >> I?ve tried this out in Pharo 6 and there seem to be no problems with the >> VM. The benefit would be improved separation between system and user >> space. It would allow us to implement stuff for processes in general (e.g. >> for the debugger) which we do not want to affect system processes like the >> UI process or the background process. One concrete example: the process >> browser could hide all system processes and make them visible on demand >> (that would greatly improve the view because you can now better find your >> own processes). >> >> >> I?m looking forward to your comments. >> >> Cheers, >> Max > > Hi Max, > > I like the idea. Let's see... > > System processes in Squeak could be: > - the timer interrupt watcher > - the event tickler > - the low space watcher > - the user interrupt watcher > - the idle process > > I am not so sure about: > - the WeakArray finalization process (still needed for Ephemerons?) > > Then we have the UI framework(s). The frameworks' processes could be user > processes or system processes, too? Hmm... for Morphic, there is only one. > Stepping is implemented with the same UI process. Applications that spawn > other (user) processes work around Morphic anyway. > > Tweak uses (or used) many processes to execute scripts. So, the Tweak UI has > a set of related processes, not just a single UI process. > > MVC has only one process running but creates/terminates processes when > switching controllers. > > If you play a MIDI or a Sound, should that process also be a system process, > right? Hmm... > > Interactive debugging is tricky only with respect to the current UI > framework because you want to be able to also debug that frameworks code and > its applications. While writing the debugger in that framework, too. So, it > is above the level of processes but at the level of the UI framework (resp. > projects). At least in Squeak. > > Hmm... for a filter in the process browser, a simple flag would be enough. > No need to add subclasses. So, whout be the benefits of distinguishing > between UserProcess and SystemProcess at process creation time? How to > decide? Might it be related to additional warnings? Calling "Smalltalk > snapshot: true andQuit: true" from a process in an endless loop might be > detected if you do that from within a UserProcess. :-D > > Maybe introduce restrictions/warnings at the level of message dispatch for > UserProcesses? Hmm? You essentially get my point. For the process browser a flag would be enough, yes, but that?s not really OO, is it? :) Anyway, I see a couple of ?direct? benefits: - better implementation of user interrupt handling (user processes can always be interrupted) - kill all user processes (system will keep running) - different low space settings for system and user processes (yes, that would probably require a VM change, but still?) - system processes could be prevented from starving (e.g. a user process must yield at least every n milliseconds) ... > > Best, > Marcel > > From maxleske at gmail.com Tue Jun 21 13:35:25 2016 From: maxleske at gmail.com (Max Leske) Date: Tue Jun 21 13:35:32 2016 Subject: [Vm-dev] Re: System and user processe Message-ID: <1FBA226F-25E2-4BFE-A7DD-DAD4B3A985B4@gmail.com> > Hi Max, > > Perhaps a notion of process grouping might make sense? Following the > zero-one-infinity principle, having exactly two kinds of process seems a > bit odd. I agree. I just wanted to get the idea out there without proposing a complete POSIX process model. And I found it interesting that we actually could use subclasses without needing special support from the VM. > > Having process grouping would lead to a tree of processes. > > For example, the outermost level could be "system" processes, of which > one was a group containing all "user" processes. > > Or, the outermost level could have two children, one group of "system" > procs, one of "user" procs; or, ... > > The "current process group" would be a kind of dynamic parameter, and > newly-forked processes would by default become siblings of the forker in > the current group. > > Regards, > Tony I think that grouping makes a lot of sense. However, the current model has also served us well, maybe exactly because it is simple. Adding a lot of complexity will not necessarily make things better (especially for newcomers). Maybe there?s a middle ground where high level processes maintain a very simple API (like Chris proposed) and where you don?t have to know about process groups (those processes might just go into a default group, essentially what you describe with ?current process group"). Really not sure? Cheers, Max > > > > On 06/19/2016 05:03 AM, Max Leske wrote: > Hi, > > In Pharo and Squeak we have no separation between processes that > belong to the IDE, tools etc. and processes that are spawned as part > of an application. I?d like to know your opinion on the following > (rough) idea: > > 1. We introduce two subclasses of Process: SystemProcess and > UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We > introduce #newSystemProcess and #newUserProcess 4. We deprecate > #newProcess and delegate to #newUserProcess (thereby modifying all > users of #forkXXX to yield instances of UserProcess) > > Of the following I?m less sure: 5. We introduce #forkSystemProcess > et. al > > I?ve tried this out in Pharo 6 and there seem to be no problems with > the VM. The benefit would be improved separation between system and > user space. It would allow us to implement stuff for processes in > general (e.g. for the debugger) which we do not want to affect system > processes like the UI process or the background process. One concrete > example: the process browser could hide all system processes and make > them visible on demand (that would greatly improve the view because > you can now better find your own processes). > > > I?m looking forward to your comments. > > Cheers, Max From maxleske at gmail.com Tue Jun 21 13:37:31 2016 From: maxleske at gmail.com (Max Leske) Date: Tue Jun 21 13:37:34 2016 Subject: [Vm-dev] Re: System and user processe Message-ID: <2C326DF7-9D68-4F91-880B-3921B273599A@gmail.com> >> On 06/19/2016 05:03 AM, Max Leske wrote: >> Hi, >> >> In Pharo and Squeak we have no separation between processes that >> belong to the IDE, tools etc. and processes that are spawned as part >> of an application. I?d like to know your opinion on the following >> (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and >> UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We >> introduce #newSystemProcess and #newUserProcess 4. We deprecate >> #newProcess and delegate to #newUserProcess (thereby modifying all >> users of #forkXXX to yield instances of UserProcess) >> >> Of the following I?m less sure: 5. We introduce #forkSystemProcess >> et. al >> >> I?ve tried this out in Pharo 6 and there seem to be no problems with >> the VM. The benefit would be improved separation between system and >> user space. It would allow us to implement stuff for processes in >> general (e.g. for the debugger) which we do not want to affect system >> processes like the UI process or the background process. One concrete >> example: the process browser could hide all system processes and make >> them visible on demand (that would greatly improve the view because >> you can now better find your own processes). >> >> >> I?m looking forward to your comments. >> >> Cheers, Max >> >> >> >> On Tue, Jun 21, 2016 at 3:32 AM, Tony Garnock-Jones wrote: >> Hi Max, >> >> Perhaps a notion of process grouping might make sense? Following the >> zero-one-infinity principle, having exactly two kinds of process seems a >> bit odd. >> >> Having process grouping would lead to a tree of processes. >> >> For example, the outermost level could be "system" processes, of which >> one was a group containing all "user" processes. >> >> Or, the outermost level could have two children, one group of "system" >> procs, one of "user" procs; or, ... >> >> The "current process group" would be a kind of dynamic parameter, and >> newly-forked processes would by default become siblings of the forker in >> the current group. >> >> Regards, >> Tony > > This sounds like a good idea. It would make it easier for a user of > multiple applications in one image to properly kill one. For this > reason, perhaps there should be some impediment on apps adding > processes adding the System Process group(??) > > cheers -ben Yes. That?s why in my proposal the default is to create a user process. Cheers, Max From maxleske at gmail.com Tue Jun 21 13:46:37 2016 From: maxleske at gmail.com (Max Leske) Date: Tue Jun 21 13:46:43 2016 Subject: [Vm-dev] Re: System and user processe Message-ID: <388BD9D2-8BF2-47E4-BBBD-4BBB0380D1F2@gmail.com> >> Message: 17 >> Date: Tue, 21 Jun 2016 00:33:17 -0700 (PDT) >> From: "marcel.taeumel" >> Subject: [squeak-dev] Re: [Vm-dev] System and user processes >> To: squeak-dev@lists.squeakfoundation.org >> Message-ID: <1466494397918-4902025.post@n4.nabble.com> >> Content-Type: text/plain; charset=UTF-8 >> >> Chris Muller-3 wrote >> Hi Max, I had a similar idea, and made a ClientProcess class. Its >> primary purpose is to provide a nice wrapping API for *users* to >> manage their "background running tasks" (i.e., #start, #stop, #pause, >> #resume, #progress, #priority adjustment), as well as a nice API for >> *developers* to report its progress via a simple signaling mechanism, >> which also gives the user all the performance stats for "free" too >> like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime, >> etc. >> >> On Sun, Jun 19, 2016 at 4:03 AM, Max Leske < >> >> maxleske@ >> >> > wrote: >> >> Hi, >> >> In Pharo and Squeak we have no separation between processes that belong >> to the IDE, tools etc. and processes that are spawned as part of an >> application. I?d like to know your opinion on the following (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and UserProcess >> 2. We define #isSystemProcess and #isUserProcess >> 3. We introduce #newSystemProcess and #newUserProcess >> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby >> modifying all users of #forkXXX to yield instances of UserProcess) >> >> Of the following I?m less sure: >> 5. We introduce #forkSystemProcess et. al >> >> I?ve tried this out in Pharo 6 and there seem to be no problems with the >> VM. The benefit would be improved separation between system and user >> space. It would allow us to implement stuff for processes in general >> (e.g. for the debugger) which we do not want to affect system processes >> like the UI process or the background process. One concrete example: the >> process browser could hide all system processes and make them visible on >> demand (that would greatly improve the view because you can now better >> find your own processes). >> >> >> I?m looking forward to your comments. >> >> Cheers, >> Max > > Hi Chris, > > Hmm... I would implement such an API rather via composition than > inheritance. Such a task does not necessarily have to run in the same image > but could also be accomplished on another machine. OSProcess has RemoteTask > for this. Inheritance would make things complicated once one would decide to > not carry out the computation as a Squeak process. > > I do like Tony's idea of process groups. We could think this one step > further an add multiple tags (symbols?) to processes to support > fine-granular or cross-cutting classifications. Tools like the process > browser could show these tags, group by them, etc. There could be tags to > identify processes that would stop working once you close the Squeak image > (e.g. "not resumable")... Hmmm... Application developers could use tags to > provide hints for other developers and users. > > Best, > Marcel Good point. Inheritance is nice but as for our infamous stream hierarchy processes would probably need to be grouped by different traits. But I think that groups and tags may be two different things. Tony?s ?current process group? for instance would have to implemented as a special tag already, unless a new process simply inherited all tags. In Pharo (I don?t know about Squeak) we now have a session manager that can be asked if the current session has changed, i.e. whether the image has been restarted. Now, instead of checking in with the session manager explicitly I could use a ?session dependant? process, which terminates when the session changes. Cheers, Max From lauraperezcerrato at gmail.com Tue Jun 21 14:11:28 2016 From: lauraperezcerrato at gmail.com (Laura Perez Cerrato) Date: Tue Jun 21 14:11:50 2016 Subject: [Vm-dev] The code in the src folders in the repository Message-ID: Hi everyone, Excuse me if this has been asked already or it's documented somewhere and I missed it, but what's the criteria to update the code in /src, /stacksrc, /spursrc and other similar folders in the repository? -Laura Perez Cerrato -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/9ce91847/attachment.htm From craig at blackpagedigital.com Tue Jun 21 14:55:14 2016 From: craig at blackpagedigital.com (Craig Latta) Date: Tue Jun 21 14:55:27 2016 Subject: [Vm-dev] re: git mavens, shortcut please? In-Reply-To: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> References: <23966E4A-C46F-445B-A0A6-4F4AB3618F0A@rowledge.org> Message-ID: Hi Tim-- > Actually, calling all git mavens - please, please, point the rest of > us to some documentation that might possibly be understood by humans. Definitely read the fine documentation others have mentioned, but also try one of the decent visual interfaces for git, such as SourceTree[1]. -C [1] https://www.sourcetreeapp.com -- Craig Latta Black Page Digital Amsterdam craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From asqueaker at gmail.com Tue Jun 21 15:37:04 2016 From: asqueaker at gmail.com (Chris Muller) Date: Tue Jun 21 15:37:47 2016 Subject: [Vm-dev] Re: [squeak-dev] Re: System and user processe In-Reply-To: <388BD9D2-8BF2-47E4-BBBD-4BBB0380D1F2@gmail.com> References: <388BD9D2-8BF2-47E4-BBBD-4BBB0380D1F2@gmail.com> Message-ID: >> Hmm... I would implement such an API rather via composition than >> inheritance. Such a task does not necessarily have to run in the same image >> but could also be accomplished on another machine. OSProcess has RemoteTask >> for this. Inheritance would make things complicated once one would decide to >> not carry out the computation as a Squeak process. It is implemented via composition, not inheritance. Maybe it is name, ClientProcess, that made you assume it is a subclass of Process..? It is not. :) >> I do like Tony's idea of process groups. We could think this one step >> further an add multiple tags (symbols?) to processes to support >> fine-granular or cross-cutting classifications. > >Tools like the process >> browser could show these tags, group by them, etc. There could be tags to >> identify processes that would stop working once you close the Squeak image >> (e.g. "not resumable")... Hmmm... Application developers could use tags to >> provide hints for other developers and users. Processes already have names, which could facilitate a hierarchical naming if someone wanted, and list filtering in the Process browser would make "grouping" or "finding" a Process pretty much free.. If all you want to do is tag and group processes, I would consider putting them into named groups/containers rather than add more process-level attributes.. From norbert at hartl.name Tue Jun 21 19:39:41 2016 From: norbert at hartl.name (Norbert Hartl) Date: Tue Jun 21 19:39:49 2016 Subject: [Vm-dev] Re: [Pharo-dev] [squeak-dev] Re: System and user processe In-Reply-To: References: <388BD9D2-8BF2-47E4-BBBD-4BBB0380D1F2@gmail.com> Message-ID: Am 21.06.2016 um 17:37 schrieb Chris Muller : >>> Hmm... I would implement such an API rather via composition than >>> inheritance. Such a task does not necessarily have to run in the same image >>> but could also be accomplished on another machine. OSProcess has RemoteTask >>> for this. Inheritance would make things complicated once one would decide to >>> not carry out the computation as a Squeak process. > > It is implemented via composition, not inheritance. > > Maybe it is name, ClientProcess, that made you assume it is a subclass > of Process..? It is not. :) > >>> I do like Tony's idea of process groups. We could think this one step >>> further an add multiple tags (symbols?) to processes to support >>> fine-granular or cross-cutting classifications. >>> Tools like the process >>> browser could show these tags, group by them, etc. There could be tags to >>> identify processes that would stop working once you close the Squeak image >>> (e.g. "not resumable")... Hmmm... Application developers could use tags to >>> provide hints for other developers and users. > > Processes already have names, which could facilitate a hierarchical > naming if someone wanted, and list filtering in the Process browser > would make "grouping" or "finding" a Process pretty much free.. > > If all you want to do is tag and group processes, I would consider > putting them into named groups/containers rather than add more > process-level attributes.. > That is exactly what I was thinking Norbert From eliot.miranda at gmail.com Tue Jun 21 20:08:17 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 21 20:08:22 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions Message-ID: Hi All, recent changes, I *think* to updateSCCSVersions, have broken platforms/Cross/vm/sqSCCSVersion.h: static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin) tim/deployment-fixes new (next fetch will store in remotes/origin) $"; First, multi-liner string constants must be terminated with a backslash to compile. So at the very least we'd need static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm\ SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin)\ tim/deployment-fixes new (next fetch will store in remotes/origin) $"; But second, multi-line output doesn't make sense here. We need something that fits on a single line. Who is going to fix this? I have a production build which is broken because of this. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/f35faeed/attachment-0001.htm From Das.Linux at gmx.de Tue Jun 21 20:37:43 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Jun 21 20:37:44 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: Message-ID: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Hi Eliot, On 21.06.2016, at 22:08, Eliot Miranda wrote: > Hi All, > > recent changes, I *think* to updateSCCSVersions, have broken platforms/Cross/vm/sqSCCSVersion.h: > > static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm > SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin) > tim/deployment-fixes new (next fetch will store in remotes/origin) $"; This is due to the line you added in .git_filters/RevDateURL.smudge: if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: //' 2>/dev/null` } Problem being, the two lines match 'fetch' (next _fetch_ will store in ...), so you get more than the actual URL. However, this has been fixed already, the current version from 24198c6 (see https://github.com/OpenSmalltalk/vm/commits/Cog/.git_filters/RevDateURL.smudge) has changed and does not suffer from the grep. Relevant lines: if ((defined $ENV{'TRAVIS'}) || (defined $ENV{'APPVEYOR'})) { $url=`git config --get remote.origin.url`; } else { $url=`whoami` . '@' . `hostname` . ':' . `PWD=\$(pwd) echo \${PWD##\$HOME/}`; } Is your repo up to date? Best regards -Tobias > > First, multi-liner string constants must be terminated with a backslash to compile. So at the very least we'd need > > static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm\ > SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin)\ > tim/deployment-fixes new (next fetch will store in remotes/origin) $"; > > But second, multi-line output doesn't make sense here. We need something that fits on a single line. Who is going to fix this? I have a production build which is broken because of this. > > _,,,^..^,,,_ > best, Eliot From eliot.miranda at gmail.com Tue Jun 21 21:37:24 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 21 21:37:28 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: Hi Tobias, On Tue, Jun 21, 2016 at 1:37 PM, Tobias Pape wrote: > > Hi Eliot, > > On 21.06.2016, at 22:08, Eliot Miranda wrote: > > > Hi All, > > > > recent changes, I *think* to updateSCCSVersions, have broken > platforms/Cross/vm/sqSCCSVersion.h: > > > > static char SvnRawRepositoryURL[] = "$URL: > http://github.com/OpenSmalltalk/vm > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in > remotes/origin) > > tim/deployment-fixes new (next fetch will store in > remotes/origin) $"; > > This is due to the line you added in .git_filters/RevDateURL.smudge: > > > if (!$url) { $url=`git remote show origin | grep -i fetch | sed > 's/^.*URL: //' 2>/dev/null` } > > Problem being, the two lines match 'fetch' (next _fetch_ will store in > ...), so you get more than the actual URL. > > However, this has been fixed already, the current version from 24198c6 > (see > https://github.com/OpenSmalltalk/vm/commits/Cog/.git_filters/RevDateURL.smudge) > has changed > and does not suffer from the grep. Relevant lines: > > > if ((defined $ENV{'TRAVIS'}) || (defined $ENV{'APPVEYOR'})) { > $url=`git config --get remote.origin.url`; > } else { > $url=`whoami` . '@' . `hostname` . ':' . `PWD=\$(pwd) echo > \${PWD##\$HOME/}`; > } > Thanks. So it was me :-(. Good to know. > Is your repo up to date? > How do I know? This "fetch and then diff" method is IMO broken. I simply want to know whether there are incoming commits /before/ I do a fetch. > > > Best regards > -Tobias > > > > > First, multi-liner string constants must be terminated with a backslash > to compile. So at the very least we'd need > > > > static char SvnRawRepositoryURL[] = "$URL: > http://github.com/OpenSmalltalk/vm\ > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in > remotes/origin)\ > > tim/deployment-fixes new (next fetch will store in > remotes/origin) $"; > > > > But second, multi-line output doesn't make sense here. We need > something that fits on a single line. Who is going to fix this? I have a > production build which is broken because of this. > > > > _,,,^..^,,,_ > > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/f8f76d40/attachment.htm From holger at freyther.de Tue Jun 21 21:42:22 2016 From: holger at freyther.de (Holger Freyther) Date: Tue Jun 21 21:42:24 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: > On 21 Jun 2016, at 23:37, Eliot Miranda wrote: > Hi Eliot, > How do I know? This "fetch and then diff" method is IMO broken. I simply want to know whether there are incoming commits /before/ I do a fetch. "fetch" will just update your remote (origin by default). Do you know "git ls-remote origin", is that closer to what you want? holger From Das.Linux at gmx.de Tue Jun 21 21:54:19 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Jun 21 21:54:20 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: On 21.06.2016, at 23:37, Eliot Miranda wrote: > Hi Tobias, > > On Tue, Jun 21, 2016 at 1:37 PM, Tobias Pape wrote: > > Hi Eliot, > > On 21.06.2016, at 22:08, Eliot Miranda wrote: > > > Hi All, > > > > recent changes, I *think* to updateSCCSVersions, have broken platforms/Cross/vm/sqSCCSVersion.h: > > > > static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin) > > tim/deployment-fixes new (next fetch will store in remotes/origin) $"; > > This is due to the line you added in .git_filters/RevDateURL.smudge: > > > if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: //' 2>/dev/null` } > > Problem being, the two lines match 'fetch' (next _fetch_ will store in ...), so you get more than the actual URL. > > However, this has been fixed already, the current version from 24198c6 > (see https://github.com/OpenSmalltalk/vm/commits/Cog/.git_filters/RevDateURL.smudge) has changed > and does not suffer from the grep. Relevant lines: > > > if ((defined $ENV{'TRAVIS'}) || (defined $ENV{'APPVEYOR'})) { > $url=`git config --get remote.origin.url`; > } else { > $url=`whoami` . '@' . `hostname` . ':' . `PWD=\$(pwd) echo \${PWD##\$HOME/}`; > } > > Thanks. So it was me :-(. Good to know. > > Is your repo up to date? > > How do I know? This "fetch and then diff" method is IMO broken. I simply want to know whether there are incoming commits /before/ I do a fetch. Fetch means 'get what is on the server to me but no more' I have a personal alias to see incoming changes: git config --global alias.incoming '!git remote update -p; git log ..@{u}' I can then do `git incoming` and it fetches the changes but then only shows the changes. So, after a fetch you can do git log ..@{u} which means 'please show me all changes from here to what upstream has' HTH best -Tobias > > > > > Best regards > -Tobias > > > > > First, multi-liner string constants must be terminated with a backslash to compile. So at the very least we'd need > > > > static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm\ > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin)\ > > tim/deployment-fixes new (next fetch will store in remotes/origin) $"; > > > > But second, multi-line output doesn't make sense here. We need something that fits on a single line. Who is going to fix this? I have a production build which is broken because of this. > > > > _,,,^..^,,,_ > > best, Eliot From eliot.miranda at gmail.com Tue Jun 21 21:57:32 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 21 21:57:37 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: Hi Holger, On Tue, Jun 21, 2016 at 2:42 PM, Holger Freyther wrote: > > > > On 21 Jun 2016, at 23:37, Eliot Miranda wrote: > > > > Hi Eliot, > > > > How do I know? This "fetch and then diff" method is IMO broken. I > simply want to know whether there are incoming commits /before/ I do a > fetch. > > "fetch" will just update your remote (origin by default). Do you know "git > ls-remote origin", is that closer to what you want? > It doesn't help me. I can't decode the commits into changes: McStalker.oscogvm$ git ls-remote origin 3e19ff3d1924550911e5fc15bbbf5eb05f39320c HEAD 3e19ff3d1924550911e5fc15bbbf5eb05f39320c refs/heads/Cog 56c4157d4a41fbc6d8f98e241c4eec954d15ebd2 refs/heads/master 795791095cc6dbc63a8272d6481554cde8b976fd refs/heads/oldTrunk 6879a597d5214e7cbb7ce329ef015ead2a7dffeb refs/heads/platform/Cross/plugins 250ea8034ffccd0639910f2abac787573afb48dd refs/heads/platform/win32/plugins 2fafe3d5bd3391b3151eb29a5b3221dc7ba18eff refs/pull/10/head cad7fcbdc2db887fd44ece95b8c5a5a2f9ed97e7 refs/pull/11/head 2fafe3d5bd3391b3151eb29a5b3221dc7ba18eff refs/pull/8/head d6d4215efc98645136ed420a69ceaf6f5f454b6c refs/pull/8/merge What makes sense to me is a list of changed files, and a further option to do a diff. So I guess the fetch, diff approach is what I'll have to get used to. What's the diff command to compare the current state of files (including unstaged modifications) against the last fetch? And thanks for holding my hand here; I really appreciate everyone's patience and help. I know I look really clumsy right now. Hopefully the murk will clear and I'll learn before doing too much damage. holger _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/208afaa8/attachment-0001.htm From eliot.miranda at gmail.com Tue Jun 21 22:00:10 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 21 22:00:14 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: Hi Tobias, On Tue, Jun 21, 2016 at 2:54 PM, Tobias Pape wrote: > > > On 21.06.2016, at 23:37, Eliot Miranda wrote: > > > Hi Tobias, > > > > On Tue, Jun 21, 2016 at 1:37 PM, Tobias Pape wrote: > > > > Hi Eliot, > > > > On 21.06.2016, at 22:08, Eliot Miranda wrote: > > > > > Hi All, > > > > > > recent changes, I *think* to updateSCCSVersions, have broken > platforms/Cross/vm/sqSCCSVersion.h: > > > > > > static char SvnRawRepositoryURL[] = "$URL: > http://github.com/OpenSmalltalk/vm > > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in > remotes/origin) > > > tim/deployment-fixes new (next fetch will store in > remotes/origin) $"; > > > > This is due to the line you added in .git_filters/RevDateURL.smudge: > > > > > > if (!$url) { $url=`git remote show origin | grep -i fetch | sed > 's/^.*URL: //' 2>/dev/null` } > > > > Problem being, the two lines match 'fetch' (next _fetch_ will store in > ...), so you get more than the actual URL. > > > > However, this has been fixed already, the current version from 24198c6 > > (see > https://github.com/OpenSmalltalk/vm/commits/Cog/.git_filters/RevDateURL.smudge) > has changed > > and does not suffer from the grep. Relevant lines: > > > > > > if ((defined $ENV{'TRAVIS'}) || (defined $ENV{'APPVEYOR'})) { > > $url=`git config --get remote.origin.url`; > > } else { > > $url=`whoami` . '@' . `hostname` . ':' . `PWD=\$(pwd) echo > \${PWD##\$HOME/}`; > > } > > > > Thanks. So it was me :-(. Good to know. > > > > Is your repo up to date? > > > > How do I know? This "fetch and then diff" method is IMO broken. I > simply want to know whether there are incoming commits /before/ I do a > fetch. > > Fetch means 'get what is on the server to me but no more' > > I have a personal alias to see incoming changes: > > git config --global alias.incoming '!git remote update -p; git log > ..@{u}' > > I can then do `git incoming` and it fetches the changes but then only shows > the changes. So, after a fetch you can do > > git log ..@{u} > > which means 'please show me all changes from here to what upstream has' > Ah, this looks like it could be what I want. So where should one put the git config command? Run it once in one's .profile? Add it to some configuration file? > HTH > best > -Tobias > > > Best regards > > -Tobias > > > > > > > > First, multi-liner string constants must be terminated with a > backslash to compile. So at the very least we'd need > > > > > > static char SvnRawRepositoryURL[] = "$URL: > http://github.com/OpenSmalltalk/vm\ > > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in > remotes/origin)\ > > > tim/deployment-fixes new (next fetch will store in > remotes/origin) $"; > > > > > > But second, multi-line output doesn't make sense here. We need > something that fits on a single line. Who is going to fix this? I have a > production build which is broken because of this. > > > > > > _,,,^..^,,,_ > > > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160621/0d5ff942/attachment.htm From Das.Linux at gmx.de Tue Jun 21 22:00:42 2016 From: Das.Linux at gmx.de (Das.Linux@gmx.de) Date: Tue Jun 21 22:00:43 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: <1E0F1965-0DF4-4BC1-A4A9-59FDD0A2F385@gmx.de> On 21.06.2016, at 23:54, Tobias Pape wrote: > > On 21.06.2016, at 23:37, Eliot Miranda wrote: > >> Hi Tobias, >> >> On Tue, Jun 21, 2016 at 1:37 PM, Tobias Pape wrote: >> >> Hi Eliot, >> >> On 21.06.2016, at 22:08, Eliot Miranda wrote: >> >>> Hi All, >>> >>> recent changes, I *think* to updateSCCSVersions, have broken platforms/Cross/vm/sqSCCSVersion.h: >>> >>> static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm >>> SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin) >>> tim/deployment-fixes new (next fetch will store in remotes/origin) $"; >> >> This is due to the line you added in .git_filters/RevDateURL.smudge: >> >> >> if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: //' 2>/dev/null` } >> >> Problem being, the two lines match 'fetch' (next _fetch_ will store in ...), so you get more than the actual URL. >> >> However, this has been fixed already, the current version from 24198c6 >> (see https://github.com/OpenSmalltalk/vm/commits/Cog/.git_filters/RevDateURL.smudge) has changed >> and does not suffer from the grep. Relevant lines: >> >> >> if ((defined $ENV{'TRAVIS'}) || (defined $ENV{'APPVEYOR'})) { >> $url=`git config --get remote.origin.url`; >> } else { >> $url=`whoami` . '@' . `hostname` . ':' . `PWD=\$(pwd) echo \${PWD##\$HOME/}`; >> } >> >> Thanks. So it was me :-(. Good to know. >> >> Is your repo up to date? >> >> How do I know? This "fetch and then diff" method is IMO broken. I simply want to know whether there are incoming commits /before/ I do a fetch. > > Fetch means 'get what is on the server to me but no more' > > I have a personal alias to see incoming changes: > > git config --global alias.incoming '!git remote update -p; git log ..@{u}' > > I can then do `git incoming` and it fetches the changes but then only shows > the changes. So, after a fetch you can do > > git log ..@{u} > > which means 'please show me all changes from here to what upstream has' > > HTH > best > -Tobias > PS: git log accepts the --patch option, which adds a diff to all commit messages. so you can also do git log ..@{u} --patch or with the alias: git incoming --patch > > >> >> >> >> >> Best regards >> -Tobias >> >>> >>> First, multi-liner string constants must be terminated with a backslash to compile. So at the very least we'd need >>> >>> static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm\ >>> SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin)\ >>> tim/deployment-fixes new (next fetch will store in remotes/origin) $"; >>> >>> But second, multi-line output doesn't make sense here. We need something that fits on a single line. Who is going to fix this? I have a production build which is broken because of this. >>> >>> _,,,^..^,,,_ >>> best, Eliot > > > From Das.Linux at gmx.de Tue Jun 21 22:08:00 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Jun 21 22:08:01 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: <06BC0439-C2CB-48E2-A958-B299FF0D8DE5@gmx.de> On 22.06.2016, at 00:00, Eliot Miranda wrote: > Hi Tobias, > > On Tue, Jun 21, 2016 at 2:54 PM, Tobias Pape wrote: > > > On 21.06.2016, at 23:37, Eliot Miranda wrote: > > > Hi Tobias, > > > > On Tue, Jun 21, 2016 at 1:37 PM, Tobias Pape wrote: > > > > Hi Eliot, > > > > On 21.06.2016, at 22:08, Eliot Miranda wrote: > > > > > Hi All, > > > > > > recent changes, I *think* to updateSCCSVersions, have broken platforms/Cross/vm/sqSCCSVersion.h: > > > > > > static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm > > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin) > > > tim/deployment-fixes new (next fetch will store in remotes/origin) $"; > > > > This is due to the line you added in .git_filters/RevDateURL.smudge: > > > > > > if (!$url) { $url=`git remote show origin | grep -i fetch | sed 's/^.*URL: //' 2>/dev/null` } > > > > Problem being, the two lines match 'fetch' (next _fetch_ will store in ...), so you get more than the actual URL. > > > > However, this has been fixed already, the current version from 24198c6 > > (see https://github.com/OpenSmalltalk/vm/commits/Cog/.git_filters/RevDateURL.smudge) has changed > > and does not suffer from the grep. Relevant lines: > > > > > > if ((defined $ENV{'TRAVIS'}) || (defined $ENV{'APPVEYOR'})) { > > $url=`git config --get remote.origin.url`; > > } else { > > $url=`whoami` . '@' . `hostname` . ':' . `PWD=\$(pwd) echo \${PWD##\$HOME/}`; > > } > > > > Thanks. So it was me :-(. Good to know. > > > > Is your repo up to date? > > > > How do I know? This "fetch and then diff" method is IMO broken. I simply want to know whether there are incoming commits /before/ I do a fetch. > > Fetch means 'get what is on the server to me but no more' > > I have a personal alias to see incoming changes: > > git config --global alias.incoming '!git remote update -p; git log ..@{u}' > > I can then do `git incoming` and it fetches the changes but then only shows > the changes. So, after a fetch you can do > > git log ..@{u} > > which means 'please show me all changes from here to what upstream has' > > Ah, this looks like it could be what I want. So where should one put the git config command? Run it once in one's .profile? Add it to some configuration file? here are my aliases $ cat ~/.gitconfig [alias] st = status co = checkout glog = log --graph --pretty=awesome --abbrev-commit --date=relative news = !git glog $(git log --author="\"$(git config user.name)\"" --pretty=format:%H -n1).. log-me = !UN=$(git config user.name)&& git log --author="\"$UN\"" --pretty=format:'%h %cd %s' --date=short log-nice = log --graph --decorate --pretty=oneline --abbrev-commit panic = !tar cvf ../git_panic.tar * wdiff = diff --color-words incoming = "!git remote update -p; git log ..@{u}" outgoing = log @{u}.. ap = add --patch up = "!git remote update -p; git merge --ff-only @{u}" Explanations: st,co from my svn days glog nice, concise log with graph news graph log with changes by other people log-me changes by me log-nice like glog, but different (not very interessting) panic put away everything i have into a tar wdiff Thats a nice one: like diff, but per-word not per-line incoming explained above outgoing which commits will be pushed when I say git push? ap I found myself saying 'git add --patch' so often I needed this. It's always worth a try up Similar to pull, but will only update when no merge is necessary Most of them are personal taste and convenience but I thought they can be an inspiration. Best -Tobias > > HTH > best > -Tobias > > > Best regards > > -Tobias > > > > > > > > First, multi-liner string constants must be terminated with a backslash to compile. So at the very least we'd need > > > > > > static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm\ > > > SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin)\ > > > tim/deployment-fixes new (next fetch will store in remotes/origin) $"; > > > > > > But second, multi-line output doesn't make sense here. We need something that fits on a single line. Who is going to fix this? I have a production build which is broken because of this. > > > > > > _,,,^..^,,,_ > > > best, Eliot From jakob.reschke at student.hpi.de Tue Jun 21 22:12:09 2016 From: jakob.reschke at student.hpi.de (Jakob Reschke) Date: Tue Jun 21 22:12:32 2016 Subject: [Vm-dev] build emergency with recent changes to updateSCCSVersions In-Reply-To: References: <0E26F469-2E51-4866-9C7E-E7A8A76E088E@gmx.de> Message-ID: 2016-06-22 0:00 GMT+02:00 Eliot Miranda : > So where should one put the git config command? You should run it only once. git config reads and edits settings for you; git config --global edits your ~/.gitconfig file. If you like, you can edit the file directly instead. From lewis at mail.msen.com Wed Jun 22 02:02:43 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Jun 22 02:02:45 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: Message-ID: <20160622020243.GA38983@shell.msen.com> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: > > Hi everyone, > > Excuse me if this has been asked already or it's documented somewhere and I > missed it, but what's the criteria to update the code in /src, /stacksrc, > /spursrc and other similar folders in the repository? > > -Laura Perez Cerrato Good question. Traditionally, Eliot generates these sources periodically and commits them to the repository (and in recent years I have done that chore for the old trunk interpreter VM). At this point, unless Eliot advises otherwise, I would suggest that no one other than Eliot should commit to the /src trees. Dave From lists at fniephaus.com Wed Jun 22 07:51:11 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed Jun 22 07:51:23 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: <20160622020243.GA38983@shell.msen.com> References: <20160622020243.GA38983@shell.msen.com> Message-ID: AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build. Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository. Fabio [1] https://github.com/pharo-project/pharo-vm [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors -- On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis wrote: > > On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: > > > > Hi everyone, > > > > Excuse me if this has been asked already or it's documented somewhere > and I > > missed it, but what's the criteria to update the code in /src, /stacksrc, > > /spursrc and other similar folders in the repository? > > > > -Laura Perez Cerrato > > Good question. Traditionally, Eliot generates these sources periodically > and > commits them to the repository (and in recent years I have done that chore > for > the old trunk interpreter VM). At this point, unless Eliot advises > otherwise, > I would suggest that no one other than Eliot should commit to the /src > trees. > > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/74e133c8/attachment.htm From norbert at hartl.name Wed Jun 22 08:11:52 2016 From: norbert at hartl.name (Norbert Hartl) Date: Wed Jun 22 08:11:54 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: <432E02D8-CACC-4CCE-B93C-C6B2D4B693CD@hartl.name> > Am 22.06.2016 um 09:51 schrieb Fabio Niephaus : > > AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build. > Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository. > How would you release a version of the vm? This is only possible of you archive the static artefacts. Norbert > Fabio > > [1] https://github.com/pharo-project/pharo-vm > [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors > > -- > > On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis > wrote: > > On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: > > > > Hi everyone, > > > > Excuse me if this has been asked already or it's documented somewhere and I > > missed it, but what's the criteria to update the code in /src, /stacksrc, > > /spursrc and other similar folders in the repository? > > > > -Laura Perez Cerrato > > Good question. Traditionally, Eliot generates these sources periodically and > commits them to the repository (and in recent years I have done that chore for > the old trunk interpreter VM). At this point, unless Eliot advises otherwise, > I would suggest that no one other than Eliot should commit to the /src trees. > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/db3ae565/attachment.htm From phil at highoctane.be Wed Jun 22 10:52:33 2016 From: phil at highoctane.be (phil@highoctane.be) Date: Wed Jun 22 10:53:14 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: <432E02D8-CACC-4CCE-B93C-C6B2D4B693CD@hartl.name> References: <20160622020243.GA38983@shell.msen.com> <432E02D8-CACC-4CCE-B93C-C6B2D4B693CD@hartl.name> Message-ID: One could thing of doing a git submodule with them but it is more trouble than it is worth. I want to be able to clone the VM and compile it right away. Phil On Wed, Jun 22, 2016 at 10:11 AM, Norbert Hartl wrote: > > > Am 22.06.2016 um 09:51 schrieb Fabio Niephaus : > > AFAIK the pharo-vm projects generates the sources from the VMMaker package > during a build. > Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one > needs to generate source manually anymore and we don't have millions of > lines [2] of generated code in the repository. > > How would you release a version of the vm? This is only possible of you > archive the static artefacts. > > Norbert > > Fabio > > [1] https://github.com/pharo-project/pharo-vm > [2] see Eliot's stats at > https://github.com/OpenSmalltalk/vm/graphs/contributors > > -- > > On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis > wrote: > >> >> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >> > >> > Hi everyone, >> > >> > Excuse me if this has been asked already or it's documented somewhere >> and I >> > missed it, but what's the criteria to update the code in /src, >> /stacksrc, >> > /spursrc and other similar folders in the repository? >> > >> > -Laura Perez Cerrato >> >> Good question. Traditionally, Eliot generates these sources periodically >> and >> commits them to the repository (and in recent years I have done that >> chore for >> the old trunk interpreter VM). At this point, unless Eliot advises >> otherwise, >> I would suggest that no one other than Eliot should commit to the /src >> trees. >> >> Dave >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/0a989f40/attachment.htm From estebanlm at gmail.com Wed Jun 22 11:15:27 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Wed Jun 22 11:15:31 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> <432E02D8-CACC-4CCE-B93C-C6B2D4B693CD@hartl.name> Message-ID: > On 22 Jun 2016, at 12:52, phil@highoctane.be wrote: > > One could thing of doing a git submodule with them but it is more trouble than it is worth. > > I want to be able to clone the VM and compile it right away. > > Phil > > On Wed, Jun 22, 2016 at 10:11 AM, Norbert Hartl > wrote: > > >> Am 22.06.2016 um 09:51 schrieb Fabio Niephaus >: >> >> AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build. >> Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository. >> > How would you release a version of the vm? This is only possible of you archive the static artefacts. I do not understand this question, so maybe I?m answering anything :) in Pharo, VMMaker package sources coexist along with C sources (thanks to filetree for now, but we are working on enhance that). This way, each release of VM in github contains *exactly* all the sources needed to reconstruct it? Esteban > > Norbert > >> Fabio >> >> [1] https://github.com/pharo-project/pharo-vm >> [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors >> >> -- >> >> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis > wrote: >> >> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >> > >> > Hi everyone, >> > >> > Excuse me if this has been asked already or it's documented somewhere and I >> > missed it, but what's the criteria to update the code in /src, /stacksrc, >> > /spursrc and other similar folders in the repository? >> > >> > -Laura Perez Cerrato >> >> Good question. Traditionally, Eliot generates these sources periodically and >> commits them to the repository (and in recent years I have done that chore for >> the old trunk interpreter VM). At this point, unless Eliot advises otherwise, >> I would suggest that no one other than Eliot should commit to the /src trees. >> >> Dave >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/02ad489b/attachment-0001.htm From lewis at mail.msen.com Wed Jun 22 12:38:58 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Jun 22 12:39:00 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: <20160622123858.GA57808@shell.msen.com> On Wed, Jun 22, 2016 at 07:51:11AM +0000, Fabio Niephaus wrote: > > On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis wrote: > > > > > On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: > > > > > > Hi everyone, > > > > > > Excuse me if this has been asked already or it's documented somewhere > > and I > > > missed it, but what's the criteria to update the code in /src, /stacksrc, > > > /spursrc and other similar folders in the repository? > > > > > > -Laura Perez Cerrato > > > > Good question. Traditionally, Eliot generates these sources periodically > > and > > commits them to the repository (and in recent years I have done that chore > > for > > the old trunk interpreter VM). At this point, unless Eliot advises > > otherwise, > > I would suggest that no one other than Eliot should commit to the /src > > trees. > > > > > AFAIK the pharo-vm projects generates the sources from the VMMaker package > during a build. > Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one > needs to generate source manually anymore and we don't have millions of > lines [2] of generated code in the repository. > > Fabio > > [1] https://github.com/pharo-project/pharo-vm > [2] see Eliot's stats at > https://github.com/OpenSmalltalk/vm/graphs/contributors > > -- Yes of course it should be automated. My suggestion is that at this point, or at least until Eliot says otherwise, Eliot should be the only person who commits to the /src directories. One step at a time :-) And of course we can do whatever is necessary in the various branches. Dave From bert at freudenbergs.de Wed Jun 22 12:57:54 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 22 12:57:56 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: Message-ID: Hi Eliot, the become-forward works now, indeed. But why is it different with the swapping become? This still gets into an endless recursion: (ByteString new: 20000000) become: (WideString new: 20000000) Why is it creating copies at all? - Bert - On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda wrote: > > Hi Bert, > > it was a regression in argument validation for become introduced in > fixing argument validation for the one-way copy hash case. The code was > erroneously checking that it had space to create copies of the input > arguments, even though it was a one-way become. It's a copyHash become and > that confused it. It's now fixed. I'll generate sources and push and new > builds should appear shortly ;-) > > On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg > wrote: > >> >> I'm reading a 20MB text file. At some point it tries to convert the 20 MB >> ByteString into an 80 MB WideString using forward become. This fails >> resulting in an endless loop. The primitive failure code for >> elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' >> and it tries again after growing: >> >> ec == #'insufficient object memory' ifTrue: >> [Smalltalk garbageCollect < 1048576 ifTrue: >> [Smalltalk growMemoryByAtLeast: 1048576]. >> ^self elementsForwardIdentityTo: otherArray]. >> >> but the growMemoryByAtLeast: does not actually grow the memory: >> >> {Smalltalk garbageCollect. >> Smalltalk growMemoryByAtLeast: 1048576. >> Smalltalk garbageCollect.} >> >> ==> #(58576608 16777216 58576608) >> >> 58 MB are not enough, but it doesn't grow any further. >> >> The question is, why does it try to allocate a new object at all? The >> WideString exists already. I thought Spur would simply install a forwarder? >> >> To reproduce, execute >> >> (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) >> >> You probably want to follow that with a user interrupt (Cmd-period). >> >> This happens using the latest Spur VM from github (r201606160944) >> >> - Bert - >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/00029e62/attachment.htm From eliot.miranda at gmail.com Wed Jun 22 13:07:22 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 22 13:07:27 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: <01840991-BAED-4618-9F1E-9CEDB4857234@gmail.com> Hi Fabio, > On Jun 22, 2016, at 12:51 AM, Fabio Niephaus wrote: > > AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build. > Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository. For me this is a very very bad idea. There are two main objections. The main problem is that it means there is no versioning of the key source of the VM. - one cannot ever guarantee generating exactly the same source that was fed to the compiler in a particular build -- elements of the type inferrence code are affected by hash computations since they use dictionaries etc, and so there are small variations from run to run. These shouldn't exist and I work to stabilize the type inferrencer but it isn't yet perfect -- the VMMaker and Cog packages make use of the underlying system and it's conceivable that differences in the generated source, in inessentials like white space, could bubble up into the generated source, especially considering the differences between Pharo and Squeak, which are only widening. This is disastrous for VM debugging. One /must/ have a versioned artifact to be able to attach a debugger and set of sources to an already-built production VM and be able to be debugging the VM that corresponds with that source. This is disastrous for spitting problems with the type inferrencer. If source is generated and sent to the computer there's no point at which the VM developer gets to check that the difference between one version of the sources and another are as expected. Often bugs introduced into the type inferrencer are noticed and understood by looking at the changes to the generated source before checking in that source. Remove this stage and these bugs will only be found much further down stream at much greater cost and at enormous cost to examine because one will have to set up two different images to generate the two versions and manually duff them. Note that the type inferrencer is key to being able to write clean Smalltalk code for the VM with minimal duplication that works for both 32- and 64- but Spur, and in general. It allows one to omit C type declaration pragmas from much of the VM source, which is key to a particular method working in 32- and 64-bit versions. I'm sure that if we ever wanted to try and merge in SqueakJS it would be even more important. The second problem is performance. Generating one of the sources takes a substantial fraction of a minute on a fast machine. On an ARM it takes more than a minute. Add to that the time taken to download a VM and image and that's more time. Add to that the loading of VMMaker, Cog and prerequisite packages and now one is in a position where Travis time limits could prevent a buff on google's ARM infrastructure. So please, no. This may seem like a pure approach but it is, in fact, insane. It means that anyone doing serious VM development has to work a lot harder and wait a lot longer to get their work done. It destroys their productivity. > Fabio > > [1] https://github.com/pharo-project/pharo-vm > [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors > > -- > >> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis wrote: >> >> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >> > >> > Hi everyone, >> > >> > Excuse me if this has been asked already or it's documented somewhere and I >> > missed it, but what's the criteria to update the code in /src, /stacksrc, >> > /spursrc and other similar folders in the repository? >> > >> > -Laura Perez Cerrato >> >> Good question. Traditionally, Eliot generates these sources periodically and >> commits them to the repository (and in recent years I have done that chore for >> the old trunk interpreter VM). At this point, unless Eliot advises otherwise, >> I would suggest that no one other than Eliot should commit to the /src trees. >> >> Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/73cc6d35/attachment.htm From eliot.miranda at gmail.com Wed Jun 22 13:27:20 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 22 13:27:30 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: Message-ID: Hi Laura, > On Jun 21, 2016, at 7:11 AM, Laura Perez Cerrato wrote: > > Hi everyone, > > Excuse me if this has been asked already or it's documented somewhere and I missed it, but what's the criteria to update the code in /src, /stacksrc, /spursrc and other similar folders in the repository? I should document this. There are three main criteria: - does the source need to be updated to fix a bug or make available new functionality urgently needed? Since up until now my VM builds have been manually kicked off on the three platforms it took a while and I'd only do new builds when necessary - does the source look sane? One should always look at the differences to the generated source if any part of Slang's translator has been modified to check for bugs. - is the source generated from versioned input? The generated C source is marked with the Monticello package version, including UUID, of the packages from which it was created (eg a package providing a plugin) and that created it (i.e. the VMMaker package). These marks will contain asterisks for modified Monticello packages. Clearly one should never check in source containing asterisks. The one exception I've allowed myself is MiscPrimitivesPlugin which gets generated from base image code, and I have a few choice base image modifications (such as a much higher character limit on the Transcript, or different code highlighting) that make it really painful to keep MiscPrimitivesPlugin clean. I'm happy for others to generate and check in VM source provided: - you carefully check the generated source before checking it in to verify that the delta is as expected and no new bugs have been introduced - you generate as little change as possible. -- There is a script that reverts generated plugins that have changed only in their Monticello markings that allows us to not checkin inessential revisions to plugins and see when I fact they did change -- wrapping the generation code with [...] valueAnswering: false (or whatever the selector is) avoids regenerating VM headers (cointerp.h cogit.h cogmethod.h interp.h) when these haven't been modified In short, only do this if you know what you're doing. But got people to know what they're doing the process has to be documented along with the rationale. I guess this email and my reply to Fabio's question can serve as input to that documentation. > -Laura Perez Cerrato _,,,^..^,,,_ (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/2b38aa85/attachment-0001.htm From eliot.miranda at gmail.com Wed Jun 22 13:30:23 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 22 13:30:28 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: <20160622123858.GA57808@shell.msen.com> References: <20160622020243.GA38983@shell.msen.com> <20160622123858.GA57808@shell.msen.com> Message-ID: > On Jun 22, 2016, at 5:38 AM, David T. Lewis wrote: > > >> On Wed, Jun 22, 2016 at 07:51:11AM +0000, Fabio Niephaus wrote: >> >>> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis wrote: >>> >>> >>>> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >>>> >>>> Hi everyone, >>>> >>>> Excuse me if this has been asked already or it's documented somewhere >>> and I >>>> missed it, but what's the criteria to update the code in /src, /stacksrc, >>>> /spursrc and other similar folders in the repository? >>>> >>>> -Laura Perez Cerrato >>> >>> Good question. Traditionally, Eliot generates these sources periodically >>> and >>> commits them to the repository (and in recent years I have done that chore >>> for >>> the old trunk interpreter VM). At this point, unless Eliot advises >>> otherwise, >>> I would suggest that no one other than Eliot should commit to the /src >>> trees. >> AFAIK the pharo-vm projects generates the sources from the VMMaker package >> during a build. >> Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one >> needs to generate source manually anymore and we don't have millions of >> lines [2] of generated code in the repository. >> >> Fabio >> >> [1] https://github.com/pharo-project/pharo-vm >> [2] see Eliot's stats at >> https://github.com/OpenSmalltalk/vm/graphs/contributors >> >> -- > > Yes of course it should be automated. My suggestion is that at this point, > or at least until Eliot says otherwise, Eliot should be the only person who > commits to the /src directories. One step at a time :-) > > And of course we can do whatever is necessary in the various branches. Absolutely not. For the reasons stated. Those millions of lines are there for good reason: Reproducibility Comprehensibility Optimising the repository for brevity is completely mistaken. That source needs to exist in a versioned form. Now please can we stop discussing this madness? I didn't simply choose to set things up as they are on a whim. > > Dave > From eliot.miranda at gmail.com Wed Jun 22 13:44:52 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 22 13:44:56 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: Message-ID: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Hi Bert, > On Jun 22, 2016, at 5:57 AM, Bert Freudenberg wrote: > > Hi Eliot, > > the become-forward works now, indeed. > > But why is it different with the swapping become? This still gets into an endless recursion: > > (ByteString new: 20000000) become: (WideString new: 20000000) > > Why is it creating copies at all? because that's how Spur works. Become is lazy; the two objects are turned into forwarders to copies of each other. If the two objects have the same byte size as heap objects (rounded up to 8 byte units) their contents can be exchanged. If they are not, two copies must be created and the two originals turned into forwarders to the copies. Remember the slides from my Cambridge talk. Spur chooses to trade memory (creating the copies) over time (searching the entire heap looking fir references). This is the right trade off until you start becoming objects that are substantial fractions of the entire heap in size. In your case you could avoid the pain simply by making sure the steam had a wide String as contents in the first place. I understand that may not be possible. > > - Bert - > >> On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda wrote: >> >> Hi Bert, >> >> it was a regression in argument validation for become introduced in fixing argument validation for the one-way copy hash case. The code was erroneously checking that it had space to create copies of the input arguments, even though it was a one-way become. It's a copyHash become and that confused it. It's now fixed. I'll generate sources and push and new builds should appear shortly ;-) >> >>> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg wrote: >>> >>> I'm reading a 20MB text file. At some point it tries to convert the 20 MB ByteString into an 80 MB WideString using forward become. This fails resulting in an endless loop. The primitive failure code for elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' and it tries again after growing: >>> >>> ec == #'insufficient object memory' ifTrue: >>> [Smalltalk garbageCollect < 1048576 ifTrue: >>> [Smalltalk growMemoryByAtLeast: 1048576]. >>> ^self elementsForwardIdentityTo: otherArray]. >>> >>> but the growMemoryByAtLeast: does not actually grow the memory: >>> >>> {Smalltalk garbageCollect. >>> Smalltalk growMemoryByAtLeast: 1048576. >>> Smalltalk garbageCollect.} >>> >>> ==> #(58576608 16777216 58576608) >>> >>> 58 MB are not enough, but it doesn't grow any further. >>> >>> The question is, why does it try to allocate a new object at all? The WideString exists already. I thought Spur would simply install a forwarder? >>> >>> To reproduce, execute >>> >>> (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) >>> >>> You probably want to follow that with a user interrupt (Cmd-period). >>> >>> This happens using the latest Spur VM from github (r201606160944) >>> >>> - Bert - >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/6735c54e/attachment.htm From eliot.miranda at gmail.com Wed Jun 22 13:48:49 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 22 13:48:53 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: Hi Fabio, Hi All, > On Jun 22, 2016, at 12:51 AM, Fabio Niephaus wrote: > > AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build. > Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository. In short, we think nothing of burning pets cycles every time we make any change in the repository, kicking off many many builds. We should think nothing of these few tens of megabytes of disc that keep a necessary record of the production VM source. Reducing disc size here is a) optimising the wrong thing and b) optimising something quite cheap. Both are cardinal errors. > Fabio > > [1] https://github.com/pharo-project/pharo-vm > [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors > > -- > >> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis wrote: >> >> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >> > >> > Hi everyone, >> > >> > Excuse me if this has been asked already or it's documented somewhere and I >> > missed it, but what's the criteria to update the code in /src, /stacksrc, >> > /spursrc and other similar folders in the repository? >> > >> > -Laura Perez Cerrato >> >> Good question. Traditionally, Eliot generates these sources periodically and >> commits them to the repository (and in recent years I have done that chore for >> the old trunk interpreter VM). At this point, unless Eliot advises otherwise, >> I would suggest that no one other than Eliot should commit to the /src trees. >> >> Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/0fe40965/attachment.htm From lauraperezcerrato at gmail.com Wed Jun 22 13:52:29 2016 From: lauraperezcerrato at gmail.com (Laura Perez Cerrato) Date: Wed Jun 22 13:52:51 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: Message-ID: Hi Eliot, Hi everyone, Thanks for the comprehensive answer. May I suggest this, along with your response to Fabio's question, be added to CONTRIBUTING.md? I wouldn't mind doing so myself if you all agree (since I'm not a contributor to the GitHub repository I'd submit it through a pull request though). Cheers! -Laura Perez Cerrato On 22 June 2016 at 10:27, Eliot Miranda wrote: > > Hi Laura, > > On Jun 21, 2016, at 7:11 AM, Laura Perez Cerrato < > lauraperezcerrato@gmail.com> wrote: > > Hi everyone, > > Excuse me if this has been asked already or it's documented somewhere and > I missed it, but what's the criteria to update the code in /src, /stacksrc, > /spursrc and other similar folders in the repository? > > > I should document this. There are three main criteria: > > - does the source need to be updated to fix a bug or make available new > functionality urgently needed? Since up until now my VM builds have been > manually kicked off on the three platforms it took a while and I'd only do > new builds when necessary > > - does the source look sane? One should always look at the differences to > the generated source if any part of Slang's translator has been modified to > check for bugs. > > - is the source generated from versioned input? The generated C source is > marked with the Monticello package version, including UUID, of the packages > from which it was created (eg a package providing a plugin) and that > created it (i.e. the VMMaker package). These marks will contain asterisks > for modified Monticello packages. Clearly one should never check in source > containing asterisks. The one exception I've allowed myself is > MiscPrimitivesPlugin which gets generated from base image code, and I have > a few choice base image modifications (such as a much higher character > limit on the Transcript, or different code highlighting) that make it > really painful to keep MiscPrimitivesPlugin clean. > > I'm happy for others to generate and check in VM source provided: > - you carefully check the generated source before checking it in to verify > that the delta is as expected and no new bugs have been introduced > - you generate as little change as possible. > -- There is a script that reverts generated plugins that have changed only > in their Monticello markings that allows us to not checkin inessential > revisions to plugins and see when I fact they did change > -- wrapping the generation code with [...] valueAnswering: false (or > whatever the selector is) avoids regenerating VM headers (cointerp.h > cogit.h cogmethod.h interp.h) when these haven't been modified > > In short, only do this if you know what you're doing. But got people to > know what they're doing the process has to be documented along with the > rationale. I guess this email and my reply to Fabio's question can serve > as input to that documentation. > > -Laura Perez Cerrato > > > _,,,^..^,,,_ (phone) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/2661213a/attachment-0001.htm From bert at freudenbergs.de Wed Jun 22 13:54:51 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed Jun 22 13:54:54 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: Hi Eliot, okay, but it still is a bug that I get an endless recursion. AFAICT the bug is in growMemoryByAtLeast: which does not grow the memory as requested. - Bert - On Wed, Jun 22, 2016 at 3:44 PM, Eliot Miranda wrote: > > Hi Bert, > > > On Jun 22, 2016, at 5:57 AM, Bert Freudenberg > wrote: > > Hi Eliot, > > the become-forward works now, indeed. > > But why is it different with the swapping become? This still gets into an > endless recursion: > > (ByteString new: 20000000) become: (WideString new: 20000000) > > Why is it creating copies at all? > > > because that's how Spur works. Become is lazy; the two objects are turned > into forwarders to copies of each other. If the two objects have the same > byte size as heap objects (rounded up to 8 byte units) their contents can > be exchanged. If they are not, two copies must be created and the two > originals turned into forwarders to the copies. Remember the slides from > my Cambridge talk. > > Spur chooses to trade memory (creating the copies) over time (searching > the entire heap looking fir references). This is the right trade off until > you start becoming objects that are substantial fractions of the entire > heap in size. > > In your case you could avoid the pain simply by making sure the steam had > a wide String as contents in the first place. I understand that may not be > possible. > > > - Bert - > > On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda > wrote: > >> >> Hi Bert, >> >> it was a regression in argument validation for become introduced in >> fixing argument validation for the one-way copy hash case. The code was >> erroneously checking that it had space to create copies of the input >> arguments, even though it was a one-way become. It's a copyHash become and >> that confused it. It's now fixed. I'll generate sources and push and new >> builds should appear shortly ;-) >> >> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg >> wrote: >> >>> >>> I'm reading a 20MB text file. At some point it tries to convert the 20 >>> MB ByteString into an 80 MB WideString using forward become. This fails >>> resulting in an endless loop. The primitive failure code for >>> elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' >>> and it tries again after growing: >>> >>> ec == #'insufficient object memory' ifTrue: >>> [Smalltalk garbageCollect < 1048576 ifTrue: >>> [Smalltalk growMemoryByAtLeast: 1048576]. >>> ^self elementsForwardIdentityTo: otherArray]. >>> >>> but the growMemoryByAtLeast: does not actually grow the memory: >>> >>> {Smalltalk garbageCollect. >>> Smalltalk growMemoryByAtLeast: 1048576. >>> Smalltalk garbageCollect.} >>> >>> ==> #(58576608 16777216 58576608) >>> >>> 58 MB are not enough, but it doesn't grow any further. >>> >>> The question is, why does it try to allocate a new object at all? The >>> WideString exists already. I thought Spur would simply install a forwarder? >>> >>> To reproduce, execute >>> >>> (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) >>> >>> You probably want to follow that with a user interrupt (Cmd-period). >>> >>> This happens using the latest Spur VM from github (r201606160944) >>> >>> - Bert - >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/c2781814/attachment.htm From tim at rowledge.org Wed Jun 22 16:53:22 2016 From: tim at rowledge.org (tim Rowledge) Date: Wed Jun 22 16:53:06 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: <99892849-345B-4479-B71D-6E40EAFBC2D3@rowledge.org> > On 22-06-2016, at 6:44 AM, Eliot Miranda wrote: > > Become is lazy; the two objects are turned into forwarders to copies of each other. If the two objects have the same byte size as heap objects (rounded up to 8 byte units) their contents can be exchanged. If they are not, two copies must be created and the two originals turned into forwarders to the copies. Remember the slides from my Cambridge talk. I could have sworn that you had added the ?copy the small one into the big one?s space? optimisation. Maybe it was only added to the list of "things to do". tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I'm so skeptical that I'm not sure I'm really a skeptic From btc at openinworld.com Wed Jun 22 17:19:05 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 22 17:19:28 2016 Subject: [Vm-dev] condense .gitignore for build dirs Message-ID: Looking at .gitignore I found the 311 entries for /build.* a bit overwhelming trying to understand what actually was ignored. I manage to condense that down to 55 general rules. I've detailed some analysis, implementation and testing in the pull request. https://github.com/OpenSmalltalk/vm/pull/13 cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/fc01c09d/attachment.htm From estebanlm at gmail.com Wed Jun 22 17:25:51 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Wed Jun 22 17:25:57 2016 Subject: [Vm-dev] condense .gitignore for build dirs In-Reply-To: References: Message-ID: <0C1D4E1A-3A7A-49F9-8840-E349B3D05D47@gmail.com> is not just easier to put just ?build? in the .gitignore? > On 22 Jun 2016, at 19:19, Ben Coman wrote: > > Looking at .gitignore I found the 311 entries for /build.* > a bit overwhelming trying to understand what actually was ignored. > I manage to condense that down to 55 general rules. > > I've detailed some analysis, implementation and testing in the pull request. > https://github.com/OpenSmalltalk/vm/pull/13 > > cheers -ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/afd37613/attachment.htm From estebanlm at gmail.com Wed Jun 22 17:26:28 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Wed Jun 22 17:26:31 2016 Subject: [Vm-dev] condense .gitignore for build dirs In-Reply-To: <0C1D4E1A-3A7A-49F9-8840-E349B3D05D47@gmail.com> References: <0C1D4E1A-3A7A-49F9-8840-E349B3D05D47@gmail.com> Message-ID: <86955595-BC47-4A19-927F-A88796C52E66@gmail.com> ah yes? that?s what you did? forget me :) > On 22 Jun 2016, at 19:25, Esteban Lorenzano wrote: > > is not just easier to put just ?build? in the .gitignore? > >> On 22 Jun 2016, at 19:19, Ben Coman > wrote: >> >> Looking at .gitignore I found the 311 entries for /build.* >> a bit overwhelming trying to understand what actually was ignored. >> I manage to condense that down to 55 general rules. >> >> I've detailed some analysis, implementation and testing in the pull request. >> https://github.com/OpenSmalltalk/vm/pull/13 >> >> cheers -ben >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/086a1b37/attachment-0001.htm From btc at openinworld.com Wed Jun 22 17:37:12 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 22 17:37:35 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: <20160622020243.GA38983@shell.msen.com> References: <20160622020243.GA38983@shell.msen.com> Message-ID: On Wed, Jun 22, 2016 at 10:02 AM, David T. Lewis wrote: > > On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >> >> Hi everyone, >> >> Excuse me if this has been asked already or it's documented somewhere and I >> missed it, but what's the criteria to update the code in /src, /stacksrc, >> /spursrc and other similar folders in the repository? >> >> -Laura Perez Cerrato > > Good question. Traditionally, Eliot generates these sources periodically and > commits them to the repository (and in recent years I have done that chore for > the old trunk interpreter VM). At this point, unless Eliot advises otherwise, > I would suggest that no one other than Eliot should commit to the /src trees. > > Dave > But... its all one repository. Everyone who works on the vm in their personal space, doing a dozen generate/compile/commit cycles along the way, and then finally submits a worthwhile change via a pull request that is accepted, gets *all* their intermediate generated src added to the repository. > On 22 Jun 2016, at 12:52, phil@highoctane.be wrote: > One could thing of doing a git submodule with them but it is more trouble than it is worth. Actually this was exactly what I wanted to suggest. That perhaps the srcs live in a submodule/subtree, that only gets pushed updated by Travis upon a successful build. That is, Travis would generate the srcs, then commit them, and build from that commit, and only push that commit back to the official repo/branch upon successful build. Upon failure the commit might be pushed to a "failure" branch for manual review before later that branch is thrown away. Having the generated sources in a submodule/subtree means when Joe Public makes a contribution, its easier for only his changes to non-generated code get submitted. Otherwise he need to manually back out any generated sources for the last commit being submitted as a PR, but that doesn't remove any previous commits. Or \every time he does a personal commit he has to back out the changes just for those directories (??). > I want to be able to clone the VM and compile it right away. The compile script could pull the srcs subtree before compiling. No real difference in elapsed time than if the main repo was pulled. cheers -ben From Yoshiki.Ohshima at acm.org Wed Jun 22 20:13:54 2016 From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima) Date: Wed Jun 22 20:13:56 2016 Subject: [Vm-dev] Loading VMMaker Message-ID: Hi, Just to refresh my skill on compiling the Squeak VM (I'd like to play with Kinect; I found some efforts like: http://tecnodacta.com.ar/gira/ but want to make a plugin that is suitable for my need.) Let us say I'd like to compile a VM and my plugins on Mac, what are the right steps? (I had some experiences with VMMaker but that was before I need to specify Interpreter class name in the VMMakerTool, for example. I added VMMaker repository in the Monticello browser, and opened it. As trying to just load VMMaker shows a warning of missing FFI constants, I turned to 'update' and load update-dtl.17.mcm. Is this a right thing to do? But then, trying to load update-dtl.17.mcm onto the VM and image in the 5.0 all in one package, the VM crashes. Do you see this? I'd like to get the files and image set up so that I can compile an external plugin, preferably for Cog/Spur. Some up to date guidance would be greatly appreciated. Thanks! -- -- Yoshiki From eliot.miranda at gmail.com Wed Jun 22 20:15:43 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 22 20:15:57 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: <8F4BBEA0-3815-429D-9D87-43A6841347E1@gmail.com> Hi Bert, > On Jun 22, 2016, at 6:54 AM, Bert Freudenberg wrote: > > Hi Eliot, > > okay, but it still is a bug that I get an endless recursion. AFAICT the bug is in growMemoryByAtLeast: which does not grow the memory as requested. Do you have a reproducible case for me to look at? The fix I submitted fixes your original case. But you could try and fix it yourself. If the become: is two-way and fails with out-of-memory the failure code should ask to grow memory by the sum of the instance byte sizes. There us a bytesSzeOfInstance: method (or close) to compute the required space. > > - Bert - > >> On Wed, Jun 22, 2016 at 3:44 PM, Eliot Miranda wrote: >> >> Hi Bert, >> >> >>> On Jun 22, 2016, at 5:57 AM, Bert Freudenberg wrote: >>> >>> Hi Eliot, >>> >>> the become-forward works now, indeed. >>> >>> But why is it different with the swapping become? This still gets into an endless recursion: >>> >>> (ByteString new: 20000000) become: (WideString new: 20000000) >>> >>> Why is it creating copies at all? >> >> because that's how Spur works. Become is lazy; the two objects are turned into forwarders to copies of each other. If the two objects have the same byte size as heap objects (rounded up to 8 byte units) their contents can be exchanged. If they are not, two copies must be created and the two originals turned into forwarders to the copies. Remember the slides from my Cambridge talk. >> >> Spur chooses to trade memory (creating the copies) over time (searching the entire heap looking fir references). This is the right trade off until you start becoming objects that are substantial fractions of the entire heap in size. >> >> In your case you could avoid the pain simply by making sure the steam had a wide String as contents in the first place. I understand that may not be possible. >> >>> >>> - Bert - >>> >>>> On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda wrote: >>>> >>>> Hi Bert, >>>> >>>> it was a regression in argument validation for become introduced in fixing argument validation for the one-way copy hash case. The code was erroneously checking that it had space to create copies of the input arguments, even though it was a one-way become. It's a copyHash become and that confused it. It's now fixed. I'll generate sources and push and new builds should appear shortly ;-) >>>> >>>>> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg wrote: >>>>> >>>>> I'm reading a 20MB text file. At some point it tries to convert the 20 MB ByteString into an 80 MB WideString using forward become. This fails resulting in an endless loop. The primitive failure code for elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' and it tries again after growing: >>>>> >>>>> ec == #'insufficient object memory' ifTrue: >>>>> [Smalltalk garbageCollect < 1048576 ifTrue: >>>>> [Smalltalk growMemoryByAtLeast: 1048576]. >>>>> ^self elementsForwardIdentityTo: otherArray]. >>>>> >>>>> but the growMemoryByAtLeast: does not actually grow the memory: >>>>> >>>>> {Smalltalk garbageCollect. >>>>> Smalltalk growMemoryByAtLeast: 1048576. >>>>> Smalltalk garbageCollect.} >>>>> >>>>> ==> #(58576608 16777216 58576608) >>>>> >>>>> 58 MB are not enough, but it doesn't grow any further. >>>>> >>>>> The question is, why does it try to allocate a new object at all? The WideString exists already. I thought Spur would simply install a forwarder? >>>>> >>>>> To reproduce, execute >>>>> >>>>> (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) >>>>> >>>>> You probably want to follow that with a user interrupt (Cmd-period). >>>>> >>>>> This happens using the latest Spur VM from github (r201606160944) >>>>> >>>>> - Bert - >>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/f0c50eb0/attachment.htm From gettimothy at zoho.com Wed Jun 22 22:53:08 2016 From: gettimothy at zoho.com (gettimothy) Date: Wed Jun 22 22:53:15 2016 Subject: [Vm-dev] Loading VMMaker In-Reply-To: References: Message-ID: <1557a512e04.101cbe8ea179639.1686182151266884800@zoho.com> Hi Yoshiki If you checkout the source code from git and go to the oscogvm/image directory are several scripts you can open in a workspace and 'do it' (or filein, i think) The one I use is BuildSqueakSpurTrunkVMMakerImage.st I am assuming you are running Cog/Spur to power a trunk image. ---- On Wed, 22 Jun 2016 16:13:54 -0400 Yoshiki Ohshima <Yoshiki.Ohshima@acm.org> wrote ---- Hi, Just to refresh my skill on compiling the Squeak VM (I'd like to play with Kinect; I found some efforts like: http://tecnodacta.com.ar/gira/ but want to make a plugin that is suitable for my need.) Let us say I'd like to compile a VM and my plugins on Mac, what are the right steps? (I had some experiences with VMMaker but that was before I need to specify Interpreter class name in the VMMakerTool, for example. I added VMMaker repository in the Monticello browser, and opened it. As trying to just load VMMaker shows a warning of missing FFI constants, I turned to 'update' and load update-dtl.17.mcm. Is this a right thing to do? But then, trying to load update-dtl.17.mcm onto the VM and image in the 5.0 all in one package, the VM crashes. Do you see this? I'd like to get the files and image set up so that I can compile an external plugin, preferably for Cog/Spur. Some up to date guidance would be greatly appreciated. Thanks! -- -- Yoshiki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/dac98db8/attachment-0001.htm From btc at openinworld.com Wed Jun 22 23:51:40 2016 From: btc at openinworld.com (Ben Coman) Date: Wed Jun 22 23:52:02 2016 Subject: [Vm-dev] Loading VMMaker In-Reply-To: References: Message-ID: On Thu, Jun 23, 2016 at 4:13 AM, Yoshiki Ohshima wrote: > > Hi, > > Just to refresh my skill on compiling the Squeak VM (I'd like to play > with Kinect; I found some efforts like: http://tecnodacta.com.ar/gira/ > but want to make a plugin that is suitable for my need.) > > Let us say I'd like to compile a VM and my plugins on Mac, what are > the right steps? (I had some experiences with VMMaker but that was > before I need to specify Interpreter class name in the VMMakerTool, > for example. > > I added VMMaker repository in the Monticello browser, and opened it. > As trying to just load VMMaker shows a warning of missing FFI > constants, I turned to 'update' and load update-dtl.17.mcm. Is this a > right thing to do? > > But then, trying to load update-dtl.17.mcm onto the VM and image in > the 5.0 all in one package, the VM crashes. Do you see this? > > I'd like to get the files and image set up so that I can compile an > external plugin, preferably for Cog/Spur. Some up to date guidance > would be greatly appreciated. > Use a combination of... * https://github.com/OpenSmalltalk/vm/blob/Cog/CONTRIBUTING.md * http://www.mirandabanda.org/cogblog/compiling-the-vm/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/f4a6bd39/attachment.htm From eliot.miranda at gmail.com Thu Jun 23 00:19:09 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 00:19:12 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: Message-ID: On Wed, Jun 22, 2016 at 6:52 AM, Laura Perez Cerrato < lauraperezcerrato@gmail.com> wrote: > > Hi Eliot, Hi everyone, > > Thanks for the comprehensive answer. May I suggest this, along with your > response to Fabio's question, be added to CONTRIBUTING.md? I wouldn't mind > doing so myself if you all agree (since I'm not a contributor to the GitHub > repository I'd submit it through a pull request though). > Yes, please! Cheers! > > -Laura Perez Cerrato > > On 22 June 2016 at 10:27, Eliot Miranda wrote: > >> >> Hi Laura, >> >> On Jun 21, 2016, at 7:11 AM, Laura Perez Cerrato < >> lauraperezcerrato@gmail.com> wrote: >> >> Hi everyone, >> >> Excuse me if this has been asked already or it's documented somewhere and >> I missed it, but what's the criteria to update the code in /src, /stacksrc, >> /spursrc and other similar folders in the repository? >> >> >> I should document this. There are three main criteria: >> >> - does the source need to be updated to fix a bug or make available new >> functionality urgently needed? Since up until now my VM builds have been >> manually kicked off on the three platforms it took a while and I'd only do >> new builds when necessary >> >> - does the source look sane? One should always look at the differences >> to the generated source if any part of Slang's translator has been modified >> to check for bugs. >> >> - is the source generated from versioned input? The generated C source >> is marked with the Monticello package version, including UUID, of the >> packages from which it was created (eg a package providing a plugin) and >> that created it (i.e. the VMMaker package). These marks will contain >> asterisks for modified Monticello packages. Clearly one should never check >> in source containing asterisks. The one exception I've allowed myself is >> MiscPrimitivesPlugin which gets generated from base image code, and I have >> a few choice base image modifications (such as a much higher character >> limit on the Transcript, or different code highlighting) that make it >> really painful to keep MiscPrimitivesPlugin clean. >> >> I'm happy for others to generate and check in VM source provided: >> - you carefully check the generated source before checking it in to >> verify that the delta is as expected and no new bugs have been introduced >> - you generate as little change as possible. >> -- There is a script that reverts generated plugins that have changed >> only in their Monticello markings that allows us to not checkin inessential >> revisions to plugins and see when I fact they did change >> -- wrapping the generation code with [...] valueAnswering: false (or >> whatever the selector is) avoids regenerating VM headers (cointerp.h >> cogit.h cogmethod.h interp.h) when these haven't been modified >> >> In short, only do this if you know what you're doing. But got people to >> know what they're doing the process has to be documented along with the >> rationale. I guess this email and my reply to Fabio's question can serve >> as input to that documentation. >> >> -Laura Perez Cerrato >> >> >> _,,,^..^,,,_ (phone) >> >> > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/8befdda8/attachment.htm From Yoshiki.Ohshima at acm.org Thu Jun 23 00:26:34 2016 From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima) Date: Thu Jun 23 00:26:36 2016 Subject: [Vm-dev] Loading VMMaker In-Reply-To: References: Message-ID: Thank you Timothy and Ben! I managed to build SpurVMMaker image and it does run. I'll add a simple VM plugin soon to see that works. On Wed, Jun 22, 2016 at 4:51 PM, Ben Coman wrote: > > > > On Thu, Jun 23, 2016 at 4:13 AM, Yoshiki Ohshima wrote: >> >> >> Hi, >> >> Just to refresh my skill on compiling the Squeak VM (I'd like to play >> with Kinect; I found some efforts like: http://tecnodacta.com.ar/gira/ >> but want to make a plugin that is suitable for my need.) >> >> Let us say I'd like to compile a VM and my plugins on Mac, what are >> the right steps? (I had some experiences with VMMaker but that was >> before I need to specify Interpreter class name in the VMMakerTool, >> for example. >> >> I added VMMaker repository in the Monticello browser, and opened it. >> As trying to just load VMMaker shows a warning of missing FFI >> constants, I turned to 'update' and load update-dtl.17.mcm. Is this a >> right thing to do? >> >> But then, trying to load update-dtl.17.mcm onto the VM and image in >> the 5.0 all in one package, the VM crashes. Do you see this? >> >> I'd like to get the files and image set up so that I can compile an >> external plugin, preferably for Cog/Spur. Some up to date guidance >> would be greatly appreciated. > > > Use a combination of... > * https://github.com/OpenSmalltalk/vm/blob/Cog/CONTRIBUTING.md > * http://www.mirandabanda.org/cogblog/compiling-the-vm/ > > -- -- Yoshiki From lewis at mail.msen.com Thu Jun 23 01:14:36 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Thu Jun 23 01:14:38 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: <20160623011436.GA12932@shell.msen.com> On Thu, Jun 23, 2016 at 01:37:12AM +0800, Ben Coman wrote: > > On Wed, Jun 22, 2016 at 10:02 AM, David T. Lewis wrote: > > > > On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: > >> > >> Hi everyone, > >> > >> Excuse me if this has been asked already or it's documented somewhere and I > >> missed it, but what's the criteria to update the code in /src, /stacksrc, > >> /spursrc and other similar folders in the repository? > >> > >> -Laura Perez Cerrato > > > > Good question. Traditionally, Eliot generates these sources periodically and > > commits them to the repository (and in recent years I have done that chore for > > the old trunk interpreter VM). At this point, unless Eliot advises otherwise, > > I would suggest that no one other than Eliot should commit to the /src trees. > > > > Dave > > > > But... its all one repository. Everyone who works on the vm in their > personal space, doing a dozen generate/compile/commit cycles along the > way, and then finally submits a worthwhile change via a pull request > that is accepted, gets *all* their intermediate generated src added to > the repository. Don't do that. See Eliot's explanation. In addition to what Eliot said, I will add that ./src generated from different images (e.g. two different versions of Squeak, or Squeak versus Pharo) can and will produce different results, even for the same version of VMMaker. It is important to check carefully for changes like this, because they can have huge impacts on performance and functionality. In a perfect world, we would treat the generated ./src as intermediate artifacts to be discarded just as we would discard the object files after compiling a C program. But the world is not perfect, and we need to be able to preserve and distribute the generated ./src files for various reasons, and to do so in a controlled manner. I very strongly advise following Eliot's guidelines. Dave From eliot.miranda at gmail.com Thu Jun 23 03:46:30 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 03:46:32 2016 Subject: [Vm-dev] Functional callbacks on all Cog platforms Message-ID: Hi All, just wanted to report that as of Alien-eem.35 and https://github.com/OpenSmalltalk/vm/commit/da3fafdec9444754af104e0ed9f613f6eb1888d9 we now have functional callbacks on all x86 platforms, ARM32 platforms and x86_64 platforms. There's a simple example Alien class>>exampleCqsort that shows how to use the system and tests the implementation using the C library's sort quick sort implementation that takes a function pointer as an argument to use for comparing pairs of elements. This is mapped onto a Smalltalk block by Alien's callback implementation. The example sorts 100 random double-precision floats using qsort and a callback into Smalltalk. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/1f699a2b/attachment-0001.htm From bert at freudenbergs.de Thu Jun 23 09:33:04 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Jun 23 09:33:06 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: On Wed, Jun 22, 2016 at 7:37 PM, Ben Coman wrote: > > But... its all one repository. Everyone who works on the vm in their > personal space, doing a dozen generate/compile/commit cycles along the > way, and then finally submits a worthwhile change via a pull request > that is accepted, gets *all* their intermediate generated src added to > the repository. > Why would you commit your generated sources at all? And if you do, why would you push them to the public repo? If you chose to commit the generated sources, then you should do so in a private branch that never gets published. You would cherry-pick non-src commits from that branch to a feature branch that you then publish for public consumption. That way the generated sources do not end up in the public repo. This is one advantage of git over svn: "commit" does not mean "publish", you still have to "push". You can have as many branches on your own machine as you like. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/aa96ca34/attachment.htm From estebanlm at gmail.com Thu Jun 23 09:58:59 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Thu Jun 23 09:59:04 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> <432E02D8-CACC-4CCE-B93C-C6B2D4B693CD@hartl.name> Message-ID: <7A4FA243-FFB6-41C9-9281-66BC650152DC@gmail.com> I want to clarify how we do it in Pharo, and why we think is a good approach. Please, note that I?m not asking to change anything, I?m just doing story telling :) 1) In Pharo, since a couple of years, VMMaker *and* plugin sources coexist along with platform sources, in same repository. pharovm/ image/ platforms/ mc/ ?> This is the important! VMMaker.package/ Freetype-Plugin.package/ ? ... (we take the effort of keeping the plugin packages here, as a mirror from his original repositories, but this is more or less automated and also, we think it worths the effort) 2) In Pharo, CI build always rebuild all source code: - it builds an image, using a BaselineOf from Metacello - then it builds ALL sources - then builds the VM 3) CI also executes all Pharo tests (we have an acceptable number of tests) Of course, doing all this in development time is losing time, but in CI is very important and produces significant advantages: 1) we know exactly which version (including Monticello versions) correspond with each build (and if we want to reproduce it, is a simple checkout) 2) we know immediately if a recent change breaks VMMaker image build (some times has happened) 3) we know immediately if a change broke compilation as a side effect (this happens more of less often, specially when working with the C translator) 4) we know immediately if a change broke something image side This process will change now, as we adopt OS/vm, but in our plans we will keep parts of this model. We will include OS/vm as submodule along with the packages: pharovm/ @osvm/ ?> this is a submodule mc/ - we will first generate image using our method - then we will follow OS/vm method, using this image (a Pharo image? for us is very important to be able to build the VM from Pharo) - we will generate sources using it - and then we?ll generate the VM using the OS/vm method. at least, this is what we are aiming for. Notice that this way everybody has what they want: Eliot and others can continue working how they like, and we have what we want: a complete reconstruction process who verifies everything. Once put in place, this system will also benefit non-pharo users, because there will be the feedback available too. cheers, Esteban > On 22 Jun 2016, at 13:15, Esteban Lorenzano wrote: > > >> On 22 Jun 2016, at 12:52, phil@highoctane.be wrote: >> >> One could thing of doing a git submodule with them but it is more trouble than it is worth. >> >> I want to be able to clone the VM and compile it right away. >> >> Phil >> >> On Wed, Jun 22, 2016 at 10:11 AM, Norbert Hartl > wrote: >> >> >>> Am 22.06.2016 um 09:51 schrieb Fabio Niephaus >: >>> >>> AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build. >>> Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository. >>> >> How would you release a version of the vm? This is only possible of you archive the static artefacts. > > I do not understand this question, so maybe I?m answering anything :) > in Pharo, VMMaker package sources coexist along with C sources (thanks to filetree for now, but we are working on enhance that). This way, each release of VM in github contains *exactly* all the sources needed to reconstruct it? > > Esteban > >> >> Norbert >> >>> Fabio >>> >>> [1] https://github.com/pharo-project/pharo-vm >>> [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors >>> >>> -- >>> >>> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis > wrote: >>> >>> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote: >>> > >>> > Hi everyone, >>> > >>> > Excuse me if this has been asked already or it's documented somewhere and I >>> > missed it, but what's the criteria to update the code in /src, /stacksrc, >>> > /spursrc and other similar folders in the repository? >>> > >>> > -Laura Perez Cerrato >>> >>> Good question. Traditionally, Eliot generates these sources periodically and >>> commits them to the repository (and in recent years I have done that chore for >>> the old trunk interpreter VM). At this point, unless Eliot advises otherwise, >>> I would suggest that no one other than Eliot should commit to the /src trees. >>> >>> Dave >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/3cc47c22/attachment.htm From bert at freudenbergs.de Thu Jun 23 11:11:28 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Jun 23 11:11:31 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: <8F4BBEA0-3815-429D-9D87-43A6841347E1@gmail.com> References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> <8F4BBEA0-3815-429D-9D87-43A6841347E1@gmail.com> Message-ID: On Wed, Jun 22, 2016 at 10:15 PM, Eliot Miranda wrote: > > Hi Bert, > Do you have a reproducible case for me to look at? > Yes, from one email ago: * (ByteString new: 20000000) become: (WideString new: 20000000)* The fix I submitted fixes your original case. But you could try and fix > it yourself. If the become: is two-way and fails with out-of-memory the > failure code should ask to grow memory by the sum of the instance byte > sizes. > The failure code in *elementsExchangeIdentityWith:* asks the memory to grow by a fixed amount and retry: ec == #'insufficient object memory' ifTrue: [Smalltalk garbageCollect < 1048576 ifTrue: [Smalltalk *growMemoryByAtLeast:* 1048576]. ^ self elementsExchangeIdentityWith: otherArray]. After a few repetitions of this there *should* be enough room. The problem is that *growMemoryByAtLeast:* does *not* grow the memory, it apparently only assures that the given amount is available. If that is indeed the intention of primitive 180, we should rename it to something like *ensureMemoryAtLeastFree:*. There us a bytesSzeOfInstance: method (or close) to compute the required > space. > This seems to work, yes: ec == #'insufficient object memory' ifTrue: [Smalltalk *ensureMemoryAtLeastFree*: ({self. otherArray} detectSum: [:array | array detectSum: [:obj | obj class byteSizeOfInstanceOfSize: obj basicSize]]). ^self elementsExchangeIdentityWith: otherArray]. Would renaming *growMemoryByAtLeast:* (and fixing its comment) make sense? - Bert - > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/bb941d47/attachment-0001.htm From btc at openinworld.com Thu Jun 23 12:35:35 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 23 12:35:57 2016 Subject: [Vm-dev] The code in the src folders in the repository In-Reply-To: References: <20160622020243.GA38983@shell.msen.com> Message-ID: On Thu, Jun 23, 2016 at 5:33 PM, Bert Freudenberg wrote: > > On Wed, Jun 22, 2016 at 7:37 PM, Ben Coman wrote: > >> >> But... its all one repository. Everyone who works on the vm in their >> personal space, doing a dozen generate/compile/commit cycles along the >> way, and then finally submits a worthwhile change via a pull request >> that is accepted, gets *all* their intermediate generated src added to >> the repository. >> > > Why would you commit your generated sources at all? And if you do, why > would you push them to the public repo? > I *don't* want to commit my generated sources. But** there they are, tracked files that have been modified so I need to weed out the changes I do want to commit. **Likely I'm overthinking this; its an imagined scenario. I should wait to comment further until I actually hit this scenario so at least I know which foot I'm putting in my mouth. :) cheers -ben > > If you chose to commit the generated sources, then you should do so in a > private branch that never gets published. You would cherry-pick non-src > commits from that branch to a feature branch that you then publish for > public consumption. That way the generated sources do not end up in the > public repo. > > This is one advantage of git over svn: "commit" does not mean "publish", > you still have to "push". You can have as many branches on your own machine > as you like. > > - Bert - > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/1ec89b9b/attachment.htm From siguctua at gmail.com Thu Jun 23 14:34:05 2016 From: siguctua at gmail.com (Igor Stasenko) Date: Thu Jun 23 14:34:07 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: Hi, Eliot, why not trimming the object (if its size allows it) to mark rest of now-forwader object to be a freespace immediately? Like that you can avoid stressing memory too much by doubling amount of memory needed per each forwaded object involved in become operation. And that, of course, if direct contents swap is not possible. On 22 June 2016 at 16:44, Eliot Miranda wrote: > > Hi Bert, > > > On Jun 22, 2016, at 5:57 AM, Bert Freudenberg > wrote: > > Hi Eliot, > > the become-forward works now, indeed. > > But why is it different with the swapping become? This still gets into an > endless recursion: > > (ByteString new: 20000000) become: (WideString new: 20000000) > > Why is it creating copies at all? > > > because that's how Spur works. Become is lazy; the two objects are turned > into forwarders to copies of each other. If the two objects have the same > byte size as heap objects (rounded up to 8 byte units) their contents can > be exchanged. If they are not, two copies must be created and the two > originals turned into forwarders to the copies. Remember the slides from > my Cambridge talk. > > Spur chooses to trade memory (creating the copies) over time (searching > the entire heap looking fir references). This is the right trade off until > you start becoming objects that are substantial fractions of the entire > heap in size. > > In your case you could avoid the pain simply by making sure the steam had > a wide String as contents in the first place. I understand that may not be > possible. > > > - Bert - > > On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda > wrote: > >> >> Hi Bert, >> >> it was a regression in argument validation for become introduced in >> fixing argument validation for the one-way copy hash case. The code was >> erroneously checking that it had space to create copies of the input >> arguments, even though it was a one-way become. It's a copyHash become and >> that confused it. It's now fixed. I'll generate sources and push and new >> builds should appear shortly ;-) >> >> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg >> wrote: >> >>> >>> I'm reading a 20MB text file. At some point it tries to convert the 20 >>> MB ByteString into an 80 MB WideString using forward become. This fails >>> resulting in an endless loop. The primitive failure code for >>> elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' >>> and it tries again after growing: >>> >>> ec == #'insufficient object memory' ifTrue: >>> [Smalltalk garbageCollect < 1048576 ifTrue: >>> [Smalltalk growMemoryByAtLeast: 1048576]. >>> ^self elementsForwardIdentityTo: otherArray]. >>> >>> but the growMemoryByAtLeast: does not actually grow the memory: >>> >>> {Smalltalk garbageCollect. >>> Smalltalk growMemoryByAtLeast: 1048576. >>> Smalltalk garbageCollect.} >>> >>> ==> #(58576608 16777216 58576608) >>> >>> 58 MB are not enough, but it doesn't grow any further. >>> >>> The question is, why does it try to allocate a new object at all? The >>> WideString exists already. I thought Spur would simply install a forwarder? >>> >>> To reproduce, execute >>> >>> (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) >>> >>> You probably want to follow that with a user interrupt (Cmd-period). >>> >>> This happens using the latest Spur VM from github (r201606160944) >>> >>> - Bert - >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > > > -- Best regards, Igor Stasenko. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/b062e79e/attachment.htm From eliot.miranda at gmail.com Thu Jun 23 14:55:04 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 14:55:09 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> <8F4BBEA0-3815-429D-9D87-43A6841347E1@gmail.com> Message-ID: <75EB112D-507D-47D4-A55B-1A10CB2C0492@gmail.com> Hi Bert, > On Jun 23, 2016, at 4:11 AM, Bert Freudenberg wrote: > >> On Wed, Jun 22, 2016 at 10:15 PM, Eliot Miranda wrote: >> >> Hi Bert, >> Do you have a reproducible case for me to look at? > > Yes, from one email ago: > > (ByteString new: 20000000) become: (WideString new: 20000000) > >> The fix I submitted fixes your original case. But you could try and fix it yourself. If the become: is two-way and fails with out-of-memory the failure code should ask to grow memory by the sum of the instance byte sizes. > > The failure code in elementsExchangeIdentityWith: asks the memory to grow by a fixed amount and retry: > > ec == #'insufficient object memory' > ifTrue: [Smalltalk garbageCollect < 1048576 > ifTrue: [Smalltalk growMemoryByAtLeast: 1048576]. > ^ self elementsExchangeIdentityWith: otherArray]. > > After a few repetitions of this there should be enough room. > > The problem is that growMemoryByAtLeast: does not grow the memory, it apparently only assures that the given amount is available. If that is indeed the intention of primitive 180, we should rename it to something like ensureMemoryAtLeastFree:. That's not true. growMemoryByAtLeast: does indeed grow memory, but does so by adding a segment. So you don't get contiguous memory of a size that's the sum of extant free space and the amount grown. You're only guaranteed to get contiguous memory of the size you grow memory by. > >> There us a bytesSzeOfInstance: method (or close) to compute the required space. > > This seems to work, yes: > > ec == #'insufficient object memory' ifTrue: > [Smalltalk ensureMemoryAtLeastFree: ({self. otherArray} detectSum: > [:array | array detectSum: > [:obj | obj class byteSizeOfInstanceOfSize: obj basicSize]]). > ^self elementsExchangeIdentityWith: otherArray]. > > Would renaming growMemoryByAtLeast: (and fixing its comment) make sense? I'll fix growMemoryByAtLeast:'s comment. But commit the above, provided you use growMemoryByAtLeast:. > > - Bert - > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/b15c2abb/attachment-0001.htm From eliot.miranda at gmail.com Thu Jun 23 15:00:25 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 15:00:30 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: Hi Igor, > On Jun 23, 2016, at 7:34 AM, Igor Stasenko wrote: > > Hi, Eliot, > > why not trimming the object (if its size allows it) to mark rest of now-forwader object to be a freespace immediately? > Like that you can avoid stressing memory too much by doubling amount of memory needed per each forwaded object involved in become operation. > And that, of course, if direct contents swap is not possible. Agreed. Would you like to have a go and I'll review it? The problem with truncating short objects is that Spur's memory manager cannot represent a free chunk of only 8 bytes in length. The minimum sized free chunk (& minimum sized object) is 16 bytes. And any size higher (24, 32, 40 etc) is ok. So if you want to shorten a 24 byte object to 16 bytes because it's been turned into a forwarder, you can't because that would leave an 8-byte sliver. So be sure to check that the object is > 24 bytes long before trying to truncate it. > >> On 22 June 2016 at 16:44, Eliot Miranda wrote: >> >> Hi Bert, >> >> >>> On Jun 22, 2016, at 5:57 AM, Bert Freudenberg wrote: >>> >>> Hi Eliot, >>> >>> the become-forward works now, indeed. >>> >>> But why is it different with the swapping become? This still gets into an endless recursion: >>> >>> (ByteString new: 20000000) become: (WideString new: 20000000) >>> >>> Why is it creating copies at all? >> >> because that's how Spur works. Become is lazy; the two objects are turned into forwarders to copies of each other. If the two objects have the same byte size as heap objects (rounded up to 8 byte units) their contents can be exchanged. If they are not, two copies must be created and the two originals turned into forwarders to the copies. Remember the slides from my Cambridge talk. >> >> Spur chooses to trade memory (creating the copies) over time (searching the entire heap looking fir references). This is the right trade off until you start becoming objects that are substantial fractions of the entire heap in size. >> >> In your case you could avoid the pain simply by making sure the steam had a wide String as contents in the first place. I understand that may not be possible. >> >>> >>> - Bert - >>> >>>> On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda wrote: >>>> >>>> Hi Bert, >>>> >>>> it was a regression in argument validation for become introduced in fixing argument validation for the one-way copy hash case. The code was erroneously checking that it had space to create copies of the input arguments, even though it was a one-way become. It's a copyHash become and that confused it. It's now fixed. I'll generate sources and push and new builds should appear shortly ;-) >>>> >>>>> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg wrote: >>>>> >>>>> I'm reading a 20MB text file. At some point it tries to convert the 20 MB ByteString into an 80 MB WideString using forward become. This fails resulting in an endless loop. The primitive failure code for elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' and it tries again after growing: >>>>> >>>>> ec == #'insufficient object memory' ifTrue: >>>>> [Smalltalk garbageCollect < 1048576 ifTrue: >>>>> [Smalltalk growMemoryByAtLeast: 1048576]. >>>>> ^self elementsForwardIdentityTo: otherArray]. >>>>> >>>>> but the growMemoryByAtLeast: does not actually grow the memory: >>>>> >>>>> {Smalltalk garbageCollect. >>>>> Smalltalk growMemoryByAtLeast: 1048576. >>>>> Smalltalk garbageCollect.} >>>>> >>>>> ==> #(58576608 16777216 58576608) >>>>> >>>>> 58 MB are not enough, but it doesn't grow any further. >>>>> >>>>> The question is, why does it try to allocate a new object at all? The WideString exists already. I thought Spur would simply install a forwarder? >>>>> >>>>> To reproduce, execute >>>>> >>>>> (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) >>>>> >>>>> You probably want to follow that with a user interrupt (Cmd-period). >>>>> >>>>> This happens using the latest Spur VM from github (r201606160944) >>>>> >>>>> - Bert - >>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot > > > > -- > Best regards, > Igor Stasenko. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/8f11feb4/attachment.htm From siguctua at gmail.com Thu Jun 23 15:11:33 2016 From: siguctua at gmail.com (Igor Stasenko) Date: Thu Jun 23 15:11:36 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: On 23 June 2016 at 18:00, Eliot Miranda wrote: > > Hi Igor, > > On Jun 23, 2016, at 7:34 AM, Igor Stasenko wrote: > > Hi, Eliot, > > why not trimming the object (if its size allows it) to mark rest of > now-forwader object to be a freespace immediately? > Like that you can avoid stressing memory too much by doubling amount of > memory needed per each forwaded object involved in become operation. > And that, of course, if direct contents swap is not possible. > > > Agreed. Would you like to have a go and I'll review it? The problem with > truncating short objects is that Spur's memory manager cannot represent a > free chunk of only 8 bytes in length. The minimum sized free chunk (& minimum > sized object) is 16 bytes. And any size higher (24, 32, 40 etc) is ok. So > if you want to shorten a 24 byte object to 16 bytes because it's been > turned into a forwarder, you can't because that would leave an 8-byte > sliver. So be sure to check that the object is > 24 bytes long before > trying to truncate it. > That's why i said - if its size allows it. I could give it try.. Of course i will need some more details, to do it fast, like updating a first-free object pointer, if needed and what limitations there, and things like if it safe to throw this newly-free object space into a soup of free chunks regardless of their location in memory (old heap/eden etc) I would be glad, if you can give me quick brief of these potential pitfall, since i don't know much about new spur memory model innards. > > On 22 June 2016 at 16:44, Eliot Miranda wrote: > >> >> Hi Bert, >> >> >> On Jun 22, 2016, at 5:57 AM, Bert Freudenberg >> wrote: >> >> Hi Eliot, >> >> the become-forward works now, indeed. >> >> But why is it different with the swapping become? This still gets into an >> endless recursion: >> >> (ByteString new: 20000000) become: (WideString new: 20000000) >> >> Why is it creating copies at all? >> >> >> because that's how Spur works. Become is lazy; the two objects are >> turned into forwarders to copies of each other. If the two objects have >> the same byte size as heap objects (rounded up to 8 byte units) their >> contents can be exchanged. If they are not, two copies must be created and >> the two originals turned into forwarders to the copies. Remember the >> slides from my Cambridge talk. >> >> Spur chooses to trade memory (creating the copies) over time (searching >> the entire heap looking fir references). This is the right trade off until >> you start becoming objects that are substantial fractions of the entire >> heap in size. >> >> In your case you could avoid the pain simply by making sure the steam had >> a wide String as contents in the first place. I understand that may not be >> possible. >> >> >> - Bert - >> >> On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda >> wrote: >> >>> >>> Hi Bert, >>> >>> it was a regression in argument validation for become introduced in >>> fixing argument validation for the one-way copy hash case. The code was >>> erroneously checking that it had space to create copies of the input >>> arguments, even though it was a one-way become. It's a copyHash become and >>> that confused it. It's now fixed. I'll generate sources and push and new >>> builds should appear shortly ;-) >>> >>> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg >>> wrote: >>> >>>> >>>> I'm reading a 20MB text file. At some point it tries to convert the 20 >>>> MB ByteString into an 80 MB WideString using forward become. This fails >>>> resulting in an endless loop. The primitive failure code for >>>> elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' >>>> and it tries again after growing: >>>> >>>> ec == #'insufficient object memory' ifTrue: >>>> [Smalltalk garbageCollect < 1048576 ifTrue: >>>> [Smalltalk growMemoryByAtLeast: 1048576]. >>>> ^self elementsForwardIdentityTo: otherArray]. >>>> >>>> but the growMemoryByAtLeast: does not actually grow the memory: >>>> >>>> {Smalltalk garbageCollect. >>>> Smalltalk growMemoryByAtLeast: 1048576. >>>> Smalltalk garbageCollect.} >>>> >>>> ==> #(58576608 16777216 58576608) >>>> >>>> 58 MB are not enough, but it doesn't grow any further. >>>> >>>> The question is, why does it try to allocate a new object at all? The >>>> WideString exists already. I thought Spur would simply install a forwarder? >>>> >>>> To reproduce, execute >>>> >>>> (ByteString new: 20000000) writeStream nextPut: (Character value: >>>> 128169) >>>> >>>> You probably want to follow that with a user interrupt (Cmd-period). >>>> >>>> This happens using the latest Spur VM from github (r201606160944) >>>> >>>> - Bert - >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/1feb36ea/attachment-0001.htm From eliot.miranda at gmail.com Thu Jun 23 18:36:16 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 18:36:19 2016 Subject: [Vm-dev] [Spur] endless recursion in forward become In-Reply-To: References: <605CC9C3-1457-4B2B-9B20-F03B176C8B60@gmail.com> Message-ID: Hi Igor, On Thu, Jun 23, 2016 at 8:11 AM, Igor Stasenko wrote: > > > > On 23 June 2016 at 18:00, Eliot Miranda wrote: > >> >> Hi Igor, >> >> On Jun 23, 2016, at 7:34 AM, Igor Stasenko wrote: >> >> Hi, Eliot, >> >> why not trimming the object (if its size allows it) to mark rest of >> now-forwader object to be a freespace immediately? >> Like that you can avoid stressing memory too much by doubling amount of >> memory needed per each forwaded object involved in become operation. >> And that, of course, if direct contents swap is not possible. >> >> >> Agreed. Would you like to have a go and I'll review it? The problem >> with truncating short objects is that Spur's memory manager cannot >> represent a free chunk of only 8 bytes in length. The minimum sized free >> chunk (& minimum sized object) is 16 bytes. And any size higher (24, >> 32, 40 etc) is ok. So if you want to shorten a 24 byte object to 16 bytes >> because it's been turned into a forwarder, you can't because that would >> leave an 8-byte sliver. So be sure to check that the object is > 24 bytes >> long before trying to truncate it. >> > > That's why i said - if its size allows it. > I could give it try.. Of course i will need some more details, to do it > fast, like updating a first-free object pointer, if needed and what > limitations there, and things like if it safe to throw this newly-free > object space into a soup of free chunks regardless of their location in > memory (old heap/eden etc) > See SpurMemoryManager>>shorten:toIndexableSize: for a utility that is close to what you need. > > I would be glad, if you can give me quick brief of these potential > pitfall, since i don't know much about new spur memory model innards. > I think the sliver problem is the only pitfall. Basically follow shorten:toIndexableSize: to see what to do with the remnant. Good luck! On 22 June 2016 at 16:44, Eliot Miranda wrote: >> >>> >>> Hi Bert, >>> >>> >>> On Jun 22, 2016, at 5:57 AM, Bert Freudenberg >>> wrote: >>> >>> Hi Eliot, >>> >>> the become-forward works now, indeed. >>> >>> But why is it different with the swapping become? This still gets into >>> an endless recursion: >>> >>> (ByteString new: 20000000) become: (WideString new: 20000000) >>> >>> Why is it creating copies at all? >>> >>> >>> because that's how Spur works. Become is lazy; the two objects are >>> turned into forwarders to copies of each other. If the two objects have >>> the same byte size as heap objects (rounded up to 8 byte units) their >>> contents can be exchanged. If they are not, two copies must be created and >>> the two originals turned into forwarders to the copies. Remember the >>> slides from my Cambridge talk. >>> >>> Spur chooses to trade memory (creating the copies) over time (searching >>> the entire heap looking fir references). This is the right trade off until >>> you start becoming objects that are substantial fractions of the entire >>> heap in size. >>> >>> In your case you could avoid the pain simply by making sure the steam >>> had a wide String as contents in the first place. I understand that may >>> not be possible. >>> >>> >>> - Bert - >>> >>> On Mon, Jun 20, 2016 at 10:36 PM, Eliot Miranda >> > wrote: >>> >>>> >>>> Hi Bert, >>>> >>>> it was a regression in argument validation for become introduced in >>>> fixing argument validation for the one-way copy hash case. The code was >>>> erroneously checking that it had space to create copies of the input >>>> arguments, even though it was a one-way become. It's a copyHash become and >>>> that confused it. It's now fixed. I'll generate sources and push and new >>>> builds should appear shortly ;-) >>>> >>>> On Thu, Jun 16, 2016 at 5:11 AM, Bert Freudenberg >>> > wrote: >>>> >>>>> >>>>> I'm reading a 20MB text file. At some point it tries to convert the 20 >>>>> MB ByteString into an 80 MB WideString using forward become. This fails >>>>> resulting in an endless loop. The primitive failure code for >>>>> elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' >>>>> and it tries again after growing: >>>>> >>>>> ec == #'insufficient object memory' ifTrue: >>>>> [Smalltalk garbageCollect < 1048576 ifTrue: >>>>> [Smalltalk growMemoryByAtLeast: 1048576]. >>>>> ^self elementsForwardIdentityTo: otherArray]. >>>>> >>>>> but the growMemoryByAtLeast: does not actually grow the memory: >>>>> >>>>> {Smalltalk garbageCollect. >>>>> Smalltalk growMemoryByAtLeast: 1048576. >>>>> Smalltalk garbageCollect.} >>>>> >>>>> ==> #(58576608 16777216 58576608) >>>>> >>>>> 58 MB are not enough, but it doesn't grow any further. >>>>> >>>>> The question is, why does it try to allocate a new object at all? The >>>>> WideString exists already. I thought Spur would simply install a forwarder? >>>>> >>>>> To reproduce, execute >>>>> >>>>> (ByteString new: 20000000) writeStream nextPut: (Character value: >>>>> 128169) >>>>> >>>>> You probably want to follow that with a user interrupt (Cmd-period). >>>>> >>>>> This happens using the latest Spur VM from github (r201606160944) >>>>> >>>>> - Bert - >>>>> >>>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > > > -- > Best regards, > Igor Stasenko. > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/43713b88/attachment.htm From tim at rowledge.org Thu Jun 23 19:54:19 2016 From: tim at rowledge.org (tim Rowledge) Date: Thu Jun 23 19:54:02 2016 Subject: [Vm-dev] git build problem on Pi Message-ID: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Since I still have no real idea how this git stuff works I may have done something wrong here? I downloaded the new git vm tree using SourceTree (and what an ?interesting? experience installing that was; no, not really, it was just unpleasant) and obtained what appears to be a very reasonable pile of files. I did nothing else - no configuring of git stuff. Then on my Pi I cd?d to the relevant build.linux32ARM/squeak.cog.spur/build directory as usual and ran `sudo ./mvm` as normal. (Hafta use sudo because of some idiocy in xrdp) It seemed to build ok. Then I went to the ?products? directory to copy out the new vm to test. The problem is that the products/cogspurlinuxhtARM/lib/squeak directory contains a directory named ?5.0-?. Which means that for some reason the version number has not been generated, found, copied, used, or whatever. What did I miss? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Loyalty oaths.Secret searches.No-fly lists.Detention without legal recourse.Remind me - who won the cold war? From casimiro.barreto at gmail.com Thu Jun 23 20:40:10 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Thu Jun 23 20:40:25 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 Message-ID: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/1f071108/signature-0001.pgp From estebanlm at gmail.com Thu Jun 23 21:04:45 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Thu Jun 23 21:04:49 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> Message-ID: <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> Hi, as I told you in the users list, this is not enough information :( - when it crashes? - normally crash should let a crash.dmp file? - also a way to reproduce the problem would be cool? a description of what you are doing, etc. cheers, Esteban ps: this one: 53.zip is compiled in debug mode, but I do not think you will get more information from there. > On 23 Jun 2016, at 22:40, Casimiro - GMAIL wrote: > > VMs are crashing. In the case of Pharo 5.0 VM does that SIGSEGV thing. Trace is: > > Pharo 5 crashes. VM does a SIGSEGV 0x00000000 at start > > Running GDB I got: > > (gdb) run > Starting program: /home/CdAB63/Downloads/pharo5.0/bin/pharo > Missing separate debuginfos, use: dnf debuginfo-install glibc-2.23.1-8.fc24.i686 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) backtrace full > #0 0x00000000 in ?? () > No symbol table info available. > #1 0xf7f3dd7e in __pthread_once_slow () from /lib/libpthread.so.0 > No symbol table info available. > #2 0xf7aa9c05 in ?? () from /lib/libGL.so.1 > No symbol table info available. > #3 0xf7a722ab in ?? () from /lib/libGL.so.1 > No symbol table info available. > #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 > No symbol table info available. > #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 > No symbol table info available. > #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 > No symbol table info available. > #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > No symbol table info available. > #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 > No symbol table info available. > #9 0xf7f4dc05 in dlopen_doit () from /lib/libdl.so.2 > No symbol table info available. > #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > No symbol table info available. > #11 0xf7f4e35d in _dlerror_run () from /lib/libdl.so.2 > No symbol table info available. > #12 0xf7f4dcae in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 > No symbol table info available. > #13 0x080bd60f in tryLoading () > No symbol table info available. > #14 0x080bd751 in ioLoadModule () > No symbol table info available. > #15 0x080bf18b in queryLoadModule () > No symbol table info available. > #16 0x080bf27f in queryModule () > No symbol table info available. > #17 0x080bf2c7 in loadImplicit () > No symbol table info available. > #18 0x0805ccd7 in main () > No symbol table info available. > (gdb) > Would be helpful if VM was compiled in debug mode so it would possible to understand better what's happening. > > -- > The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. > > == > > This email may be signed using PGP key ID: 0x4134A417 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/a8c18546/attachment.htm From casimiro.barreto at gmail.com Thu Jun 23 21:22:09 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Thu Jun 23 21:22:28 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> Message-ID: <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/116e7e33/signature-0001.pgp From eliot.miranda at gmail.com Thu Jun 23 21:35:20 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 21:35:23 2016 Subject: [Vm-dev] Mac OS X autorelease crash Message-ID: Hi, here's another Process: Squeak [96917] Path: /Users/USER/*/CocoaFast.app/Contents/MacOS/Squeak Identifier: org.squeak.Squeak$(VM_MONIKER) Version: 5.0.201606202053 (5.0.201606202053) Code Type: X86 (Native) Parent Process: launchd [186] Responsible: Squeak [96917] User ID: 594 Date/Time: 2016-06-23 11:39:36.916 -0700 OS Version: Mac OS X 10.9.5 (13F1808) Report Version: 11 Anonymous UUID: F54BABC9-4764-81AE-0375-EA1A9A4A38C2 Sleep/Wake UUID: 02B5D29D-A0A9-414F-93DC-4EA822100B81 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 VM Regions Near 0: --> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Users/USER/*/CocoaFast.app/Contents/MacOS/Squeak VM_ALLOCATE 0000000000001000-000000000006e000 [ 436K] ---/--- SM=NUL Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x00000000 ecx: 0x00000000 edx: 0x00206300 edi: 0xcc001000 esi: 0x98f848f2 ebp: 0xbfeef1c8 esp: 0xbfeef190 ss: 0x00000023 efl: 0x00010282 eip: 0x98f84a80 cs: 0x0000001b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x00000000 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x98f84a80 (anonymous namespace)::AutoreleasePoolPage::autoreleaseSlow(objc_object*) + 412 1 libobjc.A.dylib 0x98f96799 _objc_rootAutorelease2(objc_object*) + 72 2 com.apple.CoreFoundation 0x9822bf2d +[NSArray arrayWithObjects:] + 413 3 com.apple.Foundation 0x91bfdbd4 +[NSFileAttributes _populateCatInfo:forURL:statInfo:error:] + 89 4 com.apple.Foundation 0x91bfda2c +[NSFileAttributes _attributesAtPath:partialReturn:filterResourceFork:error:] + 374 5 com.apple.Foundation 0x91bfd8ad -[NSFileManager attributesOfItemAtPath:error:] + 66 6 org.squeak.Squeak$(VM_MONIKER) 0x000e3d26 -[sqSqueakFileDirectoryInterface attributesForPath:fileMgr:isDirectory:creationDate:modificationDate:sizeIfFile:posixPermissions:isSymlink:] + 63 (sqSqueakFileDirectoryInterface.m:92) 7 org.squeak.Squeak$(VM_MONIKER) 0x000e43f0 -[sqSqueakFileDirectoryInterface dir_Lookup:length:index:name:length:creationDate:modificationDate:isDirectory:sizeIfFile:posixPermissions:isSymlink:] + 840 (sqSqueakFileDirectoryInterface.m:246) 8 org.squeak.Squeak$(VM_MONIKER) 0x000e388e dir_Lookup + 156 (sqSqueakFileDirectoryAPI.m:108) 9 org.squeak.Squeak$(VM_MONIKER) 0x00101669 primitiveDirectoryLookup + 257 10 ??? 0x04935ce8 0 + 76766440 11 org.squeak.Squeak$(VM_MONIKER) 0x0006fa5a interpret + 741 (gcc3x-cointerp.c:2547) 12 org.squeak.Squeak$(VM_MONIKER) 0x000e62ac -[sqSqueakMainApplication runSqueak] + 476 (sqSqueakMainApplication.m:200) 13 com.apple.Foundation 0x91c5af70 __NSFirePerformWithOrder + 419 14 com.apple.CoreFoundation 0x9822a2be __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 15 com.apple.CoreFoundation 0x9822a20f __CFRunLoopDoObservers + 399 16 com.apple.CoreFoundation 0x9821b02e __CFRunLoopRun + 974 17 com.apple.CoreFoundation 0x9821a9ea CFRunLoopRunSpecific + 394 18 com.apple.CoreFoundation 0x9821a84b CFRunLoopRunInMode + 123 19 com.apple.HIToolbox 0x95b21b5d RunCurrentEventLoopInMode + 259 20 com.apple.HIToolbox 0x95b21777 ReceiveNextEventCommon + 163 21 com.apple.HIToolbox 0x95b216bd _BlockUntilNextEventMatchingListInModeWithFilter + 92 22 com.apple.AppKit 0x961f7349 _DPSNextEvent + 1602 23 com.apple.AppKit 0x961f6870 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119 24 com.apple.AppKit 0x961e915c -[NSApplication run] + 727 25 com.apple.AppKit 0x961d1ff8 NSApplicationMain + 1165 26 libdyld.dylib 0x9aacb701 start + 1 _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/97ced50b/attachment.htm From bwestergaard at gmail.com Thu Jun 23 21:37:46 2016 From: bwestergaard at gmail.com (Bob Westergaard) Date: Thu Jun 23 21:37:47 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge wrote: > What did I miss? I believe this can happen if you don't *first* run scripts/updateSCCSVersions after you clone the repository: https://github.com/OpenSmalltalk/vm#important-notice-for-developers Regards, -- Bob From estebanlm at gmail.com Thu Jun 23 21:39:32 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Thu Jun 23 21:39:37 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> Message-ID: <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> can you try this one? cog_linux32x86_squeak.stack.spur_201606230315.tar.gz pharo will not work completely but at least we will know if is pharovm flavour or all vm?s Esteban > On 23 Jun 2016, at 23:22, Casimiro - GMAIL wrote: > > Em 23-06-2016 18:04, Esteban Lorenzano escreveu: >> >> >> >> Hi, >> >> as I told you in the users list, this is not enough information :( >> >> - when it crashes? >> - normally crash should let a crash.dmp file? >> - also a way to reproduce the problem would be cool? a description of what you are doing, etc. >> >> cheers, >> Esteban >> >> ps: this one: 53.zip >> is compiled in debug mode, but I do not think you will get more information from there. >> >>> On 23 Jun 2016, at 22:40, Casimiro - GMAIL < casimiro.barreto@gmail.com > wrote: >>> >>> VMs are crashing. In the case of Pharo 5.0 VM does that SIGSEGV thing. Trace is: >>> >>> Pharo 5 crashes. VM does a SIGSEGV 0x00000000 at start >>> >>> Running GDB I got: >>> >>> (gdb) run >>> Starting program: /home/CdAB63/Downloads/pharo5.0/bin/pharo >>> Missing separate debuginfos, use: dnf debuginfo-install glibc-2.23.1-8.fc24.i686 >>> [Thread debugging using libthread_db enabled] >>> Using host libthread_db library "/lib64/libthread_db.so.1". >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x00000000 in ?? () >>> (gdb) backtrace full >>> #0 0x00000000 in ?? () >>> No symbol table info available. >>> #1 0xf7f3dd7e in __pthread_once_slow () from /lib/libpthread.so.0 >>> No symbol table info available. >>> #2 0xf7aa9c05 in ?? () from /lib/libGL.so.1 >>> No symbol table info available. >>> #3 0xf7a722ab in ?? () from /lib/libGL.so.1 >>> No symbol table info available. >>> #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 >>> No symbol table info available. >>> #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 >>> No symbol table info available. >>> #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 >>> No symbol table info available. >>> #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 >>> No symbol table info available. >>> #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 >>> No symbol table info available. >>> #9 0xf7f4dc05 in dlopen_doit () from /lib/libdl.so.2 >>> No symbol table info available. >>> #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 >>> No symbol table info available. >>> #11 0xf7f4e35d in _dlerror_run () from /lib/libdl.so.2 >>> No symbol table info available. >>> #12 0xf7f4dcae in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 >>> No symbol table info available. >>> #13 0x080bd60f in tryLoading () >>> No symbol table info available. >>> #14 0x080bd751 in ioLoadModule () >>> No symbol table info available. >>> #15 0x080bf18b in queryLoadModule () >>> No symbol table info available. >>> #16 0x080bf27f in queryModule () >>> No symbol table info available. >>> #17 0x080bf2c7 in loadImplicit () >>> No symbol table info available. >>> #18 0x0805ccd7 in main () >>> No symbol table info available. >>> (gdb) >>> Would be helpful if VM was compiled in debug mode so it would possible to understand better what's happening. > Just sent the core dump. > Problem happens every time the following command is issued: > > pharo (the shell script) > > or even > > $> cd shared > $> ../bin/pharo > > It seems to be a problem with thread infrastructure in the Fedora 24 (for in the debug I see that pharo starts with the i686 libraries but then something happens and it tries a /usr/lib64/libthread_db.so.1 > > #0 0x00000000 in ?? () > #1 0xf7f3cd7e in __pthread_once_slow () from /lib/libpthread.so.0 > #2 0xf7aa7c05 in ?? () from /lib/libGL.so.1 > #3 0xf7a702ab in ?? () from /lib/libGL.so.1 > #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 > #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 > #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 > #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 > #9 0xf7f4cc05 in dlopen_doit () from /lib/libdl.so.2 > #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > #11 0xf7f4d35d in _dlerror_run () from /lib/libdl.so.2 > #12 0xf7f4ccae in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 > #13 0x080bd60f in tryLoading () > #14 0x080bd751 in ioLoadModule () > #15 0x080bf18b in queryLoadModule () > #16 0x080bf27f in queryModule () > #17 0x080bf2c7 in loadImplicit () > #18 0x0805ccd7 in main () > >>> >>> >>> -- >>> The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. >>> >>> == >>> >>> This email may be signed using PGP key ID: 0x4134A417 >> > > > -- > The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. > > == > > This email may be signed using PGP key ID: 0x4134A417 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/2683f505/attachment-0001.htm From casimiro.barreto at gmail.com Thu Jun 23 22:47:24 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Thu Jun 23 22:47:40 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> Message-ID: <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/8fd6ac8f/signature.pgp From eliot.miranda at gmail.com Thu Jun 23 23:05:33 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Jun 23 23:05:36 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> Message-ID: So if you do ldd on the vm-display-X11 module are all the libraries found? Here's an example output on ARM: eliot@pi2 ~/all/Squeak/Squeak5.0 $ ldd ~/all/oscogvm/products/cogspurlinuxhtARM/lib/squeak/5.0-201606212031/vm-display-X11 /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x76f80000) libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0x76f5a000) libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x76f4c000) libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 (0x76f2f000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76f24000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76f05000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e93000) libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x76e77000) libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x76e6a000) libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 (0x76da6000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76c92000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76b61000) /lib/ld-linux-armhf.so.3 (0x76fae000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76b39000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76b2a000) libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76b0b000) libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x76b01000) libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x76af4000) On Thu, Jun 23, 2016 at 3:47 PM, Casimiro - GMAIL < casimiro.barreto@gmail.com> wrote: > > Em 23-06-2016 18:39, Esteban Lorenzano escreveu: > > > > can you try this one? > > cog_linux32x86_squeak.stack.spur_201606230315.tar.gz > > > pharo will not work completely but at least we will know if is pharovm > flavour or all vm?s > > Esteban > > The trace for this VM is as follows and it seems to be complaining about > the vm-display-X11 module: > > [CdAB63@localhost 5.0-201606230315]$ gdb ./squeak > GNU gdb (GDB) Fedora 7.11.1-75.fc24 > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > > . > Find the GDB manual and other documentation resources online at: > > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./squeak...done. > (gdb) run > Starting program: > /home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/squeak > > Missing separate debuginfos, use: dnf debuginfo-install > glibc-2.23.1-8.fc24.i686 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) backtrace full > #0 0x00000000 in ?? () > No symbol table info available. > #1 0xf7f92d7e in __pthread_once_slow () from /lib/libpthread.so.0 > No symbol table info available. > #2 0xf7aa7c05 in ?? () from /lib/libGL.so.1 > No symbol table info available. > #3 0xf7a702ab in ?? () from /lib/libGL.so.1 > No symbol table info available. > #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 > No symbol table info available. > #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 > No symbol table info available. > #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 > No symbol table info available. > #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > No symbol table info available. > #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 > No symbol table info available. > #9 0xf7fa2c05 in dlopen_doit () from /lib/libdl.so.2 > No symbol table info available. > #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > No symbol table info available. > #11 0xf7fa335d in _dlerror_run () from /lib/libdl.so.2 > No symbol table info available. > #12 0xf7fa2cae in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 > No symbol table info available. > #13 0x080a08a7 in tryLoading (dirName=0xffffac2c > "/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/", > moduleName=0xffffbc8c "vm-display-X11") > at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixExternalPrims.c:245 > libName = > "/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/vm-display-X11\000\377y\214\376\367\000\000\000\000W\253\377\377\003\000\000\000\000\000\000\000\070\000\000\000\000\000\000\000[\000\000\000\000\000\000\000n\000\000\000\000\000\000\000w\000\000\000\000\000\000\000|\000\000\000\000\360\371\367\377\377\377\177\201\000\000\000~-\371\367\260$\372\367\060`\372\367\351Q\335\367\000\300\362\367`\307\362\367\220+\372\367`\373\001\000\367{\335\367\353\201\376\367\000"... > buf = {st_dev = 64770, __pad1 = 53052, __st_ino = 14420702, > st_mode = 33261, st_nlink = 1, st_uid = 1000, st_gid = 1000, st_rdev = 0, > __pad2 = 53044, st_size = 264943, > st_blksize = 4096, st_blocks = 520, st_atim = {tv_sec = > 1466720855, tv_nsec = 541848724}, st_mtim = {tv_sec = 1466652243, tv_nsec = > 0}, st_ctim = {tv_sec = 1466720774, > tv_nsec = 231755653}, st_ino = 14420702} > prefixes = {0x8123af4 "", 0x8127d62 "lib", 0x0} > suffixes = {0x8123af4 "", 0x8127d5b ".so", 0x8127d5f ".dylib", 0x0} > handle = > prefix = > suffix = > #14 0x080a0ac1 in ioLoadModule (pluginName=0xffffbc8c "vm-display-X11") at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixExternalPrims.c:328 > path = > "/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/", > '\000' > c = > in = > out = > handle = 0x0 > #15 0x0805e75f in queryLoadModule (type=0x8123911 "display", > name=0x81238d9 "X11", query=1) at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1079 > handle = > modName = > "vm-display-X11\000\377q\335\005\b\033\275\377\377\200\254\027\b\001\020", > '\000' , > "\002\375\000\000\000\000\000\000\000\000\000\000\335\n\334\000\355\201\000\000\001\000\000\000\350\003\000\000\350\003", > '\000' , > "*'=\000\000\000\000\000\000\020\000\000\230\036\000\000\000\000\000\000WblW\033\"\341\037KVkW\000\000\000\000\006blWS\002\204\r\335\n\334\000\000\000\000\000\000\000\000/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak"... > itfName = > "display_X11\000\353:\335\367\000\300\362\367k\336\377\377\222;\022\bDI\000" > module = > itf = 0x0 > #16 0x0805e83f in queryModule (type=0x8123911 "display", name=0x81238d9 > "X11") at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1112 > ---Type to continue, or q to quit--- > No locals. > #17 0x0805e88b in loadImplicit (addr=0x8159928 , > evar=, type=, name=0x81238d9 "X11") > at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1205 > No locals. > #18 0x0805d4bb in loadModules () at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1217 > No locals. > #19 main (argc=1, argv=0xffffcf34, envp=0xffffcf3c) at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1935 > No locals. > (gdb) > > -- > The information contained in this message is confidential and intended to > the recipients specified in the headers. If you received this message by > error, notify the sender immediately. The unauthorized use, disclosure, > copy or alteration of this message are strictly forbidden and subjected to > civil and criminal sanctions. > > == > > This email may be signed using PGP key *ID: 0x4134A417* > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/741113ff/attachment-0001.htm From casimiro.barreto at gmail.com Thu Jun 23 23:21:56 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Thu Jun 23 23:22:33 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> Message-ID: <6353af1a-c18f-b9b9-58af-57e8206260f8@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/472621fb/signature.pgp From casimiro.barreto at gmail.com Thu Jun 23 23:23:43 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Thu Jun 23 23:23:47 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> Message-ID: <346dc424-311f-b9e9-e62f-2c92c4930bec@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/2f49ff33/signature.pgp From lewis at mail.msen.com Fri Jun 24 01:49:06 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 24 01:49:10 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: <20160624014906.GA76992@shell.msen.com> I have a new Raspberry Pi and want to compile the Cog Spur VM. I fetched the latest from SVN (never mind GitHub for now, I'll do that soon): $ svn co http://squeakvm.org/svn/squeak/branches/Cog Then I do a build: pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm clean? /home/pi/squeak/SVN-Cog/Cog/spursrc /home/pi/squeak/SVN-Cog/Cog/src/plugins checking sanity of generated src directory... okay checking build system type... armv7l-unknown-linux-gnu checking host system type... armv7l-unknown-linux-gnu Configuring Squeak (.-) for armv7l-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** No rule to make target 'install-squeak'. Stop. Does anyone recognize this? Googling for "compiler cannot create executables" provides lots of random advice, but I don't see a file permissions problem and most of the rest of the advice looks questionable. The config.log has this (possibly unrelated): gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated. That looks like the same gcc version issue I had with building Spur on my Ubuntu laptop. I had thought it might be easier to just buy a $35 Raspberry Pi rather than fix the autotools configure, but maybe not. Are other people seeing these issues, or is it just me? Compiling and running an interpreter VM on the same Raspberry Pi works fine, so I am assuming this is either an autotools issue or something related to gcc version for the cog/spur build. I am attaching the config.log from the ./mvm session in case it helps. Raspberry Pi OS version information: pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ cat /proc/version Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016 Thanks, Dave -------------- next part -------------- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ ../../../platforms/unix/config/configure --without-npsqueak --without-vm-display-fbdev --with-vmversion=5.0 --with-src=spursrc --without-vm-display-fbdev --without-npsqueak --enable-fast-bitblt CC=gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard CXX=g++ CFLAGS=-g -O2 -fwrapv -DNDEBUG -DDEBUGVM=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 LIBS=-lpthread -luuid -lasound LDFLAGS=-Wl,-z,now ## --------- ## ## Platform. ## ## --------- ## hostname = raspberrypi uname -m = armv7l uname -r = 4.1.19-v7+ uname -s = Linux uname -v = #858 SMP Tue Mar 15 15:56:00 GMT 2016 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/local/games PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1590: result: /home/pi/squeak/SVN-Cog/Cog/spursrc configure:1592: result: /home/pi/squeak/SVN-Cog/Cog/src/plugins configure:1627: checking sanity of generated src directory configure:1656: result: okay configure:1734: checking build system type configure:1752: result: armv7l-unknown-linux-gnu configure:1760: checking host system type configure:1774: result: armv7l-unknown-linux-gnu configure:1831: checking whether make sets $(MAKE) configure:1851: result: yes configure:1906: checking for gcc configure:1932: result: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard configure:2176: checking for C compiler version configure:2179: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard --version &5 gcc (Raspbian 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2182: $? = 0 configure:2184: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -v &5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.9.2 (Raspbian 4.9.2-10) configure:2187: $? = 0 configure:2189: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -V &5 gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated. configure:2192: $? = 4 configure:2215: checking for C compiler default output file name configure:2218: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -g -O2 -fwrapv -DNDEBUG -DDEBUGVM=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wl,-z,now conftest.c -lpthread -luuid -lasound >&5 /usr/bin/ld: cannot find -lasound collect2: error: ld returned 1 exit status configure:2221: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define SQ_VERSION ".-" | #define OS_TYPE "unix" | #define VM_HOST "armv7l-linux-gnu" | #define VM_HOST_OS "linux-gnu" | #define VM_HOST_CPU "armv7l" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2260: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=armv7l-unknown-linux-gnu ac_cv_build_alias=armv7l-unknown-linux-gnu ac_cv_env_CC_set=set ac_cv_env_CC_value='gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard' ac_cv_env_CFLAGS_set=set ac_cv_env_CFLAGS_value='-g -O2 -fwrapv -DNDEBUG -DDEBUGVM=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0' ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXCPP_set= ac_cv_env_CXXCPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set=set ac_cv_env_CXX_value=g++ ac_cv_env_F77_set= ac_cv_env_F77_value= ac_cv_env_FFLAGS_set= ac_cv_env_FFLAGS_value= ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value=-Wl,-z,now ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=armv7l-unknown-linux-gnu ac_cv_host_alias=armv7l-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALLOCA='' AR='' ARM_ARCH='' AS='' AWK='' BITBLT_FLAGS='' BITBLT_OBJS='' CC='gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard' CFLAGS='-g -O2 -fwrapv -DNDEBUG -DDEBUGVM=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0' CPP='' CPPFLAGS='' CXX='g++' CXXCPP='' CXXFLAGS='' DEFS='' ECHO='echo' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' EXEEXT='' F77='' FFLAGS='' HAVE_INTERP_H='' HAVE_LANGINFO_CODESET='' HAVE_NANOSLEEP='' IA32ABI_OBJS='' INCLUDES='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' INTERP='' LD='' LDFLAGS='-Wl,-z,now' LIBM_CFLAGS='' LIBOBJS='' LIBS='-lpthread -luuid -lasound' LIBTOOL='' LIB_UUID='' LN='' LN_S='' LTLIBOBJS='' NM='' OBJEXT='' PACKAGE_BUGREPORT='' PACKAGE_NAME='' PACKAGE_STRING='' PACKAGE_TARNAME='' PACKAGE_VERSION='' PATH_SEPARATOR=':' RANLIB='' SED='' SET_MAKE='' SHELL='/bin/bash' SQ_LIBDIR='' SQ_MAJOR='' SQ_MINOR='' SQ_UPDATE='' SQ_VERSION='.-' STRIP='' VM_APP_ICONS='' VM_DISPX11_BITBLT_FLAGS='' VM_DISPX11_OBJS='' WFLAGS='' X_CFLAGS='' X_CPPFLAGS='' X_EXTRA_LIBS='' X_INCLUDES='' X_LIBS='' X_PRE_LIBS='' ac_ct_AR='' ac_ct_CC='gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard' ac_ct_CXX='' ac_ct_F77='' ac_ct_RANLIB='' ac_ct_STRIP='' bindir='${exec_prefix}/bin' blddir='/home/pi/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build' build='armv7l-unknown-linux-gnu' build_alias='' build_cpu='armv7l' build_os='linux-gnu' build_vendor='unknown' cfgdir='/home/pi/squeak/SVN-Cog/Cog/platforms/unix/config' cogit='yes' datadir='${prefix}/share' exec_prefix='${prefix}' expanded_relative_imgdir='lib/squeak/' ext_modules='' ext_plugins='' host='armv7l-linux-gnu' host_alias='' host_cpu='armv7l' host_os='linux-gnu' host_vendor='unknown' imgdir='${prefix}/lib/squeak' includedir='${prefix}/include' infodir='${prefix}/info' install_nps='' int_modules='' int_plugins='' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localstatedir='${prefix}/var' mandir='${prefix}/man' npsqueak='' oldincludedir='/usr/include' plgdir='${imgdir}/`${blddir}/getversion VERSION_TAG`' prefix='/usr/local' program_transform_name='s,x,x,' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' topdir='/home/pi/squeak/SVN-Cog/Cog' uninstall_nps='' vmmcfg='/home/pi/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build' vmmdir='/home/pi/squeak/SVN-Cog/Cog/spursrc' vmpdir='/home/pi/squeak/SVN-Cog/Cog/src/plugins' ## ------------- ## ## Output files. ## ## ------------- ## Makefile_deb='' Makefile_dist='' Makefile_install='' Makefile_rpm='' make_cfg='' make_ext='' make_int='' make_prg='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define OS_TYPE "unix" #define PACKAGE_BUGREPORT "" #define PACKAGE_NAME "" #define PACKAGE_STRING "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define SQ_VERSION ".-" #define VM_HOST "armv7l-linux-gnu" #define VM_HOST_CPU "armv7l" #define VM_HOST_OS "linux-gnu" configure: exit 77 From btc at openinworld.com Fri Jun 24 02:13:09 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 02:13:31 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: On Fri, Jun 24, 2016 at 5:37 AM, Bob Westergaard wrote: > > On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge wrote: > > What did I miss? > > I believe this can happen if you don't *first* run > scripts/updateSCCSVersions after you clone the repository: > > https://github.com/OpenSmalltalk/vm#important-notice-for-developers > > Regards, > -- Bob > Could mvm be made to look for signs that this has been run and output a warning if it hasn't? cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/c5f9de6c/attachment.htm From pbpublist at gmail.com Fri Jun 24 02:19:23 2016 From: pbpublist at gmail.com (Phil (list)) Date: Fri Jun 24 02:19:27 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <20160624014906.GA76992@shell.msen.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> Message-ID: <1466734763.2453.14.camel@gmail.com> On Thu, 2016-06-23 at 21:49 -0400, David T. Lewis wrote: > ? > I have a new Raspberry Pi and want to compile the Cog Spur VM. > > I fetched the latest from SVN (never mind GitHub for now, I'll do > that soon): > > ? $ svn co http://squeakvm.org/svn/squeak/branches/Cog > > Then I do a build: > > ? pi@raspberrypi:~/squeak/SVN- > Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm > ? clean?? > ? /home/pi/squeak/SVN-Cog/Cog/spursrc > ? /home/pi/squeak/SVN-Cog/Cog/src/plugins > ? checking sanity of generated src directory... okay > ? checking build system type... armv7l-unknown-linux-gnu > ? checking host system type... armv7l-unknown-linux-gnu > ?? > ? Configuring Squeak??(.-) for armv7l-linux-gnu > ?? > ? checking whether make sets $(MAKE)... yes > ? checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard > ? checking for C compiler default output file name... configure: > error: C compiler cannot create executables > ? See `config.log' for more details. > ? make: *** No rule to make target 'install-squeak'.??Stop. > > Does anyone recognize this? Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ?Remove the line with the compiler flags?"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ?That fixed the issue for me for ARMv7 builds. From btc at openinworld.com Fri Jun 24 02:23:09 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 02:23:32 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: <6353af1a-c18f-b9b9-58af-57e8206260f8@gmail.com> References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> <6353af1a-c18f-b9b9-58af-57e8206260f8@gmail.com> Message-ID: On Fri, Jun 24, 2016 at 7:21 AM, Casimiro - GMAIL < casimiro.barreto@gmail.com> wrote: > > Em 23-06-2016 20:05, Eliot Miranda escreveu: > > > > So if you do ldd on the vm-display-X11 module are all the libraries > found? Here's an example output on ARM: > > eliot@pi2 ~/all/Squeak/Squeak5.0 $ ldd > ~/all/oscogvm/products/cogspurlinuxhtARM/lib/squeak/5.0-201606212031/vm-display-X11 > /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x76f80000) > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 > (0x76f5a000) > libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x76f4c000) > libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 > (0x76f2f000) > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76f24000) > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 > (0x76f05000) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e93000) > libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x76e77000) > libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x76e6a000) > libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 > (0x76da6000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 > (0x76c92000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76b61000) > /lib/ld-linux-armhf.so.3 (0x76fae000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 > (0x76b39000) > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76b2a000) > libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 > (0x76b0b000) > libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 > (0x76b01000) > libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 > (0x76af4000) > > > That's the result: > > [CdAB63@localhost 5.0-201606230315]$ ldd vm-display-X11 > linux-gate.so.1 (0xf7712000) > libGL.so.1 => /lib/libGL.so.1 (0xf75b6000) > libXext.so.6 => /lib/libXext.so.6 (0xf75a2000) > libpthread.so.0 => /lib/libpthread.so.0 (0xf7586000) > libX11.so.6 => /lib/libX11.so.6 (0xf7445000) > libc.so.6 => /lib/libc.so.6 (0xf7276000) > libnvidia-tls.so.361.45.11 => /lib/libnvidia-tls.so.361.45.11 > (0xf7271000) > libnvidia-glcore.so.361.45.11 => /lib/libnvidia-glcore.so.361.45.11 > (0xf4fe9000) > libdl.so.2 => /lib/libdl.so.2 (0xf4fe4000) > /lib/ld-linux.so.2 (0x56555000) > libxcb.so.1 => /lib/libxcb.so.1 (0xf4fbe000) > libm.so.6 => /lib/libm.so.6 (0xf4f67000) > libXau.so.6 => /lib/libXau.so.6 (0xf4f63000) > [CdAB63@localhost 5.0-201606230315]$ > > But I feel that perhaps the thing is that Fedora 24 comes with wayland by > default. And disabling wayland causes erratic behaviour of interface... :( > I'm checking on that. > But... thing is: it bangs on the libpthread... > I see the libraries found are in /lib but the error is reported in /lib64 So what do you get for... $ ls -l /*/libpthread* and presuming there is a /lib32, try something like... $ LD_LIBRARY_PATH=/lib32 ./pharo cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/280eb7c1/attachment.htm From lewis at mail.msen.com Fri Jun 24 02:35:47 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 24 02:35:48 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <1466734763.2453.14.camel@gmail.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> Message-ID: <20160624023547.GA88002@shell.msen.com> On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: > > On Thu, 2016-06-23 at 21:49 -0400, David T. Lewis wrote: > > ?? > > I have a new Raspberry Pi and want to compile the Cog Spur VM. > > > > I fetched the latest from SVN (never mind GitHub for now, I'll do > > that soon): > > > > ?? $ svn co http://squeakvm.org/svn/squeak/branches/Cog > > > > Then I do a build: > > > > ?? pi@raspberrypi:~/squeak/SVN- > > Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm > > ?? clean??? > > ?? /home/pi/squeak/SVN-Cog/Cog/spursrc > > ?? /home/pi/squeak/SVN-Cog/Cog/src/plugins > > ?? checking sanity of generated src directory... okay > > ?? checking build system type... armv7l-unknown-linux-gnu > > ?? checking host system type... armv7l-unknown-linux-gnu > > ???? > > ?? Configuring Squeak????(.-) for armv7l-linux-gnu > > ???? > > ?? checking whether make sets $(MAKE)... yes > > ?? checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard > > ?? checking for C compiler default output file name... configure: > > error: C compiler cannot create executables > > ?? See `config.log' for more details. > > ?? make: *** No rule to make target 'install-squeak'.????Stop. > > > > Does anyone recognize this? > > Yes, I ran into it as well... the build is hard-coded to build for the > ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- > march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue > for me for ARMv7 builds. Phil, Brilliant! I removed the -march=armv6 and it compiles now. Thank you, Dave From tim at rowledge.org Fri Jun 24 02:55:50 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 24 02:55:32 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <20160624023547.GA88002@shell.msen.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> Message-ID: <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> > On 23-06-2016, at 7:35 PM, David T. Lewis wrote: > > > On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: >> {snip} >> Yes, I ran into it as well... the build is hard-coded to build for the >> ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- >> march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue >> for me for ARMv7 builds. > > Phil, > > Brilliant! I removed the -march=armv6 and it compiles now.\ That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as I know and don?t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get past it? First thing, try `sudo ./mvm`. If you?re using xrdp to connect to your Pi it makes some odd things happen to do with permissions. And as for why changing that flag should have anything to do with the problem? frakkin? insane unix nonsense yet again. Yup, the vm I built this lunchtime has the armv6 flag on. Built perfectly well aside from the sccs version number issue I mentioned before. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother!" said Pooh, as Piglet pressed on the Microwave... From tim at rowledge.org Fri Jun 24 02:56:53 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 24 02:56:35 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: <1319AB97-3872-4B67-BE44-F2E0B0E60B8A@rowledge.org> > On 23-06-2016, at 7:13 PM, Ben Coman wrote: > > > > On Fri, Jun 24, 2016 at 5:37 AM, Bob Westergaard wrote: > > On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge wrote: > > What did I miss? > > I believe this can happen if you don't *first* run > scripts/updateSCCSVersions after you clone the repository: > > https://github.com/OpenSmalltalk/vm#important-notice-for-developers > > Regards, > -- Bob > > Could mvm be made to look for signs that this has been run and output a warning if it hasn't? > cheers -ben Better yet, surely we could run the damned command if needed... tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim This is all a lot simpler and a lot more complicated than you could possibly imagine From btc at openinworld.com Fri Jun 24 03:26:47 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 03:27:09 2016 Subject: [Vm-dev] build products seem to go to the wrong branch Message-ID: I just did my first vm build from git... $ git checkout -b firstbuild Cog $ cd image $ ./buildspurtrunkvmmakerimage.sh $ cd build.linux32x86/squeak.cog.spur/build $ ./mvm Which completes okay, but reports... Libraries have been installed in: /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606221719-btc/condense-gitignore but condense-gitignore is not the current branch, but a previous branch I worked on where I didn't even do a build (I'm reasonably sure, but maybe I forget). $ git branch [snip] * firstbuild btc/condense-gitignore I poked around and found the message comes from ./platforms/unix/config/ltmain.sh but I don't see any git commands there to determine the branch, so it seems the branch must be passed to ltmain from somewhere else?? cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/e19fcc85/attachment.htm From pbpublist at gmail.com Fri Jun 24 03:52:48 2016 From: pbpublist at gmail.com (Phil (list)) Date: Fri Jun 24 03:52:52 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> Message-ID: <1466740368.2453.34.camel@gmail.com> On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote: > ? > > > On 23-06-2016, at 7:35 PM, David T. Lewis > > wrote: > > > > > > On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: > > > {snip} > > > Yes, I ran into it as well... the build is hard-coded to build > > > for the > > > ARMv6 of the original Pi. ??Remove the line with the compiler > > > flags??"- > > > march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the > > > issue > > > for me for ARMv7 builds. > > > > Phil, > > > > Brilliant! I removed the -march=armv6 and it compiles now.\ > > That is both weird and in some sense wrong; Eliot & I use the armv6 > flag so far as??I know and don?t have this issue. I *did* have this > problem a very long time ago though. The question is whether I can > find any evidence of what I did to get??past it? > IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. ?Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)? ?Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf) > First thing, try `sudo ./mvm`. If you?re using xrdp to connect to > your Pi it makes some odd things happen to do with permissions. > > And as for why changing that flag should have anything to do with the > problem? frakkin? insane unix nonsense yet again. Yup, the vm I built > this lunchtime has the armv6 flag on. Built perfectly well aside from > the sccs version number issue I mentioned before. > The Linux world decided a while back that ARMv7 was the minimum for hard float but then the rpi became a thing with its ARMv6 which, unlike many/most other versions of the v6, included hard float. ?So look at it more as the Linux world viewing ARMv6 as being unsupported like the Intel 486 or older (I think they even bumped that up to Pentium recently)... i.e. it's unsupported by default on modern distros, but of course you can still build a custom distro that supports it as they did for the Pi. ?So this puts the original Pi in the odd position of being unsupported by any of the armhf distros where the Pi 2 and later can run most of them. ?But running a non-Raspberry armhf distro likely also means that you have this issue of not being able to build ARMv6 binaries. From pbpublist at gmail.com Fri Jun 24 04:04:06 2016 From: pbpublist at gmail.com (Phil (list)) Date: Fri Jun 24 04:04:10 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <1466740368.2453.34.camel@gmail.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> Message-ID: <1466741046.2453.41.camel@gmail.com> On Thu, 2016-06-23 at 23:52 -0400, Phil (list) wrote: > The Linux world decided a while back that ARMv7 was the minimum for > hard float but then the rpi became a thing with its ARMv6 which, > unlike > many/most other versions of the v6, included hard float. ?So look at > it > more as the Linux world viewing ARMv6 as being unsupported like the > Intel 486 or older (I think they even bumped that up to Pentium > recently)... i.e. it's unsupported by default on modern distros, but > of > course you can still build a custom distro that supports it as they > did > for the Pi. ?So this puts the original Pi in the odd position of > being > unsupported by any of the armhf distros where the Pi 2 and later can > run most of them. ?But running a non-Raspberry armhf distro likely > also > means that you have this issue of not being able to build ARMv6 > binaries. Just thought of a possibly better way to explain this for anyone who remembers the bad old days: remember how great it was when the Intel 486 came out and you could assume anyone running on a 486 had hardware floating point? ?Then the 486SX with disabled FP came out and screwed that assumption up. ?The Pi 1 was essentially the reverse of that: a 386 with a built-in 387 which became wildly popular... not what the Linux world was expecting. From btc at openinworld.com Fri Jun 24 04:16:14 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 04:16:37 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: <1319AB97-3872-4B67-BE44-F2E0B0E60B8A@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <1319AB97-3872-4B67-BE44-F2E0B0E60B8A@rowledge.org> Message-ID: On Fri, Jun 24, 2016 at 10:56 AM, tim Rowledge wrote: > > > > On 23-06-2016, at 7:13 PM, Ben Coman wrote: > > > > > > > > On Fri, Jun 24, 2016 at 5:37 AM, Bob Westergaard > wrote: > > > > On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge wrote: > > > What did I miss? > > > > I believe this can happen if you don't *first* run > > scripts/updateSCCSVersions after you clone the repository: > > > > https://github.com/OpenSmalltalk/vm#important-notice-for-developers > > > > Regards, > > -- Bob > > > > Could mvm be made to look for signs that this has been run and output a > warning if it hasn't? > > cheers -ben > > Better yet, surely we could run the damned command if needed... > tim > > Silent failures due to operator error increase the friction to people to get involved, and propagates the error handling to the mail list rather than handling it locally. But also see my other post "build products seem to go to the wrong branch" where it seems *every* time you change branches you need to run ./mvm... ../../../scripts/updateSCCSVersions #from the build directory so why not make it part of mvm? cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/ce894e20/attachment.htm From btc at openinworld.com Fri Jun 24 04:17:41 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 04:18:03 2016 Subject: [Vm-dev] Re: build products seem to go to the wrong branch In-Reply-To: References: Message-ID: On Fri, Jun 24, 2016 at 11:26 AM, Ben Coman wrote: > I just did my first vm build from git... > > $ git checkout -b firstbuild Cog > $ cd image > $ ./buildspurtrunkvmmakerimage.sh > $ cd build.linux32x86/squeak.cog.spur/build > $ ./mvm > Which completes okay, but reports... > Libraries have been installed in: > > /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606221719-btc/condense-gitignore > > but condense-gitignore is not the current branch, but a previous branch I > worked on where I didn't even do a build (I'm reasonably sure, but maybe I > forget). > > $ git branch > [snip] > * firstbuild > btc/condense-gitignore > > I poked around and found the message comes from > ./platforms/unix/config/ltmain.sh > but I don't see any git commands there to determine the branch, so it > seems the branch must be passed to ltmain from somewhere else?? > > cheers -ben > > I was sure I had run scripts/updateSCCSVersions before, but running it again fixed the problem $ cd ~/Repos/OpenSmalltalk/vm $ rm -r * $ git checkout -b firstbuild Cog $ git reset --hard HEAD # not sure if this is the best command to use here $ scripts/updateSCCSVersions $ cd build.linux32x86/squeak.cog.spur/build $ ./mvm clean? y Libraries have been installed in: /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606230315-firstbuild However... $ git checkout -b secondbuild Cog $ /mvm clean? y Libraries have been installed in: /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606230315-firstbuild $ ../../../scripts/updateSCCSVersions $ ./mvm clean? y Libraries have been installed in: /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606182358-secondbuild So it seems updateSCCSVersions needs to be run *every* time I change branch before running ./mvm. Should it be added to mvm? cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/921e42b5/attachment-0001.htm From btc at openinworld.com Fri Jun 24 08:16:15 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 08:16:38 2016 Subject: [Vm-dev] Can't infer base LD_LIBRARY_PATH In-Reply-To: References: Message-ID: Here is the proposed change... https://github.com/OpenSmalltalk/vm/pull/15 On Sun, May 22, 2016 at 10:11 PM, Ben Coman wrote: > (btw, Actually I am running ./buildspurtrunkvmmakerimage.sh) > > So I found that ./buildspurtrunkvmmakerimage.sh > creates directory cogspurlinuxht > containing shell script 'squeak' > which for LD_LIBRARY_PATH hard codes eight alternative libc locations. > But after reformatting (see attached) a pattern is apparent such that > the following generic substitution seems appropriate (and worked for > me)... > > LIBC_SO="`/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed > 's/^.*=> \([^ ]*\).*/\1/'`" > LIB=`expr "$LIBC_SO" : '\(.*\)/libc.*'` > if [ "$LIB" = "" ]; then > echo ERROR: Could not determine libc path for VM > exit 1 > fi > SVMLLP="$LIB:/lib:/usr$LIB:/usr/lib" > LD_LIBRARY_PATH="$PLUGINS:$SVMLLP:${LD_LIBRARY_PATH}" exec $GDB > "$BIN/squeak" "$@" > > except for /lib , /lib32 and /lib64 which substitute as... > SVMLLP="$LIB:/usr$LIB" > > Now I read [1] "The standard paths [/lib and /usr/lib] will still be > searched, but only after the list of paths in LD_LIBRARY_PATH has been > exhausted." So I wonder what is the advantage of interleaving the > standard paths with $LIB ones ? If /lib and /usr/lib could just be > left to be "searched anyway" at the end, the the above snippet seems > to cover all existing cases - and likely new cases without change. > > [1] > http://wiredrevolution.com/system-administration/how-to-correctly-use-ld_library_path > > cheers -ben > > On Sun, May 22, 2016 at 2:16 AM, Eliot Miranda > wrote: > > > > Hi Ben, > > > > just be sure to post your augmentation of the script back here so the > scripts can be updated in svn-soon-to-be-github. > > > > On Fri, May 20, 2016 at 8:54 PM, Ben Coman wrote: > >> > >> > >> On Sat, May 21, 2016 at 4:44 AM, Cl?ment Bera > wrote: > >> > > >> > On Fri, May 20, 2016 at 7:29 PM, Ben Coman > wrote: > >> >> > >> >> I've decided to try and get the simulator working for the first > >> >> time this weekend. Its been interesting poking through the VM with > >> >> gdb, but its not "exactly" fun. > >> > > >> > > >> > Normally if you build a cog development image: > >> > $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image > >> > $ cd ./image > >> > $ ./buildsqueaktrunkvmmakerimage.sh > >> > >> I'm sure I've built successfully from there before, but right now I'm > >> getting and error.. > >> cogspurlinuxht/squeak trunk50.image UpdateSqueakTrunkImage.st > >> Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for > >> /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 to cogspurlinuxht/squeak. > >> Please report your edit to squeak vm-dev. > >> > >> cogspurlinuxht/squeak SpurVMMaker.image > BuildSqueakSpurTrunkVMMakerImage.st > >> Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for > >> /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 to cogspurlinuxht/squeak. > >> Please report your edit to squeak vm-dev. > >> > >> I'm in the process of tracking that down, but just reporting in case > >> there is a known quick fix. btw, I'm on Debian Jessie > >> Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt20-1+deb8u3 > >> (2016-01-17) i686 GNU/Linux > >> > >> cheers -ben > >> > >> > > >> > You have multiple scripts available with comments to run the > simulator that work out of the box. It should take a couple minutes to get > it working. Then the easiest is to simulate a REPL image to easily debug > what you want. > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/014f1a9f/attachment.htm From btc at openinworld.com Fri Jun 24 08:41:40 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 08:42:03 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> Message-ID: On Tue, Jun 21, 2016 at 6:55 PM, Ben Coman wrote: > On Tue, Jun 21, 2016 at 6:46 PM, Ben Coman wrote: > > On Tue, Jun 21, 2016 at 5:38 PM, Dimitris Chloupis > > wrote: > >> > >> ah ok i see now, actually you will get empty results in the search > because github searches for repo first > >> > >> openSmalltalk is not the name of a repo its the name of the user so you > have to click to user and it will it to you > >> > >> so its both found by google and github > > > > Ahh. Thats quite an insight that I hadn't noticed before. Also the > > first 8 results searching github for "vm" are 8 different projects. > > One of the reasons for moving to github is get more visibility. I'm > > afraid like this that we'll be lost in the noise. > > > > Actually when I made my fork of the repo, I'd noticed the project > > seemed to lose its identity as... > > https://github.com/bencoman/vm > > but I didn't worry to much about it since "I" knew what it was. But > > confusion in the public arena on github is more serious. > > > > Since its still quite early days on github, can I ask consideration be > > given to renaming the repo so we have... > > https://github.com/OpenSmalltalk/opensmalltalk-vm > > https://github.com/bencoman/opensmalltalk-vm > > That it will show up in both searches for "smalltalk" and "vm" > > I think this is important to getting the most long term value out git & > github. > If OpenSmalltalk/opensmalltalk-vm is considered too unwieldly, some alternatives could be: * OpenSmalltalk/osvm (this has a single conflicting exact match on github [last updated 4 years ago], and a four substring matches) * OpenSmalltalk/ostvm (for which github return no results) The reason I suggest this is the old real estate adage "location, location, location" has a corollary these days with internet search of "uniqueness, uniqueness, uniqueness". Then again, its only a small thing and there is plenty of other important things to do. cheers -ben Github help pages indicate existing infrastructure should continue to > work to the old name, easing the transition. > https://help.github.com/articles/renaming-a-repository/ > > For authorised users, this should link where the rename can be done.. > https://github.com/OpenSmalltalk/vm/settings > > cheers -ben > > > > > cheers -ben > > > >> > >> On Tue, Jun 21, 2016 at 12:35 PM Phil (list) > wrote: > >>> > >>> > >>> On Tue, 2016-06-21 at 11:05 +0200, Denis Kudriashov wrote: > >>> > > >>> > Hi. > >>> > > >>> > Maybe I am super stupid. But I just tried to find new GitHub > >>> > repository for VM and I can't. > >>> > Of course I found it here but Google and GitHub not show me any > >>> > results. > >>> > At least GitHub surprised me. Is anything correct with repo settings? > >>> > >>> Searching for 'OpenSmalltalk' got me the GitHub repo as the 3rd result > >>> with Google. Since it's a new repo, perhaps it's still being added to > >>> the indexes and/or propagating out through their infrastructure and/or > >>> their algorithms are still deciding where it fits in the search > >>> results? GitHub can also take several days before new projects can be > >>> found via their search. > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/4ed99e83/attachment.htm From bert at freudenbergs.de Fri Jun 24 08:53:33 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Fri Jun 24 08:53:36 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> Message-ID: On Fri, Jun 24, 2016 at 10:41 AM, Ben Coman wrote: > > > Since its still quite early days on github, can I ask consideration be >> > given to renaming the repo so we have... >> > https://github.com/OpenSmalltalk/opensmalltalk-vm >> > https://github.com/bencoman/opensmalltalk-vm >> > +1 > If OpenSmalltalk/opensmalltalk-vm is considered too unwieldly, > some alternatives could be: > * OpenSmalltalk/osvm (this has a single conflicting exact match on github > [last updated 4 years ago], and a four substring matches) > * OpenSmalltalk/ostvm (for which github return no results) > IMHO opensmalltalk-vm is best after all. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/ea280d66/attachment-0001.htm From lewis at mail.msen.com Fri Jun 24 13:24:59 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 24 13:25:01 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> Message-ID: <20160624132459.GA18277@shell.msen.com> On Thu, Jun 23, 2016 at 07:55:50PM -0700, tim Rowledge wrote: > > > > On 23-06-2016, at 7:35 PM, David T. Lewis wrote: > > > > > > On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: > >> {snip} > >> Yes, I ran into it as well... the build is hard-coded to build for the > >> ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- > >> march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue > >> for me for ARMv7 builds. > > > > Phil, > > > > Brilliant! I removed the -march=armv6 and it compiles now.\ > > That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as I know and don???t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get past it??? > > First thing, try `sudo ./mvm`. If you???re using xrdp to connect to your Pi it makes some odd things happen to do with permissions. > I was working through an ssh connection, so sudo was not required. > And as for why changing that flag should have anything to do with the problem??? frakkin??? insane unix nonsense yet again. Yup, the vm I built this lunchtime has the armv6 flag on. Built perfectly well aside from the sccs version number issue I mentioned before. > For reference, my /proc/cpuinfo is (one of the 4 cores): model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 76.80 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Compiler version: gcc (Raspbian 4.9.2-10) 4.9.2 Dave From lewis at mail.msen.com Fri Jun 24 13:36:26 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 24 13:36:28 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <1466740368.2453.34.camel@gmail.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> Message-ID: <20160624133626.GB18277@shell.msen.com> On Thu, Jun 23, 2016 at 11:52:48PM -0400, Phil (list) wrote: > > On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote: > > ?? > > > > > On 23-06-2016, at 7:35 PM, David T. Lewis > > > wrote: > > > > > > > > > On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: > > > > {snip} > > > > Yes, I ran into it as well... the build is hard-coded to build > > > > for the > > > > ARMv6 of the original Pi. ??Remove the line with the compiler > > > > flags??"- > > > > march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the > > > > issue > > > > for me for ARMv7 builds. > > > > > > Phil, > > > > > > Brilliant! I removed the -march=armv6 and it compiles now.\ > > > > That is both weird and in some sense wrong; Eliot & I use the armv6 > > flag so far as????I know and don???t have this issue. I *did* have this > > problem a very long time ago though. The question is whether I can > > find any evidence of what I did to get????past it??? > > > > IIRC, it has to do with the build of gcc that is installed for (most?) > ARMv7 distros. ??Are you and Elliot using an armel or armhf based > installs or just the stock rpi install (which is ARMv6 hf I think)? > ??Most of the ARM world (with the notable exception of rpi) is running > armhf these days which is where the problem seems to be (i.e. I was > able to build using the shipped mvm as-is on armel, but not armhf) > Also regarding the gcc version, it looks like the configure script is getting rather old. I see this in my config log: g++: error: unrecognized command line option '-V' This apparently had no ill effect on the build for Pi, but it's important because I think that the -V option has gone away in recent gcc versions, and that is what prevented me from being able to build Cog/Spur on my Intel Ubuntu laptop. I ran out of patience trying to rebuild the autotools configuration, and that is what finally prompted me to buy this Raspberry Pi :-) So ... I think that somebody with more patience than me is going to need to update the autotools build one of these days. Dave From lewis at mail.msen.com Fri Jun 24 13:37:42 2016 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Jun 24 13:37:44 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <1466741046.2453.41.camel@gmail.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> <1466741046.2453.41.camel@gmail.com> Message-ID: <20160624133742.GC18277@shell.msen.com> On Fri, Jun 24, 2016 at 12:04:06AM -0400, Phil (list) wrote: > > On Thu, 2016-06-23 at 23:52 -0400, Phil (list) wrote: > > The Linux world decided a while back that ARMv7 was the minimum for > > hard float but then the rpi became a thing with its ARMv6 which, > > unlike > > many/most other versions of the v6, included hard float. ??So look at > > it > > more as the Linux world viewing ARMv6 as being unsupported like the > > Intel 486 or older (I think they even bumped that up to Pentium > > recently)... i.e. it's unsupported by default on modern distros, but > > of > > course you can still build a custom distro that supports it as they > > did > > for the Pi. ??So this puts the original Pi in the odd position of > > being > > unsupported by any of the armhf distros where the Pi 2 and later can > > run most of them. ??But running a non-Raspberry armhf distro likely > > also > > means that you have this issue of not being able to build ARMv6 > > binaries. > > Just thought of a possibly better way to explain this for anyone who > remembers the bad old days: remember how great it was when the Intel > 486 came out and you could assume anyone running on a 486 had hardware > floating point? ??Then the 486SX with disabled FP came out and screwed > that assumption up. ??The Pi 1 was essentially the reverse of that: a > 386 with a built-in 387 which became wildly popular... not what the > Linux world was expecting. Great explanation, thanks. Dave From btc at openinworld.com Fri Jun 24 14:11:01 2016 From: btc at openinworld.com (Ben Coman) Date: Fri Jun 24 14:11:24 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: On Mon, Jun 20, 2016 at 5:55 PM, Tim Felgentreff wrote: > > > I've pushed a CONTRIBUTING.md to the repository that we can iterate > over and discuss. > > If you go to https://github.com/OpenSmalltalk/vm/commit/5052e307fda0369f04550966fcfdf0a372aeaf39 > you can leave comments inline or at the end. > Thanks Tim, thats a really good starting point. Usually github would be the place to comment in-line, but this influences community workflow a a broader audience is useful. The thing I want to understand most is the strong discouragement of rebasing rather than using it to maintain a tidy history. First there is... > This also means that you should avoid rebasing or squashing > your work. Just keep the history. I happened to look at Laura's PR that adds some good info to CONTRIBUTING, so I use that as an example... https://github.com/OpenSmalltalk/vm/pull/14 Do you really want all four commits to appear in the master history? I hunted up a dozen articles around this point, and even though a little long winded, the best was this one... http://blog.izs.me/post/37650663670/git-rebase I particularly liked how the two camps of rebase or not were characterised into platform or service, as well as the explanation of bisect. Then there is... > Every so many commits it is a good idea to push your work. > Please refrain from rebasing, unless your history looks like this: So the need for history cleanup is alluded to, but no guidance is given on *how* to do it safely. The critical point to make is to distinguish between cleaning private branches and leaving public branches alone. This is a good article providing some examples... https://sandofsky.com/blog/git-workflow.html Thirdly there is... > However, if you're unsure what rebasing is, just forget about it > and push the history as-is. Again this seems to instil fear of a very useful tool for cleaning up work in progress commits before submitting a pull request. But first the community needs to discuss the degree to which a clean linear history is beneficial or desired. Then we might define some recipes to achieve that. Finally it says... > You will be thankful later when you need to use `git bisect` to find where a bug comes from. But IIUC, bisect works better with a clean and linear history. Also from the the repository network graph... https://github.com/OpenSmalltalk/vm/network before the 25 May the SVN history is *very* linear (or is this just an artefact of the migration?) And after the 19 June (considering only within the OpenSmalltalk swim lane, i.e. ignoring the personal repo forks) the history is less linear. Now branching is one of git's greatest strengths to encourage participation, but that doesn't mean every branch needs a permanent record in the trunk history. So considering one particular workflow case, an afternoons work on documentation or a quick bug fix, which yet may have several commits but is only pushed once upon completion -- I believe a reasonable workflow here would be for `rebase -i` to squash down to a single commit prior to issuing the pull request. Any subsequent commits to the PR from feedback would remain separate until it is ready to integrate, when the integrator could squash them as described here... "Merge pull request? [Big Green Button] Considered Harmful https://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful However it sounds like you've some personal war stories that might be useful for us to hear. To me rebase seems straightforward for certain defined situations, but maybe there is more about the risks I need to learn... > Seriously, skipping bad commits a bisect is easier than fixing > someones git tree once they have lost commits to the depths of reflog. > Especially if their recovery attempts have already triggered a Git GC. cheers -ben From eliot.miranda at gmail.com Fri Jun 24 16:40:56 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 16:41:00 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <20160624014906.GA76992@shell.msen.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> Message-ID: David, have you read build.linux32ARM/HowToBuild and made sure you've installed the necessary support packages? _,,,^..^,,,_ (phone) > On Jun 23, 2016, at 6:49 PM, David T. Lewis wrote: > > I have a new Raspberry Pi and want to compile the Cog Spur VM. > > I fetched the latest from SVN (never mind GitHub for now, I'll do that soon): > > $ svn co http://squeakvm.org/svn/squeak/branches/Cog > > Then I do a build: > > pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm > clean? > /home/pi/squeak/SVN-Cog/Cog/spursrc > /home/pi/squeak/SVN-Cog/Cog/src/plugins > checking sanity of generated src directory... okay > checking build system type... armv7l-unknown-linux-gnu > checking host system type... armv7l-unknown-linux-gnu > > Configuring Squeak (.-) for armv7l-linux-gnu > > checking whether make sets $(MAKE)... yes > checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard > checking for C compiler default output file name... configure: error: C compiler cannot create executables > See `config.log' for more details. > make: *** No rule to make target 'install-squeak'. Stop. > > Does anyone recognize this? > > Googling for "compiler cannot create executables" provides lots of random > advice, but I don't see a file permissions problem and most of the rest > of the advice looks questionable. > > The config.log has this (possibly unrelated): > > gcc: error: unrecognized command line option '-V' > gcc: fatal error: no input files > compilation terminated. > > That looks like the same gcc version issue I had with building Spur on > my Ubuntu laptop. I had thought it might be easier to just buy a $35 > Raspberry Pi rather than fix the autotools configure, but maybe not. > > Are other people seeing these issues, or is it just me? > > Compiling and running an interpreter VM on the same Raspberry Pi works > fine, so I am assuming this is either an autotools issue or something > related to gcc version for the cog/spur build. > > I am attaching the config.log from the ./mvm session in case it helps. > > Raspberry Pi OS version information: > > pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ cat /proc/version > Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016 > > Thanks, > Dave > > From eliot.miranda at gmail.com Fri Jun 24 16:53:46 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 16:53:52 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <20160624133626.GB18277@shell.msen.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> <20160624133626.GB18277@shell.msen.com> Message-ID: Hi David, > On Jun 24, 2016, at 6:36 AM, David T. Lewis wrote: > > >> On Thu, Jun 23, 2016 at 11:52:48PM -0400, Phil (list) wrote: >> >>> On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote: >>> ?? >>> >>>> On 23-06-2016, at 7:35 PM, David T. Lewis >>>> wrote: >>>> >>>> >>>>> On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: >>>>> {snip} >>>>> Yes, I ran into it as well... the build is hard-coded to build >>>>> for the >>>>> ARMv6 of the original Pi. ??Remove the line with the compiler >>>>> flags??"- >>>>> march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the >>>>> issue >>>>> for me for ARMv7 builds. >>>> >>>> Phil, >>>> >>>> Brilliant! I removed the -march=armv6 and it compiles now.\ >>> >>> That is both weird and in some sense wrong; Eliot & I use the armv6 >>> flag so far as????I know and don???t have this issue. I *did* have this >>> problem a very long time ago though. The question is whether I can >>> find any evidence of what I did to get????past it??? >> >> IIRC, it has to do with the build of gcc that is installed for (most?) >> ARMv7 distros. ??Are you and Elliot using an armel or armhf based >> installs or just the stock rpi install (which is ARMv6 hf I think)? >> ??Most of the ARM world (with the notable exception of rpi) is running >> armhf these days which is where the problem seems to be (i.e. I was >> able to build using the shipped mvm as-is on armel, but not armhf) > > Also regarding the gcc version, it looks like the configure script is > getting rather old. I see this in my config log: > > g++: error: unrecognized command line option '-V' > > This apparently had no ill effect on the build for Pi, but it's important > because I think that the -V option has gone away in recent gcc versions, > and that is what prevented me from being able to build Cog/Spur on my > Intel Ubuntu laptop. I ran out of patience trying to rebuild the > autotools configuration, and that is what finally prompted me to buy > this Raspberry Pi :-) IIRC, the issue is that the default build.linux32ARM produces a VM that will run on Pi 1, which Tim needs for Scratch deployment, and this requires the "-march=armv6 -mfpu=vfp -mfloat-abi=hard" flags. And alas this produces a VM that won't run on, eg, android. So we really need two build.linux32ARM variants. See below. > > So ... I think that somebody with more patience than me is going to > need to update the autotools build one of these days. If you remember the board conversation about moving to github you'll recall I got agreement that I could rewrite the Linux build process to use gmake and makefiles and eliminate autotools. Esteban is working on generating the per-platform config file (cogConfig.h, osvmConfig.h?) that will contain the platform facility defines (such as #define HAS_POLL) that will sit in each build directory, probably in the common directory containing the makefiles (eg build.win32x86/common, build.macos32x86/common, etc) and hence only be generated once per platform. Then we can (if armv6 still makes sense, which for scratch it does) split build.linux32ARM into build.linux32ARMv6 and build.linux32ARMv7 and eventually add build.linux64ARMv8. We can do this now and have different mvm scripts in build.linux32ARMv6 and build.linux32ARMv7. Feel free to make this split, but be sure to get Travis to build each. > > Dave > From eliot.miranda at gmail.com Fri Jun 24 17:00:03 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 17:00:08 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <20160624133626.GB18277@shell.msen.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> <20160624133626.GB18277@shell.msen.com> Message-ID: <1AA72895-9444-4B38-A511-7011F9AB6A29@gmail.com> > On Jun 24, 2016, at 6:36 AM, David T. Lewis wrote: > > >> On Thu, Jun 23, 2016 at 11:52:48PM -0400, Phil (list) wrote: >> >>> On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote: >>> ?? >>> >>>> On 23-06-2016, at 7:35 PM, David T. Lewis >>>> wrote: >>>> >>>> >>>>> On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: >>>>> {snip} >>>>> Yes, I ran into it as well... the build is hard-coded to build >>>>> for the >>>>> ARMv6 of the original Pi. ??Remove the line with the compiler >>>>> flags??"- >>>>> march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the >>>>> issue >>>>> for me for ARMv7 builds. >>>> >>>> Phil, >>>> >>>> Brilliant! I removed the -march=armv6 and it compiles now.\ >>> >>> That is both weird and in some sense wrong; Eliot & I use the armv6 >>> flag so far as????I know and don???t have this issue. I *did* have this >>> problem a very long time ago though. The question is whether I can >>> find any evidence of what I did to get????past it??? >> >> IIRC, it has to do with the build of gcc that is installed for (most?) >> ARMv7 distros. ??Are you and Elliot using an armel or armhf based >> installs or just the stock rpi install (which is ARMv6 hf I think)? >> ??Most of the ARM world (with the notable exception of rpi) is running >> armhf these days which is where the problem seems to be (i.e. I was >> able to build using the shipped mvm as-is on armel, but not armhf) > > Also regarding the gcc version, it looks like the configure script is > getting rather old. I see this in my config log: > > g++: error: unrecognized command line option '-V' > > This apparently had no ill effect on the build for Pi, but it's important > because I think that the -V option has gone away in recent gcc versions, > and that is what prevented me from being able to build Cog/Spur on my > Intel Ubuntu laptop. I ran out of patience trying to rebuild the > autotools configuration, and that is what finally prompted me to buy > this Raspberry Pi :-) With the architecture I've set up one should not attempt to rebuild the autotools configuration in a normal build. You don't need to to add or remove plugins or to choose a specific VM. You only need to when adding new configuration options, or a radically new directory hierarchy, or, as I did this week, changed the generated config.h to include VM_TARGET_CPU et al to replace the bogus VM_HOST_CPU (compiling an x86 vm on an x64 host should not produce a vm that claims to be an x64). So just use mvm. If you need to edit it, do so, all the levers you need are in mvm plugins.int plugins. ext Part of the idea is to get away from the time consuming hell of running autoconf. Anyway, soon we'll have gum makefiles for Linux, to match the other platforms, and this insanity will be history. > > So ... I think that somebody with more patience than me is going to > need to update the autotools build one of these days. > > Dave > From eliot.miranda at gmail.com Fri Jun 24 17:06:07 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 17:06:13 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: <25CCD6F0-9113-4EF2-850D-3E818A79117C@gmail.com> Hi Holger, > On Jun 20, 2016, at 1:24 AM, Holger Freyther wrote: > > > >> On 20 Jun 2016, at 09:53, Norbert Hartl wrote: >> >> >> >> A commit is associated with a comment. So commits should be rather small and describing the change. Most of the time there are some changes/commits that only make sense when being together. This would be the view from the build server or from the process of having buildable artifacts all the time. So you can see it as freedom to have a commit that breaks the software which can be build after 5 more commits. So no problem for the world if you push 5 commits at once. > > This approach breaks tools like git bisect. If a user has something easy/quick to reproduce and a "good" version and "bad" one, he/she can identify the first broken commit almost automatically. If commits are small then it is quite easy for the maintainer to identify the issue and resolve it. > > Projects like Linux have the policy that each single commit needs to compile and for my GPRS/EDGE PCU[1] we have the same policy and I can point to a recent example of git bisect used by a user[2]. As a maintainer this reduces the work I have to do. > > In the context of spur there is a significant performance regression of our TCAP benchmark from one spur version to another and with git bisect I could do: > > git bisect start > git bisect good > git bisect bad > > and then commits from good to bad will be picked and all I need to do is: > > make > bench > > and then decide to mark this commit as: > > git bisect bad > git bisect good > > and eventually end with the first bad commit (or none if I track noise) > > > It is obviously up to the maintainers if they want to support git bisect but thanks to git it is not really a burden. One can experiment with temporary branches and then rebase to a final and working patchset. With later git versions can be easily automated as well. I think this is a very sensible policy and that we should support bisect. Do you have energy to work with Tim F to update CONTRIBUTING.md to include this policy? Are there ways of enforcing or advising the policy when using git tools or is it simply something we have to tell users? This latter approach is terribly fragile. > > git rebase -i --execute "./compile_and_test_all.sh" origin/master > close the editor..and git starts compiling all your intermediate commits and stops if they fail > > > > kind regards > holger > > > > > [1] A GSM component that converts a LLC frame to smaller pieces. Decides on the coding scheme (error correction bits vs. data), schedules resources across several handsets. > [2] http://lists.osmocom.org/pipermail/openbsc/2016-May/009139.html From tim at rowledge.org Fri Jun 24 17:32:01 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 24 17:31:42 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <1466740368.2453.34.camel@gmail.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> Message-ID: <46981F39-33AC-4138-BEBC-3DA76DC408B1@rowledge.org> > On 23-06-2016, at 8:52 PM, Phil (list) wrote: > > > IIRC, it has to do with the build of gcc that is installed for (most?) > ARMv7 distros. Are you and Elliot using an armel or armhf based > installs or just the stock rpi install (which is ARMv6 hf I think)? I?m using the stock latest Raspbian (as I have throughout the last ~4 years) and I?m reasonably sure Eliot is too. The gcc version currently is 4.9.2. > Most of the ARM world (with the notable exception of rpi) is running > armhf these days which is where the problem seems to be (i.e. I was > able to build using the shipped mvm as-is on armel, but not armhf) To the best of my knowledge Pi uses hardfloat and has for a long time. Let?s see `dpkg ?print-architecture` -> armhf So yes, hard float. I think this has been true since ~2013. Several people have gone to the trouble of compiling Raspbian kernels etc with armv7 settings and found it makes no measurable difference, which means that it would be silly of the Pi people to split things - which of course they would have to do to support the several million older Pis out there. Honestly, since the Pi is probably the main ARM SBC by a very, very, large margin it would be smartest for everyone else to maintain sensible compatibility. And none of this alters the fact the Eliot & I can build vms without making any arch setting change. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Ignorant, and proud of it. From tim at rowledge.org Fri Jun 24 17:40:41 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 24 17:40:23 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: > On 23-06-2016, at 2:37 PM, Bob Westergaard wrote: > > > On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge wrote: >> What did I miss? > > I believe this can happen if you don't *first* run > scripts/updateSCCSVersions after you clone the repository: > > https://github.com/OpenSmalltalk/vm#important-notice-for-developers This appears to have problems on my Pi - I get two complaints about no such file or directory . ?cp: cannot create regular file ?./scripts/../.git/hooks/post-commit?: No such file or directory? and a simialr one for post-merge I have the .git directory but it contains no ?hooks? directory. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim <-------- The information went data way --------> From frank.shearar at gmail.com Fri Jun 24 17:53:38 2016 From: frank.shearar at gmail.com (Frank Shearar) Date: Fri Jun 24 17:53:40 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: <25CCD6F0-9113-4EF2-850D-3E818A79117C@gmail.com> References: <25CCD6F0-9113-4EF2-850D-3E818A79117C@gmail.com> Message-ID: On 24 June 2016 at 10:06, Eliot Miranda wrote: > > Hi Holger, > > > > On Jun 20, 2016, at 1:24 AM, Holger Freyther wrote: > > > > > > > >> On 20 Jun 2016, at 09:53, Norbert Hartl wrote: > >> > >> > >> > >> A commit is associated with a comment. So commits should be rather > small and describing the change. Most of the time there are some > changes/commits that only make sense when being together. This would be the > view from the build server or from the process of having buildable > artifacts all the time. So you can see it as freedom to have a commit that > breaks the software which can be build after 5 more commits. So no problem > for the world if you push 5 commits at once. > > > > This approach breaks tools like git bisect. If a user has something > easy/quick to reproduce and a "good" version and "bad" one, he/she can > identify the first broken commit almost automatically. If commits are small > then it is quite easy for the maintainer to identify the issue and resolve > it. > That's true only for commits _on master_, right? (More accurately, IIUC git bisect will binary search over a chain of commits. If a merged-into-master feature branch has a commit that doesn't compile, git bisect will not even see that commit; it will walk over the merge commit, marking it good/bad. frank > > Projects like Linux have the policy that each single commit needs to > compile and for my GPRS/EDGE PCU[1] we have the same policy and I can point > to a recent example of git bisect used by a user[2]. As a maintainer this > reduces the work I have to do. > > > > In the context of spur there is a significant performance regression of > our TCAP benchmark from one spur version to another and with git bisect I > could do: > > > > git bisect start > > git bisect good > > git bisect bad > > > > and then commits from good to bad will be picked and all I need to do is: > > > > make > > bench > > > > and then decide to mark this commit as: > > > > git bisect bad > > git bisect good > > > > and eventually end with the first bad commit (or none if I track noise) > > > > > > It is obviously up to the maintainers if they want to support git bisect > but thanks to git it is not really a burden. One can experiment with > temporary branches and then rebase to a final and working patchset. With > later git versions can be easily automated as well. > > I think this is a very sensible policy and that we should support bisect. > Do you have energy to work with Tim F to update CONTRIBUTING.md to include > this policy? Are there ways of enforcing or advising the policy when using > git tools or is it simply something we have to tell users? This latter > approach is terribly fragile. > > > > > git rebase -i --execute "./compile_and_test_all.sh" origin/master > > close the editor..and git starts compiling all your intermediate commits > and stops if they fail > > > > > > > > kind regards > > holger > > > > > > > > > > [1] A GSM component that converts a LLC frame to smaller pieces. Decides > on the coding scheme (error correction bits vs. data), schedules resources > across several handsets. > > [2] http://lists.osmocom.org/pipermail/openbsc/2016-May/009139.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/c1747d61/attachment-0001.htm From casimiro.barreto at gmail.com Fri Jun 24 17:56:28 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Fri Jun 24 17:56:34 2016 Subject: [Vm-dev] Cog spur VMs crashing in new Fedora 24 In-Reply-To: References: <198b266e-977b-7160-1765-fdab8f706e41@gmail.com> <950507D4-383B-4125-AF92-82A0557DB5F9@gmail.com> <087a5545-68d5-78c0-a2fc-8a066f83e14b@gmail.com> <6F449BFE-B293-4C3E-BD14-50FBAC5F18D4@gmail.com> <4ceb66dd-1a4e-1003-4b56-c6f1e3c9f26f@gmail.com> Message-ID: <64d308cd-a772-ed03-cb8e-8c5436c23679@gmail.com> Just upgraded another box (an ASUS with Intel GPU). Here things worked all right from install. Will reinstrall the Samsung box and see what happens. Em 23-06-2016 20:05, Eliot Miranda escreveu: > > > > So if you do ldd on the vm-display-X11 module are all the libraries > found? Here's an example output on ARM: > > eliot@pi2 ~/all/Squeak/Squeak5.0 $ ldd > ~/all/oscogvm/products/cogspurlinuxhtARM/lib/squeak/5.0-201606212031/vm-display-X11 > /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x76f80000) > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 > (0x76f5a000) > libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x76f4c000) > libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 > (0x76f2f000) > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76f24000) > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 > (0x76f05000) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e93000) > libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x76e77000) > libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x76e6a000) > libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 > (0x76da6000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 > (0x76c92000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76b61000) > /lib/ld-linux-armhf.so.3 (0x76fae000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 > (0x76b39000) > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76b2a000) > libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 > (0x76b0b000) > libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 > (0x76b01000) > libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 > (0x76af4000) > > On Thu, Jun 23, 2016 at 3:47 PM, Casimiro - GMAIL > > wrote: > > > Em 23-06-2016 18:39, Esteban Lorenzano escreveu: >> >> >> >> can you try this one? >> >> cog_linux32x86_squeak.stack.spur_201606230315.tar.gz >> >> >> pharo will not work completely but at least we will know if is >> pharovm flavour or all vm?s >> >> Esteban > The trace for this VM is as follows and it seems to be complaining > about the vm-display-X11 module: > > [CdAB63@localhost 5.0-201606230315]$ gdb ./squeak > GNU gdb (GDB) Fedora 7.11.1-75.fc24 > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > > . > Find the GDB manual and other documentation resources online at: > > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./squeak...done. > (gdb) run > Starting program: > /home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/squeak > > Missing separate debuginfos, use: dnf debuginfo-install > glibc-2.23.1-8.fc24.i686 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) backtrace full > #0 0x00000000 in ?? () > No symbol table info available. > #1 0xf7f92d7e in __pthread_once_slow () from /lib/libpthread.so.0 > No symbol table info available. > #2 0xf7aa7c05 in ?? () from /lib/libGL.so.1 > No symbol table info available. > #3 0xf7a702ab in ?? () from /lib/libGL.so.1 > No symbol table info available. > #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 > No symbol table info available. > #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 > No symbol table info available. > #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 > No symbol table info available. > #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > No symbol table info available. > #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 > No symbol table info available. > #9 0xf7fa2c05 in dlopen_doit () from /lib/libdl.so.2 > No symbol table info available. > #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 > No symbol table info available. > #11 0xf7fa335d in _dlerror_run () from /lib/libdl.so.2 > No symbol table info available. > #12 0xf7fa2cae in dlopen@@GLIBC_2.1 () > from /lib/libdl.so.2 > No symbol table info available. > #13 0x080a08a7 in tryLoading (dirName=0xffffac2c > "/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/", > moduleName=0xffffbc8c "vm-display-X11") > at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixExternalPrims.c:245 > libName = > "/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/vm-display-X11\000\377y\214\376\367\000\000\000\000W\253\377\377\003\000\000\000\000\000\000\000\070\000\000\000\000\000\000\000[\000\000\000\000\000\000\000n\000\000\000\000\000\000\000w\000\000\000\000\000\000\000|\000\000\000\000\360\371\367\377\377\377\177\201\000\000\000~-\371\367\260$\372\367\060`\372\367\351Q\335\367\000\300\362\367`\307\362\367\220+\372\367`\373\001\000\367{\335\367\353\201\376\367\000"... > buf = {st_dev = 64770, __pad1 = 53052, __st_ino = > 14420702, st_mode = 33261, st_nlink = 1, st_uid = 1000, st_gid = > 1000, st_rdev = 0, __pad2 = 53044, st_size = 264943, > st_blksize = 4096, st_blocks = 520, st_atim = {tv_sec = > 1466720855, tv_nsec = 541848724}, st_mtim = {tv_sec = 1466652243, > tv_nsec = 0}, st_ctim = {tv_sec = 1466720774, > tv_nsec = 231755653}, st_ino = 14420702} > prefixes = {0x8123af4 "", 0x8127d62 "lib", 0x0} > suffixes = {0x8123af4 "", 0x8127d5b ".so", 0x8127d5f > ".dylib", 0x0} > handle = > prefix = > suffix = > #14 0x080a0ac1 in ioLoadModule (pluginName=0xffffbc8c > "vm-display-X11") at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixExternalPrims.c:328 > path = > "/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak/5.0-201606230315/", > '\000' > c = > in = > out = > handle = 0x0 > #15 0x0805e75f in queryLoadModule (type=0x8123911 "display", > name=0x81238d9 "X11", query=1) at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1079 > handle = > modName = > "vm-display-X11\000\377q\335\005\b\033\275\377\377\200\254\027\b\001\020", > '\000' , > "\002\375\000\000\000\000\000\000\000\000\000\000\335\n\334\000\355\201\000\000\001\000\000\000\350\003\000\000\350\003", > '\000' , > "*'=\000\000\000\000\000\000\020\000\000\230\036\000\000\000\000\000\000WblW\033\"\341\037KVkW\000\000\000\000\006blWS\002\204\r\335\n\334\000\000\000\000\000\000\000\000/home/CdAB63/Downloads/products/stkspurlinuxht/lib/squeak"... > itfName = > "display_X11\000\353:\335\367\000\300\362\367k\336\377\377\222;\022\bDI\000" > module = > itf = 0x0 > #16 0x0805e83f in queryModule (type=0x8123911 "display", > name=0x81238d9 "X11") at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1112 > ---Type to continue, or q to quit--- > No locals. > #17 0x0805e88b in loadImplicit (addr=0x8159928 , > evar=, type=, name=0x81238d9 "X11") > at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1205 > No locals. > #18 0x0805d4bb in loadModules () at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1217 > No locals. > #19 main (argc=1, argv=0xffffcf34, envp=0xffffcf3c) at > /home/travis/build/OpenSmalltalk/vm/platforms/unix/vm/sqUnixMain.c:1935 > No locals. > (gdb) > > -- > The information contained in this message is confidential and > intended to the recipients specified in the headers. If you > received this message by error, notify the sender immediately. The > unauthorized use, disclosure, copy or alteration of this message > are strictly forbidden and subjected to civil and criminal sanctions. > > == > > This email may be signed using PGP key *ID: 0x4134A417* > > > > > -- > _,,,^..^,,,_ > best, Eliot -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/05c1b943/attachment.htm From eliot.miranda at gmail.com Fri Jun 24 18:00:32 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 18:00:36 2016 Subject: [Vm-dev] Re: build products seem to go to the wrong branch In-Reply-To: References: Message-ID: <77F45F7E-4149-4964-9529-06C17E077FCE@gmail.com> Hi Ben, > On Jun 23, 2016, at 9:17 PM, Ben Coman wrote: > > > >> On Fri, Jun 24, 2016 at 11:26 AM, Ben Coman wrote: >> I just did my first vm build from git... >> >> $ git checkout -b firstbuild Cog >> $ cd image >> $ ./buildspurtrunkvmmakerimage.sh >> $ cd build.linux32x86/squeak.cog.spur/build >> $ ./mvm >> Which completes okay, but reports... >> Libraries have been installed in: >> /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606221719-btc/condense-gitignore >> >> but condense-gitignore is not the current branch, but a previous branch I worked on where I didn't even do a build (I'm reasonably sure, but maybe I forget). >> >> $ git branch >> [snip] >> * firstbuild >> btc/condense-gitignore >> >> I poked around and found the message comes from ./platforms/unix/config/ltmain.sh >> but I don't see any git commands there to determine the branch, so it seems the branch must be passed to ltmain from somewhere else?? >> >> cheers -ben > > I was sure I had run scripts/updateSCCSVersions before, but running it again fixed the problem > $ cd ~/Repos/OpenSmalltalk/vm > $ rm -r * > $ git checkout -b firstbuild Cog > $ git reset --hard HEAD # not sure if this is the best command to use here > $ scripts/updateSCCSVersions > $ cd build.linux32x86/squeak.cog.spur/build > $ ./mvm > clean? y > Libraries have been installed in: > /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606230315-firstbuild > > However... > $ git checkout -b secondbuild Cog > $ /mvm > clean? y > Libraries have been installed in: > /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606230315-firstbuild > > $ ../../../scripts/updateSCCSVersions > $ ./mvm > clean? y > Libraries have been installed in: > /home/ben/Repos/OpenSmalltalk/vm/products/cogspurlinuxht/lib/squeak/5.0-201606182358-secondbuild > > So it seems updateSCCSVersions needs to be run *every* time I change branch before running ./mvm. > Should it be added to mvm? mvm is simply a convenience build script and there are lots of them. updateSCCSVersions is to do with updating the state of the checkout if the repository, so it and its effects belong in the realm of hit. Can we not add git hooks to run it after every update and merge? That seems to me both the right time to run it and to be the right universe of discourse. Tim, Fabio is this possible? > > cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/26a6b63f/attachment-0001.htm From eliot.miranda at gmail.com Fri Jun 24 18:09:39 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 18:09:44 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <20160624014906.GA76992@shell.msen.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> Message-ID: Here are useful extracts of messages from Ryan Macnak on the topic. They imply to me the need for separate v6/Pi and v7/Android builds. On Feb 11, 2016, at 7:43 PM, Ryan Macnak wrote: 4) The build is broken on Linux ARMv7 (i.e., everyone but Raspbian). The build fails in the configure step because it includes "-march=armv6 -mfpu=vfp -mfloat-abi=hard" in the compiler flags. This is not a valid configuration for a gcc built to target ARMv7. Removing this from mvm fixes the build. I don't have commit access to the Subversion repository, but someone who does should revert r3410. On Feb 13, 2016, at 11:21 AM, Ryan Macnak wrote: (Eliot: What is a valid base architecture for Linux ARMv7?) Rasbian: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard a.c OK gcc -march=armv7 -mfpu=vfp -mfloat-abi=hard a.c ERROR gcc a.c OK Debian armhf: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard a.c ERROR gcc -march=armv7 -mfpu=vfp -mfloat-abi=hard a.c OK gcc a.c OK An annoying property of ARM toolchains, which probably comes from ARM being used for embedded systems instead of desktops, is they come with a lot the options already backed in. They aren't like the x86 toolchains, where one can compile to support the latest systems and systems before SSE just by setting some flags. With ARM one has to rely on using an appropriate toolchain. ARM doesn't have great backwards compatibility either. I've tried running an ARMv6 compiled Cog on an ARMv8 board, and it crashes because the VM includes a memory fence instruction that is deprecated and has a replacement in ARMv7 and optionally (and in practice) disabled in ARMv8. So it doesn't look like one can provide a single binary that supports ARMv6-8. Again the embedded systems mentality that one builds for a specific device. From tim at rowledge.org Fri Jun 24 18:35:29 2016 From: tim at rowledge.org (tim Rowledge) Date: Fri Jun 24 18:35:12 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> Message-ID: <3F4B066C-2F45-4FDD-BAB2-BE7F186125E1@rowledge.org> > On 24-06-2016, at 11:09 AM, Eliot Miranda wrote: > > > Here are useful extracts of messages from Ryan Macnak on the topic. They imply to me the need for separate v6/Pi and v7/Android builds. > > On Feb 11, 2016, at 7:43 PM, Ryan Macnak wrote: > > > ARM doesn't have great backwards compatibility either. I've tried running an ARMv6 compiled Cog on an ARMv8 board, and it crashes because the VM includes a memory fence instruction that is deprecated and has a replacement in ARMv7 and optionally (and in practice) disabled in ARMv8. So it doesn't look like one can provide a single binary that supports ARMv6-8. Again the embedded systems mentality that one builds for a specific device. > And yet the cog vms for Raspbian work on Pi3 (ARMv8) Pi2 ARMv7 and Pi B (ARMv6) tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Bayard(n): a person armed with the self-confidence of ignorance From eliot.miranda at gmail.com Fri Jun 24 20:15:59 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 20:16:02 2016 Subject: [Vm-dev] SSLPlugin Message-ID: Hi All, now that we're on github would those who build the SSLPlugin be willing to fold in their build to the standard VM builds so that SSLPlugin is built alongside the others? _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/ae6132e6/attachment.htm From Das.Linux at gmx.de Fri Jun 24 20:48:16 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri Jun 24 20:48:16 2016 Subject: [Vm-dev] SSLPlugin In-Reply-To: References: Message-ID: On 24.06.2016, at 22:15, Eliot Miranda wrote: > Hi All, > > now that we're on github would those who build the SSLPlugin be willing to fold in their build to the standard VM builds so that SSLPlugin is built alongside the others? On principle, yes. It's hairy, still (see other mail) Best -Tobias From pbpublist at gmail.com Fri Jun 24 21:16:03 2016 From: pbpublist at gmail.com (Phil (list)) Date: Fri Jun 24 21:16:08 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <46981F39-33AC-4138-BEBC-3DA76DC408B1@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <1466734763.2453.14.camel@gmail.com> <20160624023547.GA88002@shell.msen.com> <4E18153F-72B0-4822-BEEC-63890552372C@rowledge.org> <1466740368.2453.34.camel@gmail.com> <46981F39-33AC-4138-BEBC-3DA76DC408B1@rowledge.org> Message-ID: <1466802963.2453.98.camel@gmail.com> Tim, On Fri, 2016-06-24 at 10:32 -0700, tim Rowledge wrote: > ? > > > On 23-06-2016, at 8:52 PM, Phil (list) wrote: > > > > > > IIRC, it has to do with the build of gcc that is installed for > > (most?) > > ARMv7 distros.??Are you and Elliot using an armel or armhf based > > installs or just the stock rpi install (which is ARMv6 hf I think)? > > I?m using the stock latest Raspbian (as I have throughout the last ~4 > years) and I?m reasonably sure Eliot is too. The gcc version > currently is 4.9.2. Got it. ?Apologies for not being clearer in my previous comment... > > > ?Most of the ARM world (with the notable exception of rpi) is > > running > > armhf these days which is where the problem seems to be (i.e. I was > > able to build using the shipped mvm as-is on armel, but not armhf) > > To the best of my knowledge Pi uses hardfloat and has for a long > time. Let?s see > `dpkg ?print-architecture` -> armhf > So yes, hard float. I think this has been true since ~2013. > Right, that's the main thing that makes Raspbian different from other Linux distros on ARM: Raspbian is an armhf build for ARMv6. ?This is *not* what the rest of the Linux world is doing. It is at least in the ARMv7 armhf (i.e. non-Raspbian) flavor that gcc can't build the VM using the default flags (i.e. the build of gcc doesn't appear to support it). ?This was the issue for me as I don't build the VM on Raspbian but rather in an ARMv7 VM running (non- Raspbian) armhf for use on my Pi 2 and BeagleBoard-xM. ?Now, why is Dave seeing this issue presumably running Raspbian on his new Pi? ?That I don't know... > Several people have gone to the trouble of compiling Raspbian kernels > etc with armv7 settings and found it makes no measurable difference, > which means that it would be silly of the Pi people to split things - > which of course they would have to do to support the several million > older Pis out there. Honestly, since the Pi is probably the main ARM > SBC by a very, very, large margin it would be smartest for everyone > else to maintain sensible compatibility. This is like saying that since Windows is the main x86 platform by a very, very large margin everyone should fall in line and support it. ?This doesn't make things run any better for you if you're not on Windows. ?It's also a narrow view of the ARM platform: if the priority is unit volume then Android/iOS on ARMv7 should be the priority since Pi shipments are rounding error in the ARM ocean. ?Some of us have been running Linux on ARM since before the Pi existed and/or on different form factors. ?The good news is that this doesn't need to be an either/or decision: Eliot's post about having multiple build configs for ARM would solve the issue nicely for everyone (i.e. don't assume that everyone is running Raspbian on a Pi, but support it for the majority that do) > > And none of this alters the fact the Eliot & I can build vms without > making any arch setting change.? > That likely solves the problem for the majority of users, but not everyone. ?The precompiled ARM binaries have been problematic for me for a couple of years (specifically because they have had an incomplete and varying set of plugins) ?So it's great that they exist, but they aren't the best fit for everyone. ?And it's also great that the current default build config works for both of you, but again it doesn't work for everyone. > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Useful random insult:- Ignorant, and proud of it. > > Thanks, Phil From eliot.miranda at gmail.com Fri Jun 24 21:24:06 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Jun 24 21:24:09 2016 Subject: [Vm-dev] SSLPlugin In-Reply-To: References: Message-ID: Hi Tobias, On Fri, Jun 24, 2016 at 1:48 PM, Tobias Pape wrote: > > > On 24.06.2016, at 22:15, Eliot Miranda wrote: > > > Hi All, > > > > now that we're on github would those who build the SSLPlugin be > willing to fold in their build to the standard VM builds so that SSLPlugin > is built alongside the others? > > On principle, yes. > It's hairy, still (see other mail) > got a link? Why is it hairy? Isn't it just a matter of updating HowToBuild with instructions, and then updating makefiles etc to build the same way that SSLPlugin is built? If it's in the other mail, just post a link to the mail. It passed me by and I don't see it. thx!! P.S. Loving the amount of energy and activity in our communities right now. Lovely!! _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/e4d80840/attachment.htm From pbpublist at gmail.com Fri Jun 24 21:27:14 2016 From: pbpublist at gmail.com (Phil (list)) Date: Fri Jun 24 21:27:18 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <3F4B066C-2F45-4FDD-BAB2-BE7F186125E1@rowledge.org> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <3F4B066C-2F45-4FDD-BAB2-BE7F186125E1@rowledge.org> Message-ID: <1466803634.2453.103.camel@gmail.com> On Fri, 2016-06-24 at 11:35 -0700, tim Rowledge wrote: > ? > > > On 24-06-2016, at 11:09 AM, Eliot Miranda > > wrote: > > > > > > Here are useful extracts of messages from Ryan Macnak on the > > topic.??They imply to me the need for separate v6/Pi and v7/Android > > builds. > > > > On Feb 11, 2016, at 7:43 PM, Ryan Macnak wrote: > > > > > > > ARM doesn't have great backwards compatibility either. I've tried > > running an ARMv6 compiled Cog on an ARMv8 board, and it crashes > > because the VM includes a memory fence instruction that is > > deprecated and has a replacement in ARMv7 and optionally (and in > > practice) disabled in ARMv8. So it doesn't look like one can > > provide a single binary that supports ARMv6-8. Again the embedded > > systems mentality that one builds for a specific device. > > > > And yet the cog vms for Raspbian work on Pi3 (ARMv8) Pi2 ARMv7 and Pi > B (ARMv6) > Yes, because the Pi Foundation is going to great pains (to the detriment of features and performance on newer Pi boards) to retain backward compatibility. ?The rest of the ARM world is the wild, wild west. ?Different strokes and all that... > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Bayard(n): a person armed with the self-confidence of ignorance > From Das.Linux at gmx.de Fri Jun 24 21:46:38 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri Jun 24 21:46:38 2016 Subject: [Vm-dev] SSLPlugin In-Reply-To: References: Message-ID: <0495D26F-4DCD-4F36-B312-6146E2A72F8A@gmx.de> Hi Eliot, On 24.06.2016, at 23:24, Eliot Miranda wrote: > Hi Tobias, > > On Fri, Jun 24, 2016 at 1:48 PM, Tobias Pape wrote: > > > On 24.06.2016, at 22:15, Eliot Miranda wrote: > > > Hi All, > > > > now that we're on github would those who build the SSLPlugin be willing to fold in their build to the standard VM builds so that SSLPlugin is built alongside the others? > > On principle, yes. > It's hairy, still (see other mail) > > got a link? http://forum.world.st/Fetch-zip-file-from-web-unzip-save-constituent-parts-tp4901282p4901516.html > Why is it hairy? I statically link libressl to evade the different so-names of centos vs debian. > Isn't it just a matter of updating HowToBuild with instructions, and then updating makefiles etc to build the same way that SSLPlugin is built? If it's in the other mail, just post a link to the mail. It passed me by and I don't see it. The problem here is pulling in the Dependency for Linux, LibreSSL. [tl;dr: I'm still trying to re-write some parts of SqueakSSL] What's more, I am dissatisfied with "vanilla" openssl as the api to tackle. This is the code Levente wrote to extract the subjectAlternateName(s) (SAN) from the certificate sent by the server on connect: https://github.com/squeak-smalltalk/squeakssl/pull/3/files#diff-9e4c3c0adfa49a82c47f778e7555b185R151 , in order to verify it. This code is correct and Levente as always did a good job here. But I liked it more he did not have to write it in the first place. You know what the way of SChannel(win) and SecureTransport(macOS) is? Pass the server name on connect to the Lib. It then handles SAN and SNI. That's how it has to be, because we do not know enough about crypto to get it right. So My plan for the Unix plugin is to go with the libtls api of LibreSSL, which wraps the OpenSSL-API behind quite foolproof. You do SAN and SNI by passing the server-name on connect. Sounds familiar? Right :D. Only problem: Squeak has Socket and SqueakSSL nicely-decoupled, so there's no way to just pass the socket or some fd from one to the other, and libtls is not yet fit for that. Hence I want to contribute to LibreSSL/libtls a way to do a conntect with r/w-callbacks, which should fit our architecture [/end] > Other than that, stuff is in https://github.com/squeak-smalltalk/squeakssl and should actually match the tree in opensmalltalk-vm. Best and thanks for listening -Tobias [Writing C again X-O ] > thx!! > > P.S. Loving the amount of energy and activity in our communities right now. Lovely!! > _,,,^..^,,,_ > best, Eliot From Das.Linux at gmx.de Fri Jun 24 22:23:02 2016 From: Das.Linux at gmx.de (Das.Linux@gmx.de) Date: Fri Jun 24 22:23:03 2016 Subject: [Vm-dev] SSLPlugin In-Reply-To: <0495D26F-4DCD-4F36-B312-6146E2A72F8A@gmx.de> References: <0495D26F-4DCD-4F36-B312-6146E2A72F8A@gmx.de> Message-ID: <3FBA8C6B-34C7-4345-B839-31364EDA4ACD@gmx.de> Hi On 24.06.2016, at 23:46, Tobias Pape wrote: > > Hi Eliot, > [?snip?] > Other than that, stuff is in https://github.com/squeak-smalltalk/squeakssl > and should actually match the tree in opensmalltalk-vm. _except_ that I then used the interpreter tree with Ian's cmake infrastructure for unix, hence the config.cmake, which makes sure openssl is somehow there. The one I used for building the static one is admittedly slightly different, but I lost interest when I tried to integrate into the autoconf-based process, hence the libressl setup is not in that file. Best -Tobias > > > Best and thanks for listening > -Tobias [Writing C again X-O ] > >> thx!! >> >> P.S. Loving the amount of energy and activity in our communities right now. Lovely!! >> _,,,^..^,,,_ >> best, Eliot From tim at rowledge.org Sat Jun 25 01:01:39 2016 From: tim at rowledge.org (tim Rowledge) Date: Sat Jun 25 01:01:22 2016 Subject: [Vm-dev] Compiling squeak.cog.spur on Pi In-Reply-To: <1466803634.2453.103.camel@gmail.com> References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> <20160624014906.GA76992@shell.msen.com> <3F4B066C-2F45-4FDD-BAB2-BE7F186125E1@rowledge.org> <1466803634.2453.103.camel@gmail.com> Message-ID: > On 24-06-2016, at 2:27 PM, Phil (list) wrote: > {snip} > Yes, because the Pi Foundation is going to great pains (to the > detriment of features and performance on newer Pi boards) to retain > backward compatibility. The technical group at Pi Trading (where all the heavy work is done) is larger and smarter than I suspect most of the world understands. Some of them have been working with ARM for as long as I have. Um, which is just under 30 years now. Including using various unixes on ARM since ?88 or thereabouts. > The rest of the ARM world is the wild, wild > west. Different strokes and all that? Yes, and that?s how we set it up. And none of this is very relevant to working out why Dave had problems compiling the standard setup when neither Eliot nor I do, on supposedly the same hardware and (hopefully) the same OS/compiler. It?s also a bit difficult to see how an arch flag can result in complaints about 'C compiler cannot create executables?. My config.log is a match for Dave?s reported output for only the first few lines, so something diverges very quickly. The build system and host system agree as armv7l-linux-gnu but I seem to have a check for the target system added. After that it goes differently. The check for the compiler version works ok, and then wher Dave?s fail I get - configure:2266: checking for C compiler default output file name configure:2269: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -g -O2 -fwrapv -DNDEBUG -DDEBUGVM=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wl,-z,now conftest.c -lpthread -luuid -lasound >&5 configure:2272: $? = 0 configure:2318: result: a.out So Dave, which version of Raspbian did you install? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Illiud Latine dici non potest = You can't say that in Latin. From damien.pollet at gmail.com Sat Jun 25 14:55:25 2016 From: damien.pollet at gmail.com (Damien Pollet) Date: Sat Jun 25 14:55:56 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: On 24 June 2016 at 19:40, tim Rowledge wrote: > I have the .git directory but it contains no ?hooks? directory. > You can create it when needed; I believe it gets created or not depending on your git version or based on some template, and when it does it only contains example files that do nothing. In this case, whatever script that tries to cp stuff into it could just do mkdir -p beforehand to ensure the directory is there. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160625/a2312a80/attachment.htm From timfelgentreff at gmail.com Sat Jun 25 20:51:11 2016 From: timfelgentreff at gmail.com (Tim Felgentreff) Date: Sat Jun 25 20:51:14 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: Hi Ben, One of your arguments is about history cleaning. Mostly my discouraging of rebase -i comes from experience with people who made a mistake (e.g. as simple as deleting a line and then getting "lucky" and having git not complain about conflicts during the rebase) to lose a commit entirely. And sometimes they continued working for a while, eventually a git gc was triggered, and then that commit was cleaned up and was lost for good by the time they noticed their work was gone. This happened to people around me more than just once, and then I wasn't able to help because git gc had run. Eventually I gave up and encouraged people who do not want to spend the time to really put in the work and understand how git works and what the internal structures are to not use rebase. Your other argument is about bisecting. Another experience I had was with people rebasing to "clean up" history by grouping related changes together, but then not checking that each commit still compiles. So the bisect scripts we used in these projects still had to include the logic to skip non-compiling commits. As would any script used on a repository where no one used rebase to remove such 'bad' commits. Secondly, if people tried a bunch of different approaches and finally refactored their code and then squashed it all together, any bisects will only find one large commit as the culprit without explanatory history around it, making debugging harder. All that being said, if you all think it's safe and we all agree that no one has the right to complain about git if they loose their commits, I won't strongly oppose rebasing. And finally, regarding the linear history up to now: that's an artifact of how SVN works (it doesn't actually track merges) and thus is reflected in the imported history. cheers, Tim Am 24.06.2016 16:11 schrieb "Ben Coman" : > > > On Mon, Jun 20, 2016 at 5:55 PM, Tim Felgentreff > wrote: > > > > > > I've pushed a CONTRIBUTING.md to the repository that we can iterate > > over and discuss. > > > > If you go to https://github.com/OpenSmalltalk/vm/commit/5052e307fda0369f04550966fcfdf0a372aeaf39 > > you can leave comments inline or at the end. > > > > Thanks Tim, thats a really good starting point. Usually github would > be the place to comment in-line, but this influences community > workflow a a broader audience is useful. > > The thing I want to understand most is the strong discouragement of > rebasing rather than using it to maintain a tidy history. > > First there is... > > This also means that you should avoid rebasing or squashing > > your work. Just keep the history. > > I happened to look at Laura's PR that adds some good info to > CONTRIBUTING, so I use that as an example... > https://github.com/OpenSmalltalk/vm/pull/14 > Do you really want all four commits to appear in the master history? > I hunted up a dozen articles around this point, and even though a > little long winded, the best was this one... > > http://blog.izs.me/post/37650663670/git-rebase > > I particularly liked how the two camps of rebase or not were > characterised into platform or service, as well as the explanation of > bisect. > > Then there is... > > Every so many commits it is a good idea to push your work. > > Please refrain from rebasing, unless your history looks like this: > > So the need for history cleanup is alluded to, but no guidance is > given on *how* to do it safely. > The critical point to make is to distinguish between cleaning private > branches and leaving public branches alone. This is a good article > providing some examples... > > https://sandofsky.com/blog/git-workflow.html > > Thirdly there is... > > However, if you're unsure what rebasing is, just forget about it > > and push the history as-is. > > Again this seems to instil fear of a very useful tool for cleaning up > work in progress commits before submitting a pull request. But first > the community needs to discuss the degree to which a clean linear > history is beneficial or desired. Then we might define some recipes > to achieve that. > > Finally it says... > > You will be thankful later when you need to use `git bisect` to find where a bug comes from. > > But IIUC, bisect works better with a clean and linear history. Also > from the the repository network graph... > > https://github.com/OpenSmalltalk/vm/network > > before the 25 May the SVN history is *very* linear (or is this just an > artefact of the migration?) And after the 19 June (considering only > within the OpenSmalltalk swim lane, i.e. ignoring the personal repo > forks) the history is less linear. Now branching is one of git's > greatest strengths to encourage participation, but that doesn't mean > every branch needs a permanent record in the trunk history. > > So considering one particular workflow case, an afternoons work on > documentation or a quick bug fix, which yet may have several commits > but is only pushed once upon completion -- I believe a reasonable > workflow here would be for `rebase -i` to squash down to a single > commit prior to issuing the pull request. > > Any subsequent commits to the PR from feedback would remain separate > until it is ready to integrate, when the integrator could squash them > as described here... > > "Merge pull request? [Big Green Button] Considered Harmful > https://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful > > However it sounds like you've some personal war stories that might be > useful for us to hear. To me rebase seems straightforward for certain > defined situations, but maybe there is more about the risks I need to > learn... > > Seriously, skipping bad commits a bisect is easier than fixing > > someones git tree once they have lost commits to the depths of reflog. > > Especially if their recovery attempts have already triggered a Git GC. > > cheers -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160625/003bc30c/attachment-0001.htm From casimiro.barreto at gmail.com Sat Jun 25 21:12:43 2016 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Sat Jun 25 21:12:56 2016 Subject: [Vm-dev] Pharo 5.0 Fedora 24 crash solved Message-ID: <64e425bf-7b41-975d-de2f-1d47043ab230@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160625/61fa8988/signature.pgp From btc at openinworld.com Sun Jun 26 13:44:09 2016 From: btc at openinworld.com (Ben Coman) Date: Sun Jun 26 13:44:32 2016 Subject: [Vm-dev] Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD] In-Reply-To: <20160626123725.GD1194@pf-bsd.local> References: <20160617112645.GI2592@pf-bsd.local> <34C48949-B0F5-4FC6-9C91-863DB58F7D7C@gmail.com> <20160617164937.GJ2592@pf-bsd.local> <20160624040520.GC39529@pf-bsd.local> <20160626123725.GD1194@pf-bsd.local> Message-ID: On Sun, Jun 26, 2016 at 8:37 PM, Petr Fischer wrote: > Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors occurs... So I am still building with "PharoVMSpur32Builder buildUnix32" under Linux (CentOS6) and then move compiled vm to my FreeBSD box with Linux compatibility layer. > > I compiled DEBUG vm version according to your advice and this is gdb output: > > Program received signal SIGSEGV, Segmentation fault. > 0x080aefc1 in scavengeReferentsOf (referrer=684415032) at /home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014 > 39014 if (((longAt(referent)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))) == 0) { The C files are generated from VMMaker and the line numbers change a lot. If you look upwards in the C file you should see a generated comment that links to the Smalltalk source it was generated from. > > I need to learn a little, how to play this "core C" game in gdb... > What next? I recently learnt a bit of using gdb on the image. I'm planning to write up something but its a few weeks off. The old post How to debug the VM? [1] by Mariano needs a bit of adaption, but got me off to a good start. If you look in VMMaker package where #printAllStacks is defined you'll see some others you can call, that just print the current Smalltalk call stack. [1] https://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/ > > A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but stable, there is no stack errors (or other crashes) like in cog spur vm. You might also try compiling the VM from upstream sources[2], running either: * vm/build.linux32x86/squeak.cog.spur/build.debug/mvm * vm/build.linux64x64/squeak.cog.spur/build.debug/mvm Did you try the early 64-bit Pharo Image [3] suggested by Esteban in another thread ? Also, you might try Squeak 64-bit Image, since its the platform Eliot develops the VM on, so it is further advanced in 64-bit stability. Run vm/image/buildspurtrunk64image.sh. [2] https://github.com/OpenSmalltalk/vm [3] http://files.pharo.org/get-files/60/pharo-64.zip Now since you are getting down and dirty debugging this at VM level, probably good to shift this thread to [vm-dev]. http://lists.squeakfoundation.org/mailman/listinfo/vm-dev cheers -ben > > pf > > >> You could build a debug VM from here >> https://github.com/pharo-project/pharo-vm >> I also glimpsed some FreeBSD build options there you might try. >> cheers -ben >> >> On Fri, Jun 24, 2016 at 12:05 PM, Petr Fischer wrote: >> >> > So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved >> > compiled binaries to FreeBSD and tried to load Seaside to the latest 50760 >> > image. >> > Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt >> > >> > When I run this on CentOS, everything is fine (loading Seaside, no stack >> > errors), but when I run the same on FreeBSD, stack errors (segfaults) >> > occurs. >> > >> > So... There is something bad on FreeBSD side? Can I debug more? >> > >> > pf >> > >> > >> > > Try 50760 from... >> > > http://files.pharo.org/image/50/ >> > > >> > > cheers -ben >> > > >> > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer >> > wrote: >> > > > VM version (from >> > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/): >> > > > >> > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM] >> > > > CoInterpreter VMMaker.oscog-eem.1630 uuid: >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 >> > > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 >> > > > https://github.com/estebanlm/pharo-vm.git Commit: >> > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 >> > By: Esteban Lorenzano Jenkins build #498 >> > > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 >> > x86_64 GNU/Linux >> > > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: >> > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] >> > > > >> > > > Image version (from official 5.0 download): >> > > > >> > > > [version] 5.0 #50723 >> > > > >> > > > pf >> > > > >> > > >> in fact, this is not related to FFI? but it should be fixed? >> > > >> >> > > >> along with the VM version, which version of Pharo are you using? >> > > >> >> > > >> Esteban >> > > >> >> > > >> > On 17 Jun 2016, at 14:04, Max Leske wrote: >> > > >> > >> > > >> > Hi Petr, >> > > >> > >> > > >> > That looks like a bug with FreeType with our FFI. It should >> > actually have been fixed but I don?t know if the VM for FreeBSD is up to >> > date. Can you post the output of ?Smalltalk vm version?? >> > > >> > >> > > >> > Cheers, >> > > >> > Max >> > > >> > >> > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer >> > wrote: >> > > >> >> >> > > >> >> Hello, I got some random segfaults (while loading Seaside) with 32 >> > bit spur vm on FreeBSD - can someone (with low level knowledge) decode >> > attached log? >> > > >> >> Is this some problem with stack size? Can I fix this? >> > > >> >> >> > > >> >> Log: >> > > >> >> http://pastebin.com/raw/NpFUnjh0 >> > > >> >> >> > > >> >> There is "**StackOverflow**" lines n the log... From eliot.miranda at gmail.com Sun Jun 26 15:12:23 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun Jun 26 15:12:31 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> Message-ID: <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> > On Jun 24, 2016, at 1:53 AM, Bert Freudenberg wrote: > > On Fri, Jun 24, 2016 at 10:41 AM, Ben Coman wrote: >> >>> > Since its still quite early days on github, can I ask consideration be >>> > given to renaming the repo so we have... >>> > https://github.com/OpenSmalltalk/opensmalltalk-vm >>> > https://github.com/bencoman/opensmalltalk-vm > > +1 > >> If OpenSmalltalk/opensmalltalk-vm is considered too unwieldly, >> some alternatives could be: >> * OpenSmalltalk/osvm (this has a single conflicting exact match on github [last updated 4 years ago], and a four substring matches) >> * OpenSmalltalk/ostvm (for which github return no results) > > IMHO opensmalltalk-vm is best after all. Whatever works. Should we call a vote? The sooner we resolve this the better. > > - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160626/2ea4b949/attachment.htm From commits at source.squeak.org Mon Jun 27 01:04:48 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Jun 27 01:04:50 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1890.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1890.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1890 Author: eem Time: 26 June 2016, 6:03:06.041002 pm UUID: 63b22b9f-29ab-46d5-b533-05c17aa78dc6 Ancestors: VMMaker.oscog-eem.1889 Fix regression in Sista introsduced in VMMaker.oscog-eem.1877. The Sista scanMethod: should set useTwoPaths only for methods that would be frameless were it not for a store (which needs a frame if immutable). The regression was to set useTwoPaths in frameful methods containing a store; a stupid slip by your's truly. In 1890 Dutch artist Vincent van Gogh moves to Auvers-sur-Oise on the edge of Paris in the care of Dr Paul Gachet where he will produce around seventy paintings in as many days, and commit suicide soon thereafter, the Picture of Dorian Gray by Oscar Wilde is published by Philadelphia-based Lippincott's Monthly Magazine, and the United States Census Bureau begins using Herman Hollerith's tabulating machine to tabulate census returns using punched card input, a landmark in the history of computing hardware. Hollerith's company eventually becomes IBM. =============== Diff against VMMaker.oscog-eem.1889 =============== Item was changed: ----- Method: StackToRegisterMappingCogit>>scanMethod (in category 'compile abstract instructions') ----- scanMethod "Scan the method (and all embedded blocks) to determine - what the last bytecode is; extra bytes at the end of a method are used to encode things like source pointers or temp names - if the method needs a frame or not - what are the targets of any backward branches. - how many blocks it creates Answer the block count or on error a negative error code" | latestContinuation nExts descriptor pc numBlocks distance targetPC framelessStackDelta seenInstVarStore | needsFrame := useTwoPaths := seenInstVarStore := false. self maybeInitNumFixups. self maybeInitNumCounters. prevBCDescriptor := nil. NewspeakVM ifTrue: [numIRCs := 0]. (primitiveIndex > 0 and: [coInterpreter isQuickPrimitiveIndex: primitiveIndex]) ifTrue: [^0]. pc := latestContinuation := initialPC. numBlocks := framelessStackDelta := nExts := extA := extB := 0. [pc <= endPC] whileTrue: [byte0 := (objectMemory fetchByte: pc ofObject: methodObj) + bytecodeSetOffset. descriptor := self generatorAt: byte0. descriptor isExtension ifTrue: [descriptor opcode = Nop ifTrue: "unknown bytecode tag; see Cogit class>>#generatorTableFrom:" [^EncounteredUnknownBytecode]. self loadSubsequentBytesForDescriptor: descriptor at: pc. self perform: descriptor generator]. (descriptor isReturn and: [pc >= latestContinuation]) ifTrue: [endPC := pc]. needsFrame ifFalse: [(descriptor needsFrameFunction isNil or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) ifTrue: + [needsFrame := true] - [needsFrame := true. - self cppIf: IMMUTABILITY - ifTrue: [useTwoPaths := descriptor isInstVarStore]] ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta. + "With immutability we win simply by avoiding a frame build if the receiver is not immutable. + Without immutability we win if there are two or more stores amd the receiver is new." self cppIf: IMMUTABILITY + ifTrue: [useTwoPaths := descriptor isInstVarStore] - ifTrue: [] ifFalse: [descriptor isInstVarStore ifTrue: [seenInstVarStore ifTrue: [useTwoPaths := true] ifFalse: [seenInstVarStore := true]]]]]. descriptor isBranch ifTrue: [distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. targetPC := pc + descriptor numBytes + distance. (self isBackwardBranch: descriptor at: pc exts: nExts in: methodObj) ifTrue: [self initializeFixupAt: targetPC - initialPC] ifFalse: [latestContinuation := latestContinuation max: targetPC. self maybeCountFixup. self maybeCountCounter]]. descriptor isBlockCreation ifTrue: [numBlocks := numBlocks + 1. distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. targetPC := pc + descriptor numBytes + distance. latestContinuation := latestContinuation max: targetPC. self maybeCountFixup]. NewspeakVM ifTrue: [descriptor hasIRC ifTrue: [numIRCs := numIRCs + 1]]. pc := pc + descriptor numBytes. descriptor isExtension ifTrue: [nExts := nExts + 1] ifFalse: [nExts := extA := extB := 0]. prevBCDescriptor := descriptor]. ^numBlocks! From bert at freudenbergs.de Mon Jun 27 10:06:59 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Mon Jun 27 10:07:01 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> References: <1466501703.2453.6.camel@gmail.com> <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> Message-ID: On Sun, Jun 26, 2016 at 5:12 PM, Eliot Miranda wrote: > > On Jun 24, 2016, at 1:53 AM, Bert Freudenberg > wrote: > > On Fri, Jun 24, 2016 at 10:41 AM, Ben Coman wrote: >> >> > Since its still quite early days on github, can I ask consideration be >>> > given to renaming the repo so we have... >>> > https://github.com/OpenSmalltalk/opensmalltalk-vm >>> > https://github.com/bencoman/opensmalltalk-vm >>> >> > IMHO opensmalltalk-vm is best after all. > > Whatever works. Should we call a vote? The sooner we resolve this the > better. > It's been suggested, seconded, you're fine with it, so let's just do it, asap. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/b1d090c4/attachment-0001.htm From kilon.alios at gmail.com Mon Jun 27 11:05:49 2016 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Mon Jun 27 11:06:01 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> Message-ID: I agree it's a good day enough name , go for it On Mon, 27 Jun 2016 at 13:07, Bert Freudenberg wrote: > On Sun, Jun 26, 2016 at 5:12 PM, Eliot Miranda > wrote: > >> On Jun 24, 2016, at 1:53 AM, Bert Freudenberg >> wrote: >> >> On Fri, Jun 24, 2016 at 10:41 AM, Ben Coman wrote: >>> >>> > Since its still quite early days on github, can I ask consideration be >>>> > given to renaming the repo so we have... >>>> > https://github.com/OpenSmalltalk/opensmalltalk-vm >>>> > https://github.com/bencoman/opensmalltalk-vm >>>> >>> >> IMHO opensmalltalk-vm is best after all. >> >> Whatever works. Should we call a vote? The sooner we resolve this the >> better. >> > > It's been suggested, seconded, you're fine with it, so let's just do it, > asap. > > - Bert - > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/e5692b3d/attachment.htm From eliot.miranda at gmail.com Mon Jun 27 16:31:50 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 27 16:31:54 2016 Subject: [Vm-dev] ARM linux builds Message-ID: Hi All, I'd like to resolve this quickly but my favoured resolution will affect travis. I want to rename build.linux32ARM to build.linux32ARMv6 and add build.linux32ARMv7. s that ok with people? Will the Travis maintainers be happy to build both? We need READMEs that point out that the v6 builds are for Raspberry Pi and that v7 builds are for "everywhere else" (unless we can be more specific?). Unless I hear a protest within the next two hours I will commit this change. Is that OK? _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/eadcdf08/attachment.htm From tim at rowledge.org Mon Jun 27 16:48:27 2016 From: tim at rowledge.org (tim Rowledge) Date: Mon Jun 27 16:48:07 2016 Subject: [Vm-dev] ARM linux builds In-Reply-To: References: Message-ID: <009D67E1-6E4D-4455-899D-9CA902CC4F84@rowledge.org> > On 27-06-2016, at 9:31 AM, Eliot Miranda wrote: > I'd like to resolve this quickly but my favoured resolution will affect travis. I want to rename build.linux32ARM to build.linux32ARMv6 and add build.linux32ARMv7. s that ok with people? It?s a perfectly reasonable thing to do - and we?ll need ARMv8 eventually of course - but it doesn?t have a lot to do with the original problem of why Dave couldn?t build a vm on his new Pi... tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: NNI: Neglect Next Instruction From eliot.miranda at gmail.com Mon Jun 27 17:04:34 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 27 17:04:37 2016 Subject: [Vm-dev] Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD] In-Reply-To: References: <20160617112645.GI2592@pf-bsd.local> <34C48949-B0F5-4FC6-9C91-863DB58F7D7C@gmail.com> <20160617164937.GJ2592@pf-bsd.local> <20160624040520.GC39529@pf-bsd.local> <20160626123725.GD1194@pf-bsd.local> Message-ID: Hi Ben, On Sun, Jun 26, 2016 at 6:44 AM, Ben Coman wrote: > > On Sun, Jun 26, 2016 at 8:37 PM, Petr Fischer wrote: > > Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors > occurs... So I am still building with "PharoVMSpur32Builder buildUnix32" > under Linux (CentOS6) and then move compiled vm to my FreeBSD box with > Linux compatibility layer. > > > > I compiled DEBUG vm version according to your advice and this is gdb > output: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x080aefc1 in scavengeReferentsOf (referrer=684415032) at > /home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014 > > 39014 if (((longAt(referent)) & ((classIndexMask()) - > (isForwardedObjectClassIndexPun()))) == 0) { > > The C files are generated from VMMaker and the line numbers change a > lot. If you look upwards in the C file you should see a generated > comment that links to the Smalltalk source it was generated from. > > > > > I need to learn a little, how to play this "core C" game in gdb... > > What next? > > I recently learnt a bit of using gdb on the image. I'm planning to > write up something but its a few weeks off. The old post How to debug > the VM? [1] by Mariano needs a bit of adaption, but got me off to a > good start. If you look in VMMaker package where #printAllStacks is > defined you'll see some others you can call, that just print the > current Smalltalk call stack. > > [1] https://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/ > > > > > A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but stable, > there is no stack errors (or other crashes) like in cog spur vm. > > You might also try compiling the VM from upstream sources[2], running > either: > * vm/build.linux32x86/squeak.cog.spur/build.debug/mvm > * vm/build.linux64x64/squeak.cog.spur/build.debug/mvm > > Did you try the early 64-bit Pharo Image [3] suggested by Esteban in > another thread ? > > Also, you might try Squeak 64-bit Image, since its the platform Eliot > develops the VM on, so it is further advanced in 64-bit stability. > That's not true. I develop on Mac OS X using Spur and the 32-bit VM. I do run the 64-bit system from time to time and am currently collaborating with Bob Westergaard to move the Cadence system over to 64-bits. I do hope to use 64-bit Spur from day-to-day but am not there yet, not for any reasons of deficiency in 64-bits but simply because my current, large, project-laden, VMMaker image is in 32-bits and I've not changed it over yet. > Run vm/image/buildspurtrunk64image.sh. > > [2] https://github.com/OpenSmalltalk/vm > [3] http://files.pharo.org/get-files/60/pharo-64.zip > > Now since you are getting down and dirty debugging this at VM level, > probably good to shift this thread to [vm-dev]. > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > > cheers -ben > > > > > pf > > > > > >> You could build a debug VM from here > >> https://github.com/pharo-project/pharo-vm > >> I also glimpsed some FreeBSD build options there you might try. > >> cheers -ben > >> > >> On Fri, Jun 24, 2016 at 12:05 PM, Petr Fischer > wrote: > >> > >> > So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved > >> > compiled binaries to FreeBSD and tried to load Seaside to the latest > 50760 > >> > image. > >> > Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt > >> > > >> > When I run this on CentOS, everything is fine (loading Seaside, no > stack > >> > errors), but when I run the same on FreeBSD, stack errors (segfaults) > >> > occurs. > >> > > >> > So... There is something bad on FreeBSD side? Can I debug more? > >> > > >> > pf > >> > > >> > > >> > > Try 50760 from... > >> > > http://files.pharo.org/image/50/ > >> > > > >> > > cheers -ben > >> > > > >> > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer > > >> > wrote: > >> > > > VM version (from > >> > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/): > >> > > > > >> > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur > ITHB VM] > >> > > > CoInterpreter VMMaker.oscog-eem.1630 uuid: > >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > >> > > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: > >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > >> > > > https://github.com/estebanlm/pharo-vm.git Commit: > >> > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 > +0100 > >> > By: Esteban Lorenzano Jenkins build #498 > >> > > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian > 3.2.73-2+deb7u2 > >> > x86_64 GNU/Linux > >> > > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin > [default: > >> > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] > >> > > > > >> > > > Image version (from official 5.0 download): > >> > > > > >> > > > [version] 5.0 #50723 > >> > > > > >> > > > pf > >> > > > > >> > > >> in fact, this is not related to FFI? but it should be fixed? > >> > > >> > >> > > >> along with the VM version, which version of Pharo are you using? > >> > > >> > >> > > >> Esteban > >> > > >> > >> > > >> > On 17 Jun 2016, at 14:04, Max Leske > wrote: > >> > > >> > > >> > > >> > Hi Petr, > >> > > >> > > >> > > >> > That looks like a bug with FreeType with our FFI. It should > >> > actually have been fixed but I don?t know if the VM for FreeBSD is up > to > >> > date. Can you post the output of ?Smalltalk vm version?? > >> > > >> > > >> > > >> > Cheers, > >> > > >> > Max > >> > > >> > > >> > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer > >> > wrote: > >> > > >> >> > >> > > >> >> Hello, I got some random segfaults (while loading Seaside) > with 32 > >> > bit spur vm on FreeBSD - can someone (with low level knowledge) decode > >> > attached log? > >> > > >> >> Is this some problem with stack size? Can I fix this? > >> > > >> >> > >> > > >> >> Log: > >> > > >> >> http://pastebin.com/raw/NpFUnjh0 > >> > > >> >> > >> > > >> >> There is "**StackOverflow**" lines n the log... > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/b6fe3ee7/attachment-0001.htm From btc at openinworld.com Mon Jun 27 17:32:31 2016 From: btc at openinworld.com (Ben Coman) Date: Mon Jun 27 17:32:53 2016 Subject: [Vm-dev] Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD] In-Reply-To: References: <20160617112645.GI2592@pf-bsd.local> <34C48949-B0F5-4FC6-9C91-863DB58F7D7C@gmail.com> <20160617164937.GJ2592@pf-bsd.local> <20160624040520.GC39529@pf-bsd.local> <20160626123725.GD1194@pf-bsd.local> Message-ID: On Tue, Jun 28, 2016 at 1:04 AM, Eliot Miranda wrote: > > Hi Ben, > > On Sun, Jun 26, 2016 at 6:44 AM, Ben Coman wrote: >> >> >> On Sun, Jun 26, 2016 at 8:37 PM, Petr Fischer wrote: >> > Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors occurs... So I am still building with "PharoVMSpur32Builder buildUnix32" under Linux (CentOS6) and then move compiled vm to my FreeBSD box with Linux compatibility layer. >> > >> > I compiled DEBUG vm version according to your advice and this is gdb output: >> > >> > Program received signal SIGSEGV, Segmentation fault. >> > 0x080aefc1 in scavengeReferentsOf (referrer=684415032) at /home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014 >> > 39014 if (((longAt(referent)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))) == 0) { >> >> The C files are generated from VMMaker and the line numbers change a >> lot. If you look upwards in the C file you should see a generated >> comment that links to the Smalltalk source it was generated from. >> >> > >> > I need to learn a little, how to play this "core C" game in gdb... >> > What next? >> >> I recently learnt a bit of using gdb on the image. I'm planning to >> write up something but its a few weeks off. The old post How to debug >> the VM? [1] by Mariano needs a bit of adaption, but got me off to a >> good start. If you look in VMMaker package where #printAllStacks is >> defined you'll see some others you can call, that just print the >> current Smalltalk call stack. >> >> [1] https://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/ >> >> > >> > A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but stable, there is no stack errors (or other crashes) like in cog spur vm. >> >> You might also try compiling the VM from upstream sources[2], running either: >> * vm/build.linux32x86/squeak.cog.spur/build.debug/mvm >> * vm/build.linux64x64/squeak.cog.spur/build.debug/mvm >> >> Did you try the early 64-bit Pharo Image [3] suggested by Esteban in >> another thread ? >> >> Also, you might try Squeak 64-bit Image, since its the platform Eliot >> develops the VM on, so it is further advanced in 64-bit stability. > > > That's not true. I develop on Mac OS X using Spur and the 32-bit VM. I do run the 64-bit system from time to time and am currently collaborating with Bob Westergaard to move the Cadence system over to 64-bits. I do hope to use 64-bit Spur from day-to-day but am not there yet, not for any reasons of deficiency in 64-bits but simply because my current, large, project-laden, VMMaker image is in 32-bits and I've not changed it over yet. Thanks for that insight to correct my bad presumption. Strange the images that develop in my head in isolation. cheers -ben From eliot.miranda at gmail.com Mon Jun 27 17:36:36 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 27 17:36:40 2016 Subject: [Vm-dev] Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD] In-Reply-To: References: <20160617112645.GI2592@pf-bsd.local> <34C48949-B0F5-4FC6-9C91-863DB58F7D7C@gmail.com> <20160617164937.GJ2592@pf-bsd.local> <20160624040520.GC39529@pf-bsd.local> <20160626123725.GD1194@pf-bsd.local> Message-ID: On Mon, Jun 27, 2016 at 10:32 AM, Ben Coman wrote: > > On Tue, Jun 28, 2016 at 1:04 AM, Eliot Miranda > wrote: > > > > Hi Ben, > > > > On Sun, Jun 26, 2016 at 6:44 AM, Ben Coman wrote: > >> > >> > >> On Sun, Jun 26, 2016 at 8:37 PM, Petr Fischer > wrote: > >> > Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors > occurs... So I am still building with "PharoVMSpur32Builder buildUnix32" > under Linux (CentOS6) and then move compiled vm to my FreeBSD box with > Linux compatibility layer. > >> > > >> > I compiled DEBUG vm version according to your advice and this is gdb > output: > >> > > >> > Program received signal SIGSEGV, Segmentation fault. > >> > 0x080aefc1 in scavengeReferentsOf (referrer=684415032) at > /home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014 > >> > 39014 if (((longAt(referent)) & ((classIndexMask()) - > (isForwardedObjectClassIndexPun()))) == 0) { > >> > >> The C files are generated from VMMaker and the line numbers change a > >> lot. If you look upwards in the C file you should see a generated > >> comment that links to the Smalltalk source it was generated from. > >> > >> > > >> > I need to learn a little, how to play this "core C" game in gdb... > >> > What next? > >> > >> I recently learnt a bit of using gdb on the image. I'm planning to > >> write up something but its a few weeks off. The old post How to debug > >> the VM? [1] by Mariano needs a bit of adaption, but got me off to a > >> good start. If you look in VMMaker package where #printAllStacks is > >> defined you'll see some others you can call, that just print the > >> current Smalltalk call stack. > >> > >> [1] https://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/ > >> > >> > > >> > A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but > stable, there is no stack errors (or other crashes) like in cog spur vm. > >> > >> You might also try compiling the VM from upstream sources[2], running > either: > >> * vm/build.linux32x86/squeak.cog.spur/build.debug/mvm > >> * vm/build.linux64x64/squeak.cog.spur/build.debug/mvm > >> > >> Did you try the early 64-bit Pharo Image [3] suggested by Esteban in > >> another thread ? > >> > >> Also, you might try Squeak 64-bit Image, since its the platform Eliot > >> develops the VM on, so it is further advanced in 64-bit stability. > > > > > > That's not true. I develop on Mac OS X using Spur and the 32-bit VM. I > do run the 64-bit system from time to time and am currently collaborating > with Bob Westergaard to move the Cadence system over to 64-bits. I do hope > to use 64-bit Spur from day-to-day but am not there yet, not for any > reasons of deficiency in 64-bits but simply because my current, large, > project-laden, VMMaker image is in 32-bits and I've not changed it over yet. > > Thanks for that insight to correct my bad presumption. Strange the > images that develop in my head in isolation. > cheers -ben > :-). We'll have to figure out some way of smuggling you to an ESUG :-) _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/f1b1185c/attachment.htm From eliot.miranda at gmail.com Mon Jun 27 18:08:34 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 27 18:08:36 2016 Subject: [Vm-dev] equivalent of svn export... Message-ID: Hi All, I have build.linux32ARM which is full of generated crap. I have renamed it to build.linux32ARMv6 via git mv build.linux32ARM build.linux32ARMv6. So far so good. Now I want to clone the clean state of build.linux32ARMv6 (or of https://github.com/OpenSmalltalk/vm/build.linux32ARMv6) to create the clean state of build.linux32ARMv7. But I can't?!?!? In Subversion one can extract a subdirectory of the entire repository; great for Travis builds, where one doesn't waste time cloning the entire repository. Does git simply not support this? I see http://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export but it doesn't appear to offer a solution beyond cloning the entire repository :-( _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/2f573c4b/attachment.htm From eliot.miranda at gmail.com Mon Jun 27 19:04:35 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Jun 27 19:04:38 2016 Subject: [Vm-dev] Re: equivalent of svn export... In-Reply-To: References: Message-ID: On Mon, Jun 27, 2016 at 11:08 AM, Eliot Miranda wrote: > Hi All, > > I have build.linux32ARM which is full of generated crap. I have > renamed it to build.linux32ARMv6 via git > mv build.linux32ARM build.linux32ARMv6. So far so good. Now I want to > clone the clean state of build.linux32ARMv6 (or of > https://github.com/OpenSmalltalk/vm/build.linux32ARMv6) to create the > clean state of build.linux32ARMv7. But I can't?!?!? > > In Subversion one can extract a subdirectory of the entire repository; > great for Travis builds, where one doesn't waste time cloning the entire > repository. Does git simply not support this? I see > > http://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export > but it doesn't appear to offer a solution beyond cloning the entire > repository :-( > _,,,^..^,,,_ > best, Eliot > BTW, my hack is to maintain a clone of the repository I'm calling oscogvm.clean, as a sibling of my oscogvm clone of OpenSmalltalk/vm, and when I want to access it I'll do a git pull and then copy what I want. Expensive, and error-prone, but functional. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/a3647006/attachment.htm From jakob.reschke at student.hpi.de Mon Jun 27 19:15:55 2016 From: jakob.reschke at student.hpi.de (Jakob Reschke) Date: Mon Jun 27 19:16:18 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: Hi Elliot, as far as I know, git does not support cloning only part of a repository (you can checkout only parts of it, but need to clone the entire history anyway). However, I think these people have all the answers for you: http://stackoverflow.com/questions/7106012/download-a-single-folder-or-directory-from-a-github-repo In short: Since GitHub allows you to access repositories via svn, you can simply use svn export to extract a clean subdirectory. Otherwise you would use `git archive` for similar tasks; it creates compressed files from arbitrary trees (e. g., git archive -o build.linux32ARMv6.zip HEAD:build.linux32ARMv6, where HEAD can be any revision). git archive also has a --remote option, which seems to allow one to do similar things like svn export on remote repositories, but GitHub does not support that. See this answer: http://stackoverflow.com/a/15983139/383568 Best regards, Jakob 2016-06-27 20:08 GMT+02:00 Eliot Miranda : > From Das.Linux at gmx.de Mon Jun 27 20:32:42 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon Jun 27 20:32:45 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: <006130C1-F058-49FF-862F-512D391B7235@gmx.de> Hi Eliot On 27.06.2016, at 20:08, Eliot Miranda wrote: > Hi All, > > I have build.linux32ARM which is full of generated crap. I have renamed it to build.linux32ARMv6 via git mv build.linux32ARM build.linux32ARMv6. So far so good. Now I want to clone the clean state of build.linux32ARMv6 (or of https://github.com/OpenSmalltalk/vm/build.linux32ARMv6) to create the clean state of build.linux32ARMv7. But I can't?!?!? > > In Subversion one can extract a subdirectory of the entire repository; great for Travis builds, where one doesn't waste time cloning the entire repository. Does git simply not support this? I see > http://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export > but it doesn't appear to offer a solution beyond cloning the entire repository :-( I have not yet grasped your use case, please help me there. You want to maintain both build.linux32ARMv6 and build.linux32ARMv7, but build.linux32ARMv7 is actually build.linux32ARM? If so, what about: mv build.linux32ARM build.linux32ARMv7 #note no git git checkout -- build.linux32ARM mv build.linux32ARM build.linux32ARMv6 and then `git add` the pieces of build.linux32ARMv6 and build.linux32ARMv7 as necessary and `commit` or replace the latter with `git mv`? If it is only for local development to get a clean slate, it is quite similar, but leave out the `commit` or `git mv` part? HTH Best -Tobias From eliot.miranda at gmail.com Tue Jun 28 00:02:58 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 28 00:03:01 2016 Subject: [Vm-dev] CryptographyPlugins Message-ID: Hi, where does this live right now and can someone give me write permission asap? I've fixed the DSAPlgin for 64-bits, sped up the argument marshalling, and want to commit and regenerate. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160627/ca03f3c3/attachment.htm From btc at openinworld.com Tue Jun 28 00:28:41 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 28 00:29:04 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: On Tue, Jun 28, 2016 at 2:08 AM, Eliot Miranda wrote: > > Hi All, > > I have build.linux32ARM which is full of generated crap. I have renamed it to build.linux32ARMv6 via git mv build.linux32ARM build.linux32ARMv6. So far so good. Now I want to clone the clean state of build.linux32ARMv6 (or of https://github.com/OpenSmalltalk/vm/build.linux32ARMv6) to create the clean state of build.linux32ARMv7. But I can't?!?!? I was curious to learn the answer to this, so I found these... Stack Overflow, Record file copy operation with Git: Git does not do rename tracking nor copy tracking, which means it doesn't record renames or copies. What it does instead is rename and copy detection http://stackoverflow.com/questions/1043388/record-file-copy-operation-with-git One of the things Git gets right: Fancy file rename and copy detection deduced merely by looking at the commit graph. It doesn't need any metadata to be stored. If you store metadata, you're locking yourself into the best algorithms you had at the time of storage; if you forget metadata and instead deduce you can always use the very best algorithms available at the time you examine the history. http://www.wincent.com/a/about/wincent/weblog/archives/2007/11/one_of_the_thin.php Git Mail List, How to fork a file (git cp ?) ?yvind A. Holm response: Git has a rename command git mv, but that is just for convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content http://git.661346.n2.nabble.com/How-to-fork-a-file-git-cp-td6331860.html Code Archaeology With Git: takes a look at techniques for separating the interesting commits from the uninteresting ones http://jfire.io/blog/2012/03/07/code-archaeology-with-git/ Configure git diff to default to rename and copy detection: git config --global diff.renames copies http://nuclearsquid.com/writings/git-tricks-tips-workflows/ > > In Subversion one can extract a subdirectory of the entire repository; great for Travis builds, where one doesn't waste time cloning the entire repository. Does git simply not support this? I see > http://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export > but it doesn't appear to offer a solution beyond cloning the entire repository :-( Build systems can use a shallow clone... git clone --depth depth remote-url or single branch clone... git clone URL --branch branch_name --single-branch [folder] http://blogs.atlassian.com/2014/05/handle-big-repositories-git/ cheers -ben From btc at openinworld.com Tue Jun 28 00:57:36 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 28 00:57:59 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: On Tue, Jun 28, 2016 at 8:28 AM, Ben Coman wrote: > On Tue, Jun 28, 2016 at 2:08 AM, Eliot Miranda wrote: >> >> Hi All, >> >> I have build.linux32ARM which is full of generated crap. I have renamed it to build.linux32ARMv6 via git mv build.linux32ARM build.linux32ARMv6. So far so good. Now I want to clone the clean state of build.linux32ARMv6 (or of https://github.com/OpenSmalltalk/vm/build.linux32ARMv6) to create the clean state of build.linux32ARMv7. But I can't?!?!? > > I was curious to learn the answer to this, so I found these... > > Stack Overflow, Record file copy operation with Git: > Git does not do rename tracking nor copy tracking, > which means it doesn't record renames or copies. > What it does instead is rename and copy detection > http://stackoverflow.com/questions/1043388/record-file-copy-operation-with-git > > One of the things Git gets right: > Fancy file rename and copy detection deduced merely by looking at the > commit graph. It doesn't need any metadata to be stored. If you store > metadata, you're locking yourself into the best algorithms you had at > the time of storage; if you forget metadata and instead deduce you can > always use the very best algorithms available at the time you examine > the history. > http://www.wincent.com/a/about/wincent/weblog/archives/2007/11/one_of_the_thin.php > > Git Mail List, How to fork a file (git cp ?) > ?yvind A. Holm response: > Git has a rename command git mv, but that is just for > convenience. The effect is indistinguishable from removing the file and > adding another with different name and the same content > http://git.661346.n2.nabble.com/How-to-fork-a-file-git-cp-td6331860.html > > Code Archaeology With Git: > takes a look at techniques for separating the interesting commits from > the uninteresting ones > http://jfire.io/blog/2012/03/07/code-archaeology-with-git/ > > Configure git diff to default to rename and copy detection: > git config --global diff.renames copies > http://nuclearsquid.com/writings/git-tricks-tips-workflows/ > >> >> In Subversion one can extract a subdirectory of the entire repository; great for Travis builds, where one doesn't waste time cloning the entire repository. Does git simply not support this? I see >> http://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export >> but it doesn't appear to offer a solution beyond cloning the entire repository :-( > > Build systems can use a shallow clone... > git clone --depth depth remote-url > or single branch clone... > git clone URL --branch branch_name --single-branch [folder] > http://blogs.atlassian.com/2014/05/handle-big-repositories-git/ > > cheers -ben A couple more useful reads... gitdiffcore(7) - Linux man page Authoritative reference, with worked example. scroll down to... DIFFCORE-RENAME http://linux.die.net/man/7/gitdiffcore Git Secrets Revealed Git heuristically ferrets out renames and copies between successive versions. In fact, it can detect chunks of code being moved or copied around between files! [Also read the short section on "Blobs"] http://www-cs-students.stanford.edu/~blynn/gitmagic/ch08.html I'm not at a computer where I can test this, but in summary I would just try... $ git checkout -b splitARM Cog $ mv build.linux32ARM build.linux32ARMv6 $ cp -r build.linux32ARMv6 build.linux32ARMv7 $ git add build.linux32ARMv6 build.linux32ARMv7 $ git commit -m "Split ARM build into ARMv6/ARMv7" $ git diff -M -C --summary Cog You might first want to $ cp -r oscogvm oscogvm.practice cheers -ben From lists at fniephaus.com Tue Jun 28 07:19:25 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Tue Jun 28 07:19:38 2016 Subject: [Vm-dev] ARM linux builds In-Reply-To: <009D67E1-6E4D-4455-899D-9CA902CC4F84@rowledge.org> References: <009D67E1-6E4D-4455-899D-9CA902CC4F84@rowledge.org> Message-ID: +1 for renaming ARM builds to linux32ARMv6, linux32ARMv7, linux32ARMv8... -- On Mon, Jun 27, 2016 at 6:48 PM tim Rowledge wrote: > > > > On 27-06-2016, at 9:31 AM, Eliot Miranda > wrote: > > I'd like to resolve this quickly but my favoured resolution will > affect travis. I want to rename build.linux32ARM to build.linux32ARMv6 and > add build.linux32ARMv7. s that ok with people? > > It?s a perfectly reasonable thing to do - and we?ll need ARMv8 eventually > of course - but it doesn?t have a lot to do with the original problem of > why Dave couldn?t build a vm on his new Pi... > > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: NNI: Neglect Next Instruction > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160628/764c5275/attachment.htm From estebanlm at gmail.com Tue Jun 28 07:21:47 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Tue Jun 28 07:21:51 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: Hi, > On 28 Jun 2016, at 02:57, Ben Coman wrote: > > I'm not at a computer where I can test this, but in summary I would just try... > $ git checkout -b splitARM Cog > $ mv build.linux32ARM build.linux32ARMv6 > $ cp -r build.linux32ARMv6 build.linux32ARMv7 > $ git add build.linux32ARMv6 build.linux32ARMv7 > $ git commit -m "Split ARM build into ARMv6/ARMv7" > $ git diff -M -C --summary Cog I?m not sure either what?s the purpose of checking out just a directory? in git, since it does global versions for commits, it does not has much sense? also git is designed to do the branching a very easy/efficient task open a new branch? and then merging back is a second-time task). So I suppose this is the right way to do it? I imagine that different tools means sometimes different ways of doing things, and forcing ?old way? can be not as effective as it was before. +1 for this step list :) > You might first want to > $ cp -r oscogvm oscogvm.practice why? if you made a mistake you can just kill the branch :) Esteban -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160628/1630d7be/attachment-0001.htm From btc at openinworld.com Tue Jun 28 11:59:58 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 28 12:00:21 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: On Tue, Jun 28, 2016 at 3:21 PM, Esteban Lorenzano wrote: > > Hi, > > > On 28 Jun 2016, at 02:57, Ben Coman wrote: > > I'm not at a computer where I can test this, but in summary I would just try... > $ git checkout -b splitARM Cog > $ mv build.linux32ARM build.linux32ARMv6 > $ cp -r build.linux32ARMv6 build.linux32ARMv7 > $ git add build.linux32ARMv6 build.linux32ARMv7 > $ git commit -m "Split ARM build into ARMv6/ARMv7" > $ git diff -M -C --summary Cog > > > I?m not sure either what?s the purpose of checking out just a directory? in git, since it does global versions for commits, it does not has much sense? also git is designed to do the branching a very easy/efficient task open a new branch? and then merging back is a second-time task). > So I suppose this is the right way to do it? I imagine that different tools means sometimes different ways of doing things, and forcing ?old way? can be not as effective as it was before. > > +1 for this step list :) > > You might first want to > $ cp -r oscogvm oscogvm.practice > > > why? if you made a mistake you can just kill the branch :) > You are right. But it can give a bit a freedom while experimenting to build confidence with a new system. cheers -ben From btc at openinworld.com Tue Jun 28 15:41:48 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 28 15:42:12 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: On Sun, Jun 26, 2016 at 4:51 AM, Tim Felgentreff wrote: > > > Hi Ben, > > One of your arguments is about history cleaning. > Mostly my discouraging of rebase -i comes from experience with people who made a mistake (e.g. as simple as deleting a line and then getting "lucky" and having git not complain about conflicts during the rebase) to lose a commit entirely. And sometimes they continued working for a while, eventually a git gc was triggered, and then that commit was cleaned up and was lost for good by the time they noticed their work was gone. This happened to people around me more than just once, and then I wasn't able to help because git gc had run. Eventually I gave up and encouraged people who do not want to spend the time to really put in the work and understand how git works and what the internal structures are to not use rebase. Ah, it never cross my mind to delete a line. So I never hit the problem. At https://git-scm.com/docs/git-rebase I found rebase.missingCommitsCheck - If set to "warn", print warnings about removed commits in interactive mode. If set to "error", print the warnings and stop the rebase. If set to "ignore", no checking is done. "ignore" by default. which you can see in action here... https://github.com/git/git/blob/cf4c2cfe52be5bd973a4838f73a35d3959ce2f43/git-rebase--interactive.sh warn "Warning: some commits may have been dropped" \ "accidentally." warn "Dropped commits (newer to older):" but that didn't work for me and I had to ask on #git IRC to discover this was introduced in 2.6.0. I'm only 2.1.4 and current release is 2.9.0. ((Also btw I learnt a new trick, at the top of that last link, click , then search for "missingCommitsCheck" and scroll back up to click on the commit, and at the bottom of the commit it says "master v2.9.0?v2.6.0-rc0" )) > > Your other argument is about bisecting. Another experience I had was with people rebasing to "clean up" history by grouping related changes together, but then not checking that each commit still compiles. So the bisect scripts we used in these projects still had to include the logic to skip non-compiling commits. Good point. Although I do like Holger's git rebase -i --execute "./compile_and_test_all.sh" origin/master but this is probably hard to police in an open source environment. > As would any script used on a repository where no one used rebase to remove such 'bad' commits. > Secondly, if people tried a bunch of different approaches and finally refactored their code and then squashed it all together, any bisects will only find one large commit as the culprit without explanatory history around it, making debugging harder. I wouldn't expect every commit to be squashed, just the minuscule things. Logical groups of work should remain. > > All that being said, if you all think it's safe and we all agree that no one has the right to complain about git if they loose their commits, I won't strongly oppose rebasing. Its probably too early for anyone new to git to form an experiential opinion on whether rebase is safe. Still the main contributors coudl choose to be conservative. I think the CONTRIBUTION page could say something like... "git rebase is a dangerous but useful tool for a narrow range of well defined tasks. Receipies for these tasks are presented below. For project consistency, you should adhere strongly to the recipe and if something unexpected occurs, do... git rebase --abort. Please discuss any deviations on the mail list." and if that sounds reasonable, I'll follow up with some recipes, one of which might be check "git --version" and upgrade to latest git to make rebase a bit safer. cheers -ben P.S. while on the topic of disasters we can learn from, this "Disaster 2" story [1] might be a useful read for anyone adapting from SVN. [1] https://randyfay.com/content/avoiding-git-disasters-gory-story From eliot.miranda at gmail.com Tue Jun 28 16:10:50 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Jun 28 16:10:55 2016 Subject: [Vm-dev] equivalent of svn export... In-Reply-To: References: Message-ID: Hi Esteban, > On Jun 28, 2016, at 12:21 AM, Esteban Lorenzano wrote: > > Hi, > > >> On 28 Jun 2016, at 02:57, Ben Coman wrote: >> >> I'm not at a computer where I can test this, but in summary I would just try... >> $ git checkout -b splitARM Cog >> $ mv build.linux32ARM build.linux32ARMv6 >> $ cp -r build.linux32ARMv6 build.linux32ARMv7 >> $ git add build.linux32ARMv6 build.linux32ARMv7 >> $ git commit -m "Split ARM build into ARMv6/ARMv7" >> $ git diff -M -C --summary Cog > > I?m not sure either what?s the purpose of checking out just a directory? in git, since it does global versions for commits, it does not has much sense? also git is designed to do the branching a very easy/efficient task open a new branch? and then merging back is a second-time task). At Cadence there are automatic build of only VMs derived from nsspursrc and only on build.linux32x86, so when we were on subversion we would check out these and processors and build and save time and space. Now we have to check out the whole thing. > So I suppose this is the right way to do it? I imagine that different tools means sometimes different ways of doing things, and forcing ?old way? can be not as effective as it was before. > > +1 for this step list :) > >> You might first want to >> $ cp -r oscogvm oscogvm.practice > > why? if you made a mistake you can just kill the branch :) +1 > > Esteban -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160628/28a9222e/attachment.htm From btc at openinworld.com Tue Jun 28 17:38:45 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 28 17:39:08 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: On Tue, Jun 28, 2016 at 11:41 PM, Ben Coman wrote: > On Sun, Jun 26, 2016 at 4:51 AM, Tim Felgentreff > wrote: >> >> >> Hi Ben, >> >> One of your arguments is about history cleaning. >> Mostly my discouraging of rebase -i comes from experience with people who made a mistake (e.g. as simple as deleting a line and then getting "lucky" and having git not complain about conflicts during the rebase) to lose a commit entirely. And sometimes they continued working for a while, eventually a git gc was triggered, and then that commit was cleaned up and was lost for good by the time they noticed their work was gone. This happened to people around me more than just once, and then I wasn't able to help because git gc had run. Eventually I gave up and encouraged people who do not want to spend the time to really put in the work and understand how git works and what the internal structures are to not use rebase. > > Ah, it never cross my mind to delete a line. So I never hit the problem. > > At https://git-scm.com/docs/git-rebase I found > rebase.missingCommitsCheck - If set to "warn", print warnings > about removed commits in interactive mode. If set to "error", print > the warnings and stop the rebase. If set to "ignore", no checking is > done. "ignore" by default. > > which you can see in action here... > https://github.com/git/git/blob/cf4c2cfe52be5bd973a4838f73a35d3959ce2f43/git-rebase--interactive.sh > warn "Warning: some commits may have been dropped" \ > "accidentally." > warn "Dropped commits (newer to older):" > > but that didn't work for me and I had to ask on #git IRC to discover > this was introduced in 2.6.0. > I'm only 2.1.4 and current release is 2.9.0. It took some work to determine out how to upgrade git, so I share that for reference... The easy path didn't work... $ sudo apt-get dist-upgrade $ lsb_release -a Debian GNU/Linux 8.4 (jessie) $ git --version 2.1.4 So I built from source per... http://superuser.com/questions/644586/how-to-upgrade-to-latest-git-on-debian-7 $ sudo apt-get install devscripts $ mkdir ~/devel && cd $_ $ dget http://ftp.de.debian.org/debian/pool/main/g/git/git_2.8.1-1.dsc $ dpkg-source -x git_2.1.4-2.1.dsc $ cd git $ dpkg-checkbuilddeps $ apt-get build-dep git $ dch --bpo $ dpkg-buildpackage -uc -us -b $ cd .. $ sudo dpkg -i git_*.deb git-man_*.deb $ git --version 2.8.1 cheers -ben > > ((Also btw I learnt a new trick, at the top of that last link, click , > then search for "missingCommitsCheck" and scroll back up > to click on the commit, and at the bottom of the commit > it says "master v2.9.0?v2.6.0-rc0" )) > > > >> >> Your other argument is about bisecting. Another experience I had was with people rebasing to "clean up" history by grouping related changes together, but then not checking that each commit still compiles. So the bisect scripts we used in these projects still had to include the logic to skip non-compiling commits. > > Good point. Although I do like Holger's > git rebase -i --execute "./compile_and_test_all.sh" origin/master > but this is probably hard to police in an open source environment. > >> As would any script used on a repository where no one used rebase to remove such 'bad' commits. >> Secondly, if people tried a bunch of different approaches and finally refactored their code and then squashed it all together, any bisects will only find one large commit as the culprit without explanatory history around it, making debugging harder. > > I wouldn't expect every commit to be squashed, just the minuscule > things. Logical groups of work should remain. > >> >> All that being said, if you all think it's safe and we all agree that no one has the right to complain about git if they loose their commits, I won't strongly oppose rebasing. > > Its probably too early for anyone new to git to form an experiential > opinion on whether rebase is safe. Still the main contributors coudl > choose to be conservative. I think the CONTRIBUTION page could say > something like... > "git rebase is a dangerous but useful tool for a narrow range of > well defined tasks. Receipies for these tasks are presented below. > For project consistency, you should adhere strongly to the recipe and > if something unexpected occurs, do... git rebase --abort. Please > discuss any deviations on the mail list." > > and if that sounds reasonable, I'll follow up with some recipes, one > of which might be check "git --version" and upgrade to latest git to > make rebase a bit safer. > > cheers -ben > > P.S. while on the topic of disasters we can learn from, this "Disaster > 2" story [1] might be a useful read for anyone adapting from SVN. > [1] https://randyfay.com/content/avoiding-git-disasters-gory-story From btc at openinworld.com Tue Jun 28 17:45:19 2016 From: btc at openinworld.com (Ben Coman) Date: Tue Jun 28 17:45:42 2016 Subject: [Vm-dev] Should I push or request a pull? In-Reply-To: References: Message-ID: On Wed, Jun 29, 2016 at 1:38 AM, Ben Coman wrote: > On Tue, Jun 28, 2016 at 11:41 PM, Ben Coman wrote: >> On Sun, Jun 26, 2016 at 4:51 AM, Tim Felgentreff >> wrote: >>> >>> >>> Hi Ben, >>> >>> One of your arguments is about history cleaning. >>> Mostly my discouraging of rebase -i comes from experience with people who made a mistake (e.g. as simple as deleting a line and then getting "lucky" and having git not complain about conflicts during the rebase) to lose a commit entirely. And sometimes they continued working for a while, eventually a git gc was triggered, and then that commit was cleaned up and was lost for good by the time they noticed their work was gone. This happened to people around me more than just once, and then I wasn't able to help because git gc had run. Eventually I gave up and encouraged people who do not want to spend the time to really put in the work and understand how git works and what the internal structures are to not use rebase. >> >> Ah, it never cross my mind to delete a line. So I never hit the problem. So of course I had to experiment to understand properly. The log is a bit long, but maybe a handy reference... Each experiment delineated by "#====" TL;DR - check out the last two examples. #====SETUP MASTER $ mkdir testrebase && cd testrebase $ git init $ echo M >> blah ; git add blah ; git commit -m M #====NORMAL SQUASH ONLY, NO DELETES $ git checkout -b testSquashOnly master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline M 1 2 3 4 b9784f0 4 97df945 3 c57a0e6 2 77366e2 1 9b9b515 M $ git rebase -i master # in editor, change commit 2 to squash, save, exit # in second editor, change commit message to "1&2", save, exit $ cat blah ; git log --oneline M 1 2 3 4 15cbb61 4 6416fd2 3 3b00e2a 1&2 4bba92f M No changes lost. History cleaned okay. #====DELETE,ERROR,ABORT $ git checkout -b testDeleteAbort master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline # as above $ git rebase -i master # in editor, delete commit 2 line, save, exit error: could not apply 97df945... 3 When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". Could not apply 97df94529f50a597489a53bf21f25a9c270226a0... 3 # error??!! ==> panic!!! ==> abort $ cd rebase --abort $ cat blah ; git log --oneline master 1 2 3 4 b9784f0 4 97df945 3 c57a0e6 2 77366e2 1 9b9b515 master Abort on all errors is okay. #====DELETE,ERROR,EDIT,CONTINUE $ git checkout -b testDeleteMerge master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline # as above $ git rebase -i master # in editor, delete commit 2 line, save, exit error: could not apply 97df945... 3 # open editor on file blah # remove line <<<< ==== >>>> inserted by rebase, to end up with... master 1 2 3 $ git add blah; git rebase --continue [detached HEAD 1f5ed82] 3 1 file changed, 2 insertions(+) Successfully rebased and updated refs/heads/test. $ cat blah ; git log --oneline master 1 2 3 4 ef57ae0 4 1f5ed82 3 77366e2 1 9b9b515 master All changes survived, but there is a risk of losing changes if wrong lines merged in editor. #====DELETE,ERROR,CONTINUE(WITHOUT EDIT) $ git checkout -b testDeleteMerge2 master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline # as above $ git rebase -i master # in editor, delete commit 2 line, save, exit error: could not apply 97df945... 3 # note, no edit of blah $ git add blah; git rebase --continue # in editor, save, exit [detached HEAD bf742d8] 3 1 file changed, 5 insertions(+) error: could not apply 83209d3... 4 $ git add blah; git rebase --continue # in editor, save, exit [detached HEAD 42ab0c6] 4 1 file changed, 4 insertions(+) Successfully rebased and updated refs/heads/testDeleteMerge2. $ cat blah ; git log --oneline M 1 <<<<<<< HEAD ======= 2 3 <<<<<<< HEAD >>>>>>> 7176be1... 3 ======= 4 >>>>>>> 83209d3... 4 42ab0c6 4 bf742d8 3 a13429f 1 4bba92f M Urgh! No lines actually lost, but an awful mess to clean up. #====DELETE,ERROR,SKIP $ git checkout -b testDeleteSkip master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline # as above $ git rebase -i master # in editor, delete commit 2 line, save, exit error: could not apply 97df945... 3 $ git rebase --skip error: could not apply b873786... 4 $ git rebase --skip Successfully rebased and updated refs/heads/testDeleteSkip. $ cat blah ; git log --oneline M 1 fc67d5e 1 4bba92f M OUCH!! CHANGES LOST!!!! AAARRRGGHHH!! #====THE FOLLOWING REQUIRES git --version > 2.6.0 #====DELETE, missingCommitsCheck WARN $ git checkout -b testMissingCommitsCheckWarn master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline # as above $ git config rebase.missingCommitsCheck warn $ git rebase -i master # in editor, delete commit 2 line, save, exit Warning: some commits may have been dropped accidentally. Dropped commits (newer to older): - 304610b 2 To avoid this message, use "drop" to explicitly remove a commit. Use 'git config rebase.missingCommitsCheck' to change the level of warnings. The possible behaviours are: ignore, warn, error. error: could not apply a427113... 3 When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". Could not apply a427113b3137a1e585fcd04dcdd64c899fa4f163... 3 SO WITH WARN WE ARE STILL PRESENTED WITH THE CHOICE TO SKIP, ETC... #====DELETE, missingCommitsCheck ERROR $ git checkout -b testMissingCommitsCheckError master $ for N in 1 2 3 4 ; do (echo $N >> blah ; git commit -am $N) ; done $ cat blah ; git log --oneline # as above $ git config rebase.missingCommitsCheck error $ git rebase -i master # in editor, delete commit 2 line, save, exit Warning: some commits may have been dropped accidentally. Dropped commits (newer to older): - 08d9c7b 2 To avoid this message, use "drop" to explicitly remove a commit. Use 'git config rebase.missingCommitsCheck' to change the level of warnings. The possible behaviours are: ignore, warn, error. You can fix this with 'git rebase --edit-todo'. Or you can abort the rebase with 'git rebase --abort'. SO WITH ERROR WE ARE PRESENTED WITH SAFER OPTIONS cheers -ben. From eliot.miranda at gmail.com Wed Jun 29 17:00:30 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 29 17:00:32 2016 Subject: [Vm-dev] Where area the Travis-CI builds? Message-ID: Hi All, what's the URL for the Travis-CI builds and can we add a link to README.md to point to them? TIA _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/879f8de4/attachment.htm From eliot.miranda at gmail.com Wed Jun 29 17:50:24 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 29 17:50:27 2016 Subject: [Vm-dev] Urgent, .gitignore is broken and I can't commit fixes while it is. Message-ID: Hi Git mavens, make a change to any of build.linux32x86/newspeak.*/build*/mvm (i.e. changing INSTALLDIR=nscogspurlinuxhtARM to INSTALLDIR=nscogspurlinuxhtARMv7) and then say git status. No joy! I need to check in these fixes. can some kind soul who understands the .gitignore conventions fix .gitignore to not ignore at the least the mvm files three levels down in the build.linux* builds? _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/5da1a8b5/attachment.htm From Das.Linux at gmx.de Wed Jun 29 18:20:03 2016 From: Das.Linux at gmx.de (Tobias Pape) Date: Wed Jun 29 18:20:07 2016 Subject: [Vm-dev] Urgent, .gitignore is broken and I can't commit fixes while it is. In-Reply-To: References: Message-ID: <549C7823-6975-4163-8FE8-0F9DC94122BB@gmx.de> On 29.06.2016, at 19:50, Eliot Miranda wrote: > Hi Git mavens, > > make a change to any of build.linux32x86/newspeak.*/build*/mvm (i.e. changing INSTALLDIR=nscogspurlinuxhtARM to INSTALLDIR=nscogspurlinuxhtARMv7) and then say git status. No joy! > > I need to check in these fixes. can some kind soul who understands the .gitignore conventions fix .gitignore to not ignore at the least the mvm files three levels down in the build.linux* builds? quickfix/workaround: git add --force build.linux32x86/newspeak.*/build*/mvm ? > _,,,^..^,,,_ > best, Eliot From commits at source.squeak.org Wed Jun 29 19:35:19 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Jun 29 19:35:21 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1891.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1891.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1891 Author: eem Time: 29 June 2016, 12:33:32.521203 pm UUID: 496e6e75-7d9c-4299-8e65-e951b54de254 Ancestors: VMMaker.oscog-eem.1890 Simplify parameter validation in several plugins, especially the FloatArrayPlugin. stackObjectValue: checks for an object, failing if it accesses an immediate. But so do isWords:, isBytes: et al. There is no need to check twice. Further, the "interpreterProxy success: expr. ... interpreterProxy failed ifTrue: [^nil]" form contauns more calls then the "expr ifFalse: [^interpreterProxy primtiveFail]" form and so is slower. Trying the Travis infrastructure to test this for the first time. Gulp. But I'd love others to eyeball this change (and use the style in future). =============== Diff against VMMaker.oscog-eem.1890 =============== Item was changed: ----- Method: FloatArrayPlugin>>primitiveAddFloatArray (in category 'arithmetic primitives') ----- primitiveAddFloatArray "Primitive. Add the receiver and the argument, both FloatArrays and store the result into the receiver." | rcvr arg rcvrPtr argPtr length | + + + arg := interpreterProxy stackValue: 0. + rcvr := interpreterProxy stackValue: 1. + ((interpreterProxy isWords: arg) + and: [(interpreterProxy isWords: rcvr) + and: [(length := interpreterProxy stSizeOf: arg) = (interpreterProxy stSizeOf: rcvr)]]) ifFalse: + [^interpreterProxy primitiveFail]. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. + argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: #'float *'. - - - arg := interpreterProxy stackObjectValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: arg). - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. - length := interpreterProxy stSizeOf: arg. - interpreterProxy success: (length = (interpreterProxy stSizeOf: rcvr)). - interpreterProxy failed ifTrue:[^nil]. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. - argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: 'float *'. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) + (self cCoerce: (argPtr at: i) to: #double)]. - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') + (self cCoerce: (argPtr at: i) to: 'double')]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveAddScalar (in category 'arithmetic primitives') ----- primitiveAddScalar "Primitive. Add the argument, a scalar value to the receiver, a FloatArray" | rcvr rcvrPtr value length | + + - - value := interpreterProxy stackFloatValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. interpreterProxy failed ifTrue:[^nil]. + rcvr := interpreterProxy stackValue: 1. + (interpreterProxy isWords: rcvr) ifFalse: + [^interpreterProxy primitiveFail]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. length := interpreterProxy stSizeOf: rcvr. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) + value]. - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') + value]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveAt (in category 'access primitives') ----- primitiveAt | index rcvr floatValue floatPtr | + + - - index := interpreterProxy stackIntegerValue: 0. + rcvr := interpreterProxy stackValue: 1. + (interpreterProxy failed not + and: [(interpreterProxy isWords: rcvr) + and: [index > 0 and: [index <= (interpreterProxy slotSizeOf: rcvr)]]]) ifFalse: + [^interpreterProxy primitiveFail]. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy success: (index > 0 and:[index <= (interpreterProxy slotSizeOf: rcvr)]). - interpreterProxy failed ifTrue:[^nil]. floatPtr := interpreterProxy firstIndexableField: rcvr. floatValue := (floatPtr at: index-1) asFloat. interpreterProxy pop: 2. + interpreterProxy pushFloat: floatValue! - interpreterProxy pushFloat: floatValue.! Item was changed: ----- Method: FloatArrayPlugin>>primitiveAtPut (in category 'access primitives') ----- primitiveAtPut | value floatValue index rcvr floatPtr | + + - - value := interpreterProxy stackValue: 0. (interpreterProxy isIntegerObject: value) ifTrue:[floatValue := (interpreterProxy integerValueOf: value) asFloat] ifFalse:[floatValue := interpreterProxy floatValueOf: value]. index := interpreterProxy stackIntegerValue: 1. + rcvr := interpreterProxy stackValue: 2. + (interpreterProxy failed not + and: [(interpreterProxy isWords: rcvr) + and: [index > 0 and: [index <= (interpreterProxy slotSizeOf: rcvr)]]]) ifFalse: + [^interpreterProxy primitiveFail]. - rcvr := interpreterProxy stackObjectValue: 2. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy success: (index > 0 and:[index <= (interpreterProxy slotSizeOf: rcvr)]). - interpreterProxy failed ifTrue:[^nil]. floatPtr := interpreterProxy firstIndexableField: rcvr. + floatPtr at: index-1 put: (self cCoerce: floatValue to:#float). + interpreterProxy pop: 3 thenPush: value! - floatPtr at: index-1 put: (self cCoerce: floatValue to:'float'). - interpreterProxy failed ifFalse: [interpreterProxy pop: 3 thenPush: value].! Item was changed: ----- Method: FloatArrayPlugin>>primitiveDivFloatArray (in category 'arithmetic primitives') ----- primitiveDivFloatArray "Primitive. Add the receiver and the argument, both FloatArrays and store the result into the receiver." | rcvr arg rcvrPtr argPtr length | + + + arg := interpreterProxy stackValue: 0. + rcvr := interpreterProxy stackValue: 1. + ((interpreterProxy isWords: arg) + and: [(interpreterProxy isWords: rcvr) + and: [(length := interpreterProxy stSizeOf: arg) = (interpreterProxy stSizeOf: rcvr)]]) ifFalse: + [^interpreterProxy primitiveFail]. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. + argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: #'float *'. - - - arg := interpreterProxy stackObjectValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: arg). - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. - length := interpreterProxy stSizeOf: arg. - interpreterProxy success: (length = (interpreterProxy stSizeOf: rcvr)). - interpreterProxy failed ifTrue:[^nil]. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. - argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: 'float *'. "Check if any of the argument's values is zero" 0 to: length-1 do:[:i| + (interpreterProxy intAtPointer:(self cCoerce: (argPtr + i) to: #'char*')) = 0 ifTrue:[^interpreterProxy primitiveFail]]. - ( interpreterProxy intAtPointer:(self cCoerce: (argPtr + i) to: 'char*')) = 0 ifTrue:[^interpreterProxy primitiveFail]]. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) / (self cCoerce: (argPtr at: i) to: #double). - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') / (self cCoerce: (argPtr at: i) to: 'double'). ]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveDivScalar (in category 'arithmetic primitives') ----- primitiveDivScalar "Primitive. Add the argument, a scalar value to the receiver, a FloatArray" | rcvr rcvrPtr value inverse length | - + + - value := interpreterProxy stackFloatValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. interpreterProxy failed ifTrue:[^nil]. + rcvr := interpreterProxy stackValue: 1. + (interpreterProxy isWords: rcvr) ifFalse: + [^interpreterProxy primitiveFail]. - value = 0.0 ifTrue:[^interpreterProxy primitiveFail]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. length := interpreterProxy stSizeOf: rcvr. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. inverse := 1.0 / value. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) * inverse. - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') * inverse. ]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveDotProduct (in category 'arithmetic primitives') ----- primitiveDotProduct "Primitive. Compute the dot product of the receiver and the argument. The dot product is defined as the sum of the products of the individual elements." | rcvr arg rcvrPtr argPtr length result | + + + + arg := interpreterProxy stackValue: 0. + rcvr := interpreterProxy stackValue: 1. + ((interpreterProxy isWords: arg) + and: [(interpreterProxy isWords: rcvr) + and: [(length := interpreterProxy stSizeOf: arg) = (interpreterProxy stSizeOf: rcvr)]]) ifFalse: + [^interpreterProxy primitiveFail]. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. + argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: #'float *'. - - - - arg := interpreterProxy stackObjectValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: arg). - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. - length := interpreterProxy stSizeOf: arg. - interpreterProxy success: (length = (interpreterProxy stSizeOf: rcvr)). - interpreterProxy failed ifTrue:[^nil]. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. - argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: 'float *'. result := 0.0. 0 to: length-1 do:[:i| result := result + ((self cCoerce: (rcvrPtr at: i) to: 'double') * (self cCoerce: (argPtr at: i) to: 'double')). ]. interpreterProxy pop: 2. "Pop args + rcvr" interpreterProxy pushFloat: result. "Return result"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveEqual (in category 'access primitives') ----- primitiveEqual | rcvr arg rcvrPtr argPtr length | + + + arg := interpreterProxy stackValue: 0. + rcvr := interpreterProxy stackValue: 1. + ((interpreterProxy isWords: arg) + and: [(interpreterProxy isWords: rcvr)]) ifFalse: + [^interpreterProxy primitiveFail]. - - - arg := interpreterProxy stackObjectValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: arg). - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. interpreterProxy pop: 2. + (length := interpreterProxy stSizeOf: arg) = (interpreterProxy stSizeOf: rcvr) ifFalse: + [^interpreterProxy pushBool: false]. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. + argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: #'float *'. - length := interpreterProxy stSizeOf: arg. - length = (interpreterProxy stSizeOf: rcvr) ifFalse:[^interpreterProxy pushBool: false]. - - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. - argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: 'float *'. 0 to: length-1 do:[:i| (rcvrPtr at: i) = (argPtr at: i) ifFalse:[^interpreterProxy pushBool: false]. ]. ^interpreterProxy pushBool: true! Item was changed: ----- Method: FloatArrayPlugin>>primitiveHashArray (in category 'access primitives') ----- primitiveHashArray | rcvr rcvrPtr length result | + + rcvr := interpreterProxy stackValue: 0. + (interpreterProxy isWords: rcvr) ifFalse: + [^interpreterProxy primitiveFail]. - - rcvr := interpreterProxy stackObjectValue: 0. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. length := interpreterProxy stSizeOf: rcvr. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'int *'. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'int *'. result := 0. 0 to: length-1 do:[:i| result := result + (rcvrPtr at: i). ]. interpreterProxy pop: 1. ^interpreterProxy pushInteger: (result bitAnd: 16r1FFFFFFF)! Item was changed: ----- Method: FloatArrayPlugin>>primitiveMulFloatArray (in category 'arithmetic primitives') ----- primitiveMulFloatArray "Primitive. Add the receiver and the argument, both FloatArrays and store the result into the receiver." | rcvr arg rcvrPtr argPtr length | + + + arg := interpreterProxy stackValue: 0. + rcvr := interpreterProxy stackValue: 1. + ((interpreterProxy isWords: arg) + and: [(interpreterProxy isWords: rcvr) + and: [(length := interpreterProxy stSizeOf: arg) = (interpreterProxy stSizeOf: rcvr)]]) ifFalse: + [^interpreterProxy primitiveFail]. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. + argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: #'float *'. - - - arg := interpreterProxy stackObjectValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: arg). - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. - length := interpreterProxy stSizeOf: arg. - interpreterProxy success: (length = (interpreterProxy stSizeOf: rcvr)). - interpreterProxy failed ifTrue:[^nil]. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. - argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: 'float *'. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) * (self cCoerce: (argPtr at: i) to: #double). - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') * (self cCoerce: (argPtr at: i) to: 'double'). ]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveMulScalar (in category 'arithmetic primitives') ----- primitiveMulScalar "Primitive. Add the argument, a scalar value to the receiver, a FloatArray" | rcvr rcvrPtr value length | + + - - value := interpreterProxy stackFloatValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. interpreterProxy failed ifTrue:[^nil]. + rcvr := interpreterProxy stackValue: 1. + (interpreterProxy isWords: rcvr) ifFalse: + [^interpreterProxy primitiveFail]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. length := interpreterProxy stSizeOf: rcvr. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) * value. - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') * value. ]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveSubFloatArray (in category 'arithmetic primitives') ----- primitiveSubFloatArray "Primitive. Add the receiver and the argument, both FloatArrays and store the result into the receiver." | rcvr arg rcvrPtr argPtr length | + + + arg := interpreterProxy stackValue: 0. + rcvr := interpreterProxy stackValue: 1. + ((interpreterProxy isWords: arg) + and: [(interpreterProxy isWords: rcvr) + and: [(length := interpreterProxy stSizeOf: arg) = (interpreterProxy stSizeOf: rcvr)]]) ifFalse: + [^interpreterProxy primitiveFail]. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. + argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: #'float *'. - - - arg := interpreterProxy stackObjectValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: arg). - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. - length := interpreterProxy stSizeOf: arg. - interpreterProxy success: (length = (interpreterProxy stSizeOf: rcvr)). - interpreterProxy failed ifTrue:[^nil]. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. - argPtr := self cCoerce: (interpreterProxy firstIndexableField: arg) to: 'float *'. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) - (self cCoerce: (argPtr at: i) to: #double). - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') - (self cCoerce: (argPtr at: i) to: 'double'). ]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveSubScalar (in category 'arithmetic primitives') ----- primitiveSubScalar "Primitive. Add the argument, a scalar value to the receiver, a FloatArray" | rcvr rcvrPtr value length | + + - - value := interpreterProxy stackFloatValue: 0. - rcvr := interpreterProxy stackObjectValue: 1. interpreterProxy failed ifTrue:[^nil]. + rcvr := interpreterProxy stackValue: 1. + (interpreterProxy isWords: rcvr) ifFalse: + [^interpreterProxy primitiveFail]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. length := interpreterProxy stSizeOf: rcvr. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. 0 to: length-1 do:[:i| + rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: #double) - value. - rcvrPtr at: i put: (self cCoerce: (rcvrPtr at: i) to: 'double') - value. ]. interpreterProxy pop: 1. "Leave rcvr on stack"! Item was changed: ----- Method: FloatArrayPlugin>>primitiveSum (in category 'arithmetic primitives') ----- primitiveSum "Primitive. Find the sum of each float in the receiver, a FloatArray, and stash the result into the argument Float." | rcvr rcvrPtr length sum | + + + rcvr := interpreterProxy stackValue: 0. + (interpreterProxy isWords: rcvr) ifFalse: + [^interpreterProxy primitiveFail]. - - - rcvr := interpreterProxy stackObjectValue: 0. - interpreterProxy failed ifTrue:[^nil]. - interpreterProxy success: (interpreterProxy isWords: rcvr). - interpreterProxy failed ifTrue:[^nil]. length := interpreterProxy stSizeOf: rcvr. + rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: #'float *'. - rcvrPtr := self cCoerce: (interpreterProxy firstIndexableField: rcvr) to: 'float *'. sum := 0.0. 0 to: length-1 do:[:i| + sum := sum + (self cCoerce: (rcvrPtr at: i) to: #double). - sum := sum + (self cCoerce: (rcvrPtr at: i) to: 'double'). ]. interpreterProxy pop: 1 thenPush: (interpreterProxy floatObjectOf: sum)! Item was changed: ----- Method: InterpreterPrimitives>>primitiveScanCharacters (in category 'I/O primitives') ----- primitiveScanCharacters "The character scanner primitive." + | kernDelta stops sourceString scanStopIndex scanStartIndex rcvr scanDestX scanLastIndex scanXTable + scanMap maxGlyph ascii stopReason glyphIndex sourceX sourceX2 nextDestX scanRightX nilOop | - | kernDelta stops sourceString scanStopIndex scanStartIndex rcvr scanDestX scanLastIndex scanXTable scanMap maxGlyph ascii stopReason glyphIndex sourceX sourceX2 nextDestX scanRightX nilOop | self methodArgumentCount = 6 ifFalse: [^ self primitiveFail]. "Load the receiver and arguments" kernDelta := self stackIntegerValue: 0. + stops := self stackValue: 1. - stops := self stackObjectValue: 1. scanRightX := self stackIntegerValue: 2. + sourceString := self stackValue: 3. - sourceString := self stackObjectValue: 3. scanStopIndex := self stackIntegerValue: 4. scanStartIndex := self stackIntegerValue: 5. + rcvr := self stackValue: 6. - rcvr := self stackObjectValue: 6. self successful ifFalse: [^ nil]. + "check argument type and range and rcvr" + ((objectMemory isArray: stops) + and: [(objectMemory slotSizeOf: stops) >= 258 + and: [(objectMemory isBytes: sourceString) + and: [scanStartIndex > 0 + and: [scanStopIndex > 0 + and: [scanStopIndex <= (objectMemory byteSizeOf: sourceString) + and: [(objectMemory isPointers: rcvr) + and: [(objectMemory slotSizeOf: rcvr) >= 4]]]]]]]) - "check argument type and range" - (objectMemory isArray: stops) ifFalse: [^ self primitiveFail]. - (objectMemory slotSizeOf: stops) >= 258 ifFalse: [^ self primitiveFail]. - (objectMemory isBytes: sourceString) ifFalse: [^ self primitiveFail]. - (scanStartIndex > 0 and: [scanStopIndex > 0 and: [scanStopIndex <= (objectMemory byteSizeOf: sourceString)]]) ifFalse: [^ self primitiveFail]. + "Check required rcvr instVars" - "Check receiver and required instVars" - ((objectMemory isPointers: rcvr) and: [(objectMemory slotSizeOf: rcvr) >= 4]) ifFalse: [^ self primitiveFail]. scanDestX := self fetchInteger: 0 ofObject: rcvr. scanLastIndex := self fetchInteger: 1 ofObject: rcvr. scanXTable := objectMemory fetchPointer: 2 ofObject: rcvr. scanMap := objectMemory fetchPointer: 3 ofObject: rcvr. + ((objectMemory isArray: scanXTable) + and: [(objectMemory isArray: scanMap) + and: [(objectMemory slotSizeOf: scanMap) = 256 + and: [self successful "for the fetchInteger:ofObject:'s abobve"]]]) ifFalse: + [^ self primitiveFail]. - ((objectMemory isArray: scanXTable) and: [objectMemory isArray: scanMap]) ifFalse: [^ self primitiveFail]. - (objectMemory slotSizeOf: scanMap) = 256 ifFalse: [^ self primitiveFail]. - self successful ifFalse: [^ nil]. maxGlyph := (objectMemory slotSizeOf: scanXTable) - 2. "Okay, here we go. We have eliminated nearly all failure conditions, to optimize the inner fetches." scanLastIndex := scanStartIndex. nilOop := objectMemory nilObject. [scanLastIndex <= scanStopIndex] whileTrue: [ "Known to be okay since scanStartIndex > 0 and scanStopIndex <= sourceString size" ascii := objectMemory fetchByte: scanLastIndex - 1 ofObject: sourceString. "Known to be okay since stops size >= 258" (stopReason := objectMemory fetchPointer: ascii ofObject: stops) = nilOop ifFalse: ["Store everything back and get out of here since some stop conditionn needs to be checked" (objectMemory isIntegerValue: scanDestX) ifFalse: [^ self primitiveFail]. self storeInteger: 0 ofObject: rcvr withValue: scanDestX. self storeInteger: 1 ofObject: rcvr withValue: scanLastIndex. self pop: 7. "args+rcvr" ^ self push: stopReason]. "Known to be okay since scanMap size = 256" glyphIndex := self fetchInteger: ascii ofObject: scanMap. "fail if the glyphIndex is out of range" (self failed or: [glyphIndex < 0 or: [glyphIndex > maxGlyph]]) ifTrue: [^ self primitiveFail]. sourceX := self fetchInteger: glyphIndex ofObject: scanXTable. sourceX2 := self fetchInteger: glyphIndex + 1 ofObject: scanXTable. "Above may fail if non-integer entries in scanXTable" self failed ifTrue: [^ nil]. nextDestX := scanDestX + sourceX2 - sourceX. nextDestX > scanRightX ifTrue: ["Store everything back and get out of here since we got to the right edge" (objectMemory isIntegerValue: scanDestX) ifFalse: [^ self primitiveFail]. self storeInteger: 0 ofObject: rcvr withValue: scanDestX. self storeInteger: 1 ofObject: rcvr withValue: scanLastIndex. self pop: 7 "args+rcvr" thenPush: (objectMemory fetchPointer: CrossedX - 1 ofObject: stops). ^nil]. scanDestX := nextDestX + kernDelta. scanLastIndex := scanLastIndex + 1]. (objectMemory isIntegerValue: scanDestX) ifFalse: [^ self primitiveFail]. self storeInteger: 0 ofObject: rcvr withValue: scanDestX. self storeInteger: 1 ofObject: rcvr withValue: scanStopIndex. self pop: 7 "args+rcvr" thenPush: (objectMemory fetchPointer: EndOfRun - 1 ofObject: stops)! Item was changed: ----- Method: JPEGReaderPlugin>>primitiveColorConvertGrayscaleMCU (in category 'primitives') ----- primitiveColorConvertGrayscaleMCU "Requires: JPEGColorComponent bits WordArray with: 3*Integer (residuals) ditherMask " | arrayOop | self stInit. interpreterProxy methodArgumentCount = 4 ifFalse:[^interpreterProxy primitiveFail]. ditherMask := interpreterProxy stackIntegerValue: 0. - arrayOop := interpreterProxy stackObjectValue: 1. interpreterProxy failed ifTrue:[^nil]. + arrayOop := interpreterProxy stackValue: 1. ((interpreterProxy isWords: arrayOop) and:[(interpreterProxy slotSizeOf: arrayOop) = 3]) ifFalse:[^interpreterProxy primitiveFail]. residuals := interpreterProxy firstIndexableField: arrayOop. + arrayOop := interpreterProxy stackValue: 2. - arrayOop := interpreterProxy stackObjectValue: 2. - interpreterProxy failed ifTrue:[^nil]. (interpreterProxy isWords: arrayOop) ifFalse:[^interpreterProxy primitiveFail]. jpegBitsSize := interpreterProxy slotSizeOf: arrayOop. jpegBits := interpreterProxy firstIndexableField: arrayOop. + arrayOop := interpreterProxy stackValue: 3. - arrayOop := interpreterProxy stackObjectValue: 3. - interpreterProxy failed ifTrue:[^nil]. (self yColorComponentFrom: arrayOop) ifFalse:[^interpreterProxy primitiveFail]. self colorConvertGrayscaleMCU. + interpreterProxy pop: 4! - interpreterProxy pop: 4.! Item was changed: ----- Method: JPEGReaderPlugin>>primitiveColorConvertMCU (in category 'primitives') ----- primitiveColorConvertMCU "Requires: Array with: 3*JPEGColorComponent bits WordArray with: 3*Integer (residuals) ditherMask " | arrayOop | self stInit. interpreterProxy methodArgumentCount = 4 ifFalse:[^interpreterProxy primitiveFail]. ditherMask := interpreterProxy stackIntegerValue: 0. - arrayOop := interpreterProxy stackObjectValue: 1. interpreterProxy failed ifTrue:[^nil]. + arrayOop := interpreterProxy stackValue: 1. ((interpreterProxy isWords: arrayOop) and:[(interpreterProxy slotSizeOf: arrayOop) = 3]) ifFalse:[^interpreterProxy primitiveFail]. residuals := interpreterProxy firstIndexableField: arrayOop. + arrayOop := interpreterProxy stackValue: 2. - arrayOop := interpreterProxy stackObjectValue: 2. - interpreterProxy failed ifTrue:[^nil]. (interpreterProxy isWords: arrayOop) ifFalse:[^interpreterProxy primitiveFail]. jpegBitsSize := interpreterProxy slotSizeOf: arrayOop. jpegBits := interpreterProxy firstIndexableField: arrayOop. + arrayOop := interpreterProxy stackValue: 3. - arrayOop := interpreterProxy stackObjectValue: 3. - interpreterProxy failed ifTrue:[^nil]. ((interpreterProxy isPointers: arrayOop) and:[(interpreterProxy slotSizeOf: arrayOop) = 3]) ifFalse:[^interpreterProxy primitiveFail]. (self yColorComponentFrom: (interpreterProxy fetchPointer: 0 ofObject: arrayOop)) ifFalse:[^interpreterProxy primitiveFail]. (self cbColorComponentFrom: (interpreterProxy fetchPointer: 1 ofObject: arrayOop)) ifFalse:[^interpreterProxy primitiveFail]. (self crColorComponentFrom: (interpreterProxy fetchPointer: 2 ofObject: arrayOop)) ifFalse:[^interpreterProxy primitiveFail]. self colorConvertMCU. + interpreterProxy pop: 4! - interpreterProxy pop: 4.! Item was changed: ----- Method: JPEGReaderPlugin>>primitiveDecodeMCU (in category 'primitives') ----- primitiveDecodeMCU "In: anArray WordArray of: DCTSize2 aColorComponent JPEGColorComponent dcTable WordArray acTable WordArray stream JPEGStream " | arrayOop oop anArray | + - self cCode:'' inSmalltalk:[self stInit]. interpreterProxy methodArgumentCount = 5 ifFalse:[^interpreterProxy primitiveFail]. + oop := interpreterProxy stackValue: 0. - oop := interpreterProxy stackObjectValue: 0. - interpreterProxy failed ifTrue:[^nil]. (self loadJPEGStreamFrom: oop) ifFalse:[^interpreterProxy primitiveFail]. + arrayOop := interpreterProxy stackValue: 1. - arrayOop := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. (interpreterProxy isWords: arrayOop) ifFalse:[^interpreterProxy primitiveFail]. acTableSize := interpreterProxy slotSizeOf: arrayOop. acTable := interpreterProxy firstIndexableField: arrayOop. + arrayOop := interpreterProxy stackValue: 2. - arrayOop := interpreterProxy stackObjectValue: 2. - interpreterProxy failed ifTrue:[^nil]. (interpreterProxy isWords: arrayOop) ifFalse:[^interpreterProxy primitiveFail]. dcTableSize := interpreterProxy slotSizeOf: arrayOop. dcTable := interpreterProxy firstIndexableField: arrayOop. + oop := interpreterProxy stackValue: 3. - oop := interpreterProxy stackObjectValue: 3. - interpreterProxy failed ifTrue:[^nil]. (self colorComponent: yComponent from: oop) ifFalse:[^interpreterProxy primitiveFail]. + arrayOop := interpreterProxy stackValue: 4. + ((interpreterProxy isWords: arrayOop) + and: [(interpreterProxy slotSizeOf: arrayOop) = DCTSize2]) - arrayOop := interpreterProxy stackObjectValue: 4. - interpreterProxy failed ifTrue:[^nil]. - (interpreterProxy isWords: arrayOop) ifFalse:[^interpreterProxy primitiveFail]. - (interpreterProxy slotSizeOf: arrayOop) = DCTSize2 - ifFalse:[^interpreterProxy primitiveFail]. anArray := interpreterProxy firstIndexableField: arrayOop. interpreterProxy failed ifTrue:[^nil]. self decodeBlockInto: anArray component: yComponent. interpreterProxy failed ifTrue:[^nil]. self storeJPEGStreamOn: (interpreterProxy stackValue: 0). interpreterProxy storeInteger: PriorDCValueIndex ofObject: (interpreterProxy stackValue: 3) withValue: (yComponent at: PriorDCValueIndex). + interpreterProxy pop: 5! - interpreterProxy pop: 5.! Item was changed: ----- Method: JPEGReaderPlugin>>primitiveIdctInt (in category 'primitives') ----- primitiveIdctInt "In: anArray: IntegerArray new: DCTSize2 qt: IntegerArray new: DCTSize2. " | arrayOop anArray qt | + + - - self cCode:'' inSmalltalk:[self stInit]. interpreterProxy methodArgumentCount = 2 ifFalse:[^interpreterProxy primitiveFail]. + arrayOop := interpreterProxy stackValue: 0. - arrayOop := interpreterProxy stackObjectValue: 0. - interpreterProxy failed ifTrue:[^nil]. ((interpreterProxy isWords: arrayOop) and:[(interpreterProxy slotSizeOf: arrayOop) = DCTSize2]) ifFalse:[^interpreterProxy primitiveFail]. qt := interpreterProxy firstIndexableField: arrayOop. + arrayOop := interpreterProxy stackValue: 1. - arrayOop := interpreterProxy stackObjectValue: 1. - interpreterProxy failed ifTrue:[^nil]. ((interpreterProxy isWords: arrayOop) and:[(interpreterProxy slotSizeOf: arrayOop) = DCTSize2]) ifFalse:[^interpreterProxy primitiveFail]. anArray := interpreterProxy firstIndexableField: arrayOop. self idctBlockInt: anArray qt: qt. + interpreterProxy pop: 2! - interpreterProxy pop: 2.! Item was changed: ----- Method: Spur32BitMMLECoSimulator>>firstIndexableField: (in category 'object format') ----- firstIndexableField: objOop "NOTE: overridden from SpurMemoryManager to add coercion to CArray, so please duplicate any changes. There are only two important cases, both for objects with named inst vars, i.e. formats 2,3 & 5. The first indexable field for formats 2 & 5 is the slot count (by convention, even though that's off the end of the object). For 3 we must go to the class." | fmt classFormat | fmt := self formatOf: objOop. fmt <= self lastPointerFormat ifTrue: "pointer; may need to delve into the class format word" [(fmt between: self indexablePointersFormat and: self weakArrayFormat) ifTrue: [classFormat := self formatOfClass: (self fetchClassOfNonImm: objOop). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self fixedFieldsOfClassFormat: classFormat) << self shiftForWord)) to: #'oop *']. ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self numSlotsOf: objOop) << self shiftForWord)) to: #'oop *']. + "All bit objects, and indeed CompiledMethod, though this is a no-no, start at 0" - "All bit objects, and indeed CompiledMethod, though this is a non-no, start at 0" self assert: (fmt >= self sixtyFourBitIndexableFormat and: [fmt < self firstCompiledMethodFormat]). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize) to: (fmt < self firstByteFormat ifTrue: [fmt = self sixtyFourBitIndexableFormat ifTrue: ["64 bit field objects" #'long long *'] ifFalse: [fmt < self firstShortFormat ifTrue: ["32 bit field objects" #'int *'] ifFalse: ["16-bit field objects" #'short *']]] ifFalse: ["byte objects (including CompiledMethod" #'char *'])! Item was changed: ----- Method: Spur32BitMMLESimulator>>firstIndexableField: (in category 'object format') ----- firstIndexableField: objOop "NOTE: overridden from SpurMemoryManager to add coercion to CArray, so please duplicate any changes. There are only two important cases, both for objects with named inst vars, i.e. formats 2,3 & 5. The first indexable field for formats 2 & 5 is the slot count (by convention, even though that's off the end of the object). For 3 we must go to the class." | fmt classFormat | fmt := self formatOf: objOop. fmt <= self lastPointerFormat ifTrue: "pointer; may need to delve into the class format word" [(fmt between: self indexablePointersFormat and: self weakArrayFormat) ifTrue: [classFormat := self formatOfClass: (self fetchClassOfNonImm: objOop). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self fixedFieldsOfClassFormat: classFormat) << self shiftForWord)) to: #'oop *']. ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self numSlotsOf: objOop) << self shiftForWord)) to: #'oop *']. + "All bit objects, and indeed CompiledMethod, though this is a no-no, start at 0" - "All bit objects, and indeed CompiledMethod, though this is a non-no, start at 0" self assert: (fmt >= self sixtyFourBitIndexableFormat and: [fmt < self firstCompiledMethodFormat]). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize) to: (fmt < self firstByteFormat ifTrue: [fmt = self sixtyFourBitIndexableFormat ifTrue: ["64 bit field objects" #'long long *'] ifFalse: [fmt < self firstShortFormat ifTrue: ["32 bit field objects" #'int *'] ifFalse: ["16-bit field objects" #'short *']]] ifFalse: ["byte objects (including CompiledMethod" #'char *'])! Item was changed: ----- Method: Spur64BitMMLECoSimulator>>firstIndexableField: (in category 'object format') ----- firstIndexableField: objOop "NOTE: overridden from SpurMemoryManager to add coercion to CArray, so please duplicate any changes. There are only two important cases, both for objects with named inst vars, i.e. formats 2,3 & 5. The first indexable field for formats 2 & 5 is the slot count (by convention, even though that's off the end of the object). For 3 we must go to the class." | fmt classFormat | fmt := self formatOf: objOop. fmt <= self lastPointerFormat ifTrue: "pointer; may need to delve into the class format word" [(fmt between: self indexablePointersFormat and: self weakArrayFormat) ifTrue: [classFormat := self formatOfClass: (self fetchClassOfNonImm: objOop). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self fixedFieldsOfClassFormat: classFormat) << self shiftForWord)) to: #'oop *']. ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self numSlotsOf: objOop) << self shiftForWord)) to: #'oop *']. + "All bit objects, and indeed CompiledMethod, though this is a no-no, start at 0" - "All bit objects, and indeed CompiledMethod, though this is a non-no, start at 0" self assert: (fmt >= self sixtyFourBitIndexableFormat and: [fmt < self firstCompiledMethodFormat]). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize) to: (fmt < self firstByteFormat ifTrue: [fmt = self sixtyFourBitIndexableFormat ifTrue: ["64 bit field objects" #'long long *'] ifFalse: [fmt < self firstShortFormat ifTrue: ["32 bit field objects" #'int *'] ifFalse: ["16-bit field objects" #'short *']]] ifFalse: ["byte objects (including CompiledMethod" #'char *'])! Item was changed: ----- Method: Spur64BitMMLESimulator>>firstIndexableField: (in category 'object format') ----- firstIndexableField: objOop "NOTE: overridden from SpurMemoryManager to add coercion to CArray, so please duplicate any changes. There are only two important cases, both for objects with named inst vars, i.e. formats 2,3 & 5. The first indexable field for formats 2 & 5 is the slot count (by convention, even though that's off the end of the object). For 3 we must go to the class." | fmt classFormat | fmt := self formatOf: objOop. fmt <= self lastPointerFormat ifTrue: "pointer; may need to delve into the class format word" [(fmt between: self indexablePointersFormat and: self weakArrayFormat) ifTrue: [classFormat := self formatOfClass: (self fetchClassOfNonImm: objOop). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self fixedFieldsOfClassFormat: classFormat) << self shiftForWord)) to: #'oop *']. ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize + ((self numSlotsOf: objOop) << self shiftForWord)) to: #'oop *']. + "All bit objects, and indeed CompiledMethod, though this is a no-no, start at 0" - "All bit objects, and indeed CompiledMethod, though this is a non-no, start at 0" self assert: (fmt >= self sixtyFourBitIndexableFormat and: [fmt < self firstCompiledMethodFormat]). ^self cCoerce: (self pointerForOop: objOop + self baseHeaderSize) to: (fmt < self firstByteFormat ifTrue: [fmt = self sixtyFourBitIndexableFormat ifTrue: ["64 bit field objects" #'long long *'] ifFalse: [fmt < self firstShortFormat ifTrue: ["32 bit field objects" #'int *'] ifFalse: ["16-bit field objects" #'short *']]] ifFalse: ["byte objects (including CompiledMethod" #'char *'])! Item was changed: ----- Method: SpurMemoryManager>>firstIndexableField: (in category 'object format') ----- firstIndexableField: objOop "NOTE: overridden in various simulator subclasses to add coercion to CArray, so please duplicate any changes. There are only two important cases, both for objects with named inst vars, i.e. formats 2,3 & 5. The first indexable field for formats 2 & 5 is the slot count (by convention, even though that's off the end of the object). For 3 we must go to the class." | fmt classFormat | fmt := self formatOf: objOop. fmt <= self weakArrayFormat ifTrue: [fmt = self arrayFormat ifTrue: "array starts at 0." [^self pointerForOop: objOop + self baseHeaderSize]. fmt >= self indexablePointersFormat ifTrue: "indexable with inst vars; need to delve into the class format word" [classFormat := self formatOfClass: (self fetchClassOfNonImm: objOop). ^self pointerForOop: objOop + self baseHeaderSize + ((self fixedFieldsOfClassFormat: classFormat) << self shiftForWord)]. "otherwise not indexable" ^0]. + "All bit objects, and indeed CompiledMethod, though this is a no-no, start at 0" - "All bit objects, and indeed CompiledMethod, though this is a non-no, start at 0" (fmt >= self sixtyFourBitIndexableFormat and: [fmt < self firstCompiledMethodFormat]) ifTrue: [^self pointerForOop: objOop + self baseHeaderSize]. "otherwise not indexable" ^0! Item was changed: ----- Method: SqueakSSLPlugin>>primitiveAccept (in category 'primitives') ----- primitiveAccept "Primitive. Starts or continues a server handshake using the current session. Will eventually produce output to be sent to the client. Requires the host and cert name to be set for the session. Returns a code indicating the sate of the connection: > 0 - Number of bytes to be sent to the client. 0 - Success. The connection is established. -1 - More input is required. < -1 - Other errors. " | start srcLen dstLen srcOop dstOop handle srcPtr dstPtr result | + + - - interpreterProxy methodArgumentCount = 5 ifFalse:[^interpreterProxy primitiveFail]. + dstOop := interpreterProxy stackValue: 0. - dstOop := interpreterProxy stackObjectValue: 0. srcLen := interpreterProxy stackIntegerValue: 1. start := interpreterProxy stackIntegerValue: 2. + srcOop := interpreterProxy stackValue: 3. - srcOop := interpreterProxy stackObjectValue: 3. handle := interpreterProxy stackIntegerValue: 4. interpreterProxy failed ifTrue:[^nil]. ((start > 0 and:[srcLen >= 0]) and:[(interpreterProxy isBytes: srcOop) and:[(interpreterProxy isBytes: dstOop) and:[(interpreterProxy byteSizeOf: srcOop) >= (start + srcLen - 1)]]]) ifFalse:[^interpreterProxy primitiveFail]. srcPtr := interpreterProxy firstIndexableField: srcOop. dstPtr := interpreterProxy firstIndexableField: dstOop. srcPtr := srcPtr + start - 1. dstLen := interpreterProxy byteSizeOf: dstOop. result := self cCode: 'sqAcceptSSL(handle, srcPtr, srcLen, dstPtr, dstLen)' inSmalltalk:[handle. srcPtr. srcLen. dstPtr. dstLen. -2]. interpreterProxy failed ifTrue:[^nil]. interpreterProxy pop: interpreterProxy methodArgumentCount+1. interpreterProxy pushInteger: result.! Item was changed: ----- Method: SqueakSSLPlugin>>primitiveConnect (in category 'primitives') ----- primitiveConnect "Primitive. Starts or continues a client handshake using the provided data. Will eventually produce output to be sent to the server. Requires the host name to be set for the session. Returns: > 0 - Number of bytes to be sent to the server 0 - Success. The connection is established. -1 - More input is required. < -1 - Other errors. " | start srcLen dstLen srcOop dstOop handle srcPtr dstPtr result | + + - - interpreterProxy methodArgumentCount = 5 ifFalse:[^interpreterProxy primitiveFail]. + dstOop := interpreterProxy stackValue: 0. - dstOop := interpreterProxy stackObjectValue: 0. srcLen := interpreterProxy stackIntegerValue: 1. start := interpreterProxy stackIntegerValue: 2. + srcOop := interpreterProxy stackValue: 3. - srcOop := interpreterProxy stackObjectValue: 3. handle := interpreterProxy stackIntegerValue: 4. interpreterProxy failed ifTrue:[^nil]. ((start > 0 and:[srcLen >= 0]) and:[(interpreterProxy isBytes: srcOop) and:[(interpreterProxy isBytes: dstOop) and:[(interpreterProxy byteSizeOf: srcOop) >= (start + srcLen - 1)]]]) ifFalse:[^interpreterProxy primitiveFail]. srcPtr := interpreterProxy firstIndexableField: srcOop. dstPtr := interpreterProxy firstIndexableField: dstOop. srcPtr := srcPtr + start - 1. dstLen := interpreterProxy byteSizeOf: dstOop. result := self cCode: 'sqConnectSSL(handle, srcPtr, srcLen, dstPtr, dstLen)' inSmalltalk:[handle. srcPtr. srcLen. dstPtr. dstLen. -2]. interpreterProxy failed ifTrue:[^nil]. interpreterProxy pop: interpreterProxy methodArgumentCount+1. interpreterProxy pushInteger: result.! Item was changed: ----- Method: SqueakSSLPlugin>>primitiveDecrypt (in category 'primitives') ----- primitiveDecrypt "Primitive. Decrypts a buffer sent via the connection. Requires the session to be established. Returns: >=0 - Number of bytes decrypted in the result buffer < -1 - Other errors. " | start srcLen dstLen srcOop dstOop handle srcPtr dstPtr result | interpreterProxy methodArgumentCount = 5 ifFalse:[^interpreterProxy primitiveFail]. + dstOop := interpreterProxy stackValue: 0. - dstOop := interpreterProxy stackObjectValue: 0. srcLen := interpreterProxy stackIntegerValue: 1. start := interpreterProxy stackIntegerValue: 2. + srcOop := interpreterProxy stackValue: 3. - srcOop := interpreterProxy stackObjectValue: 3. handle := interpreterProxy stackIntegerValue: 4. interpreterProxy failed ifTrue:[^nil]. ((start > 0 and:[srcLen >= 0]) and:[(interpreterProxy isBytes: srcOop) and:[(interpreterProxy isBytes: dstOop) and:[(interpreterProxy byteSizeOf: srcOop) >= (start + srcLen - 1)]]]) ifFalse:[^interpreterProxy primitiveFail]. srcPtr := interpreterProxy firstIndexableField: srcOop. dstPtr := interpreterProxy firstIndexableField: dstOop. srcPtr := srcPtr + start - 1. dstLen := interpreterProxy byteSizeOf: dstOop. result := self cCode: 'sqDecryptSSL(handle, srcPtr, srcLen, dstPtr, dstLen)' inSmalltalk:[handle. srcPtr. srcLen. dstPtr. dstLen. -2]. interpreterProxy failed ifTrue:[^nil]. interpreterProxy pop: interpreterProxy methodArgumentCount+1. interpreterProxy pushInteger: result.! Item was changed: ----- Method: SqueakSSLPlugin>>primitiveEncrypt (in category 'primitives') ----- primitiveEncrypt "Primitive. Encrypts a buffer to be sent to the via the connection. Requires the session to be established. Returns: >=0 - Number of bytes encrypted in the result buffer < -1 - Other errors. " | start srcLen dstLen srcOop dstOop handle srcPtr dstPtr result | interpreterProxy methodArgumentCount = 5 ifFalse:[^interpreterProxy primitiveFail]. + dstOop := interpreterProxy stackValue: 0. - dstOop := interpreterProxy stackObjectValue: 0. srcLen := interpreterProxy stackIntegerValue: 1. start := interpreterProxy stackIntegerValue: 2. + srcOop := interpreterProxy stackValue: 3. - srcOop := interpreterProxy stackObjectValue: 3. handle := interpreterProxy stackIntegerValue: 4. interpreterProxy failed ifTrue:[^nil]. ((start > 0 and:[srcLen >= 0]) and:[(interpreterProxy isBytes: srcOop) and:[(interpreterProxy isBytes: dstOop) and:[(interpreterProxy byteSizeOf: srcOop) >= (start + srcLen - 1)]]]) ifFalse:[^interpreterProxy primitiveFail]. srcPtr := interpreterProxy firstIndexableField: srcOop. dstPtr := interpreterProxy firstIndexableField: dstOop. srcPtr := srcPtr + start - 1. dstLen := interpreterProxy byteSizeOf: dstOop. result := self cCode: 'sqEncryptSSL(handle, srcPtr, srcLen, dstPtr, dstLen)' inSmalltalk:[handle. srcPtr. srcLen. dstPtr. dstLen. -2]. interpreterProxy failed ifTrue:[^nil]. interpreterProxy pop: interpreterProxy methodArgumentCount+1. interpreterProxy pushInteger: result.! Item was changed: ----- Method: SqueakSSLPlugin>>primitiveSetStringProperty (in category 'primitives') ----- primitiveSetStringProperty "Primitive. Sets a string property for the session" | srcLen srcOop propID handle srcPtr result | interpreterProxy methodArgumentCount = 3 ifFalse:[^interpreterProxy primitiveFail]. + srcOop := interpreterProxy stackValue: 0. - srcOop := interpreterProxy stackObjectValue: 0. propID := interpreterProxy stackIntegerValue: 1. handle := interpreterProxy stackIntegerValue: 2. interpreterProxy failed ifTrue:[^nil]. (interpreterProxy isBytes: srcOop) ifFalse:[^interpreterProxy primitiveFail]. srcPtr := interpreterProxy firstIndexableField: srcOop. srcLen := interpreterProxy byteSizeOf: srcOop. result := self cCode: 'sqSetStringPropertySSL(handle, propID, srcPtr, srcLen)' inSmalltalk:[handle. srcPtr. propID. srcLen. false]. result ifFalse:[^interpreterProxy primitiveFail]. interpreterProxy failed ifTrue:[^nil]. interpreterProxy pop: interpreterProxy methodArgumentCount. ! Item was changed: ----- Method: ThreadedFFIPlugin>>ffiArgument:Spec:Class:in: (in category 'callout support') ----- ffiArgument: oop Spec: argSpec Class: argClass in: calloutState "Callout support. Prepare the given oop as argument. argSpec defines the compiled spec for the argument. argClass (if non-nil) defines the required (super)class for the argument." | valueOop oopClass isStruct nilOop | oopClass := interpreterProxy fetchClassOf: oop. "Prefetch class (we'll need it)" nilOop := interpreterProxy nilObject. "Do the necessary type checks" argClass = nilOop ifFalse:[ "Type check 1: Is the required class of the argument a subclass of ExternalStructure?" (interpreterProxy includesBehavior: argClass ThatOf: interpreterProxy classExternalStructure) ifFalse:[^FFIErrorWrongType]. "Nope. Fail." "Type check 2: Is the class of the argument a subclass of required class?" ((nilOop = oop) or:[interpreterProxy includesBehavior: oopClass ThatOf: argClass]) ifFalse:[^FFIErrorCoercionFailed]. "Nope. Fail." "Okay, we've passed the type check (so far)" ]. "Check if oopClass is a subclass of ExternalStructure. If this is the case we'll work on it's handle and not the actual oop." isStruct := false. + (oop ~= nilOop + and: [interpreterProxy isPointers: oop]) ifTrue: "#isPointers: will fail if oop is immediate so don't even attempt to use it" + [isStruct := interpreterProxy + includesBehavior: oopClass + ThatOf: interpreterProxy classExternalStructure. + (argClass = nilOop or: [isStruct]) ifFalse: + [^FFIErrorCoercionFailed]]. + "note: the test for #isPointers: above should speed up execution since no pointer type + ST objects are allowed in external calls and thus if #isPointers: is true then the arg must + be ExternalStructure to work. If it isn't then the code fails anyways so speed isn't an issue." - ((interpreterProxy isImmediate: oop) or:[oop = nilOop]) ifFalse:[ - "#isPointers: will fail if oop is immediate so don't even attempt to use it" - (interpreterProxy isPointers: oop) - ifTrue:[isStruct := interpreterProxy includesBehavior: oopClass - ThatOf: interpreterProxy classExternalStructure. - (argClass = nilOop or:[isStruct]) - ifFalse:[^FFIErrorCoercionFailed]]. - "note: the test for #isPointers: above should speed up execution since no pointer type ST objects are allowed in external calls and thus if #isPointers: is true then the arg must be ExternalStructure to work. If it isn't then the code fails anyways so speed isn't an issue" - ]. "Determine valueOop (e.g., the actual oop to pass as argument)" isStruct ifTrue:[valueOop := interpreterProxy fetchPointer: 0 ofObject: oop] ifFalse:[valueOop := oop]. "Fetch and check the contents of the compiled spec" (interpreterProxy isWords: argSpec) ifFalse:[^FFIErrorWrongType]. calloutState ffiArgSpecSize: (interpreterProxy slotSizeOf: argSpec). calloutState ffiArgSpecSize = 0 ifTrue:[^FFIErrorWrongType]. calloutState ffiArgSpec: (interpreterProxy firstIndexableField: argSpec). calloutState ffiArgHeader: (interpreterProxy longAt: calloutState ffiArgSpec). "Do the actual preparation of the argument" "Note: Order is important since FFIFlagStructure + FFIFlagPointer is used to represent 'typedef void* VoidPointer' and VoidPointer really is *struct* not pointer." (calloutState ffiArgHeader anyMask: FFIFlagStructure) ifTrue:[ "argument must be ExternalStructure" isStruct ifFalse:[^FFIErrorCoercionFailed]. (calloutState ffiArgHeader anyMask: FFIFlagAtomic) ifTrue:[^FFIErrorWrongType]. "bad combination" ^self ffiPushStructureContentsOf: valueOop in: calloutState]. (calloutState ffiArgHeader anyMask: FFIFlagPointer) ifTrue:[ "no integers (or characters) for pointers please" (interpreterProxy isImmediate: oop) ifTrue:[^FFIErrorIntAsPointer]. "but allow passing nil pointer for any pointer type" oop = nilOop ifTrue:[^self ffiPushPointer: nil in: calloutState]. "argument is reference to either atomic or structure type" (calloutState ffiArgHeader anyMask: FFIFlagAtomic) ifTrue:[ isStruct "e.g., ExternalData" ifTrue:[^self ffiAtomicStructByReference: oop Class: oopClass in: calloutState] ifFalse:[^self ffiAtomicArgByReference: oop Class: oopClass in: calloutState]. "********* NOTE: The above uses 'oop' not 'valueOop' (for ExternalData) ******" ]. "Needs to be external structure here" isStruct ifFalse:[^FFIErrorCoercionFailed]. ^self ffiPushPointerContentsOf: valueOop in: calloutState]. (calloutState ffiArgHeader anyMask: FFIFlagAtomic) ifTrue:[ "argument is atomic value" ^self ffiArgByValue: valueOop in: calloutState]. "None of the above - bad spec" ^FFIErrorWrongType! Item was changed: ----- Method: ThreadedFFIPlugin>>primitiveLogCallsTo (in category 'primitives') ----- primitiveLogCallsTo "Enable logging of FFI calls by providing it with a log file name." | logFile ok | interpreterProxy methodArgumentCount = 1 ifFalse:[^interpreterProxy primitiveFail]. + logFile := interpreterProxy stackValue: 0. - logFile := interpreterProxy stackObjectValue: 0. logFile = interpreterProxy nilObject ifTrue:[ "disable logging" ok := self ffiLogFileName: nil OfLength: 0. ok ifFalse:[^interpreterProxy primitiveFail]. ffiLogEnabled := false. ] ifFalse:[ "enable logging" (interpreterProxy isBytes: logFile) ifFalse:[^interpreterProxy primitiveFail]. ok := self ffiLogFileName: (interpreterProxy firstIndexableField: logFile) OfLength: (interpreterProxy byteSizeOf: logFile). ok ifFalse:[^interpreterProxy primitiveFail]. ffiLogEnabled := true. ]. ^interpreterProxy pop: 1. "pop arg; return rcvr" ! Item was changed: ----- Method: UUIDPlugin>>primitiveMakeUUID (in category 'system primitives') ----- primitiveMakeUUID | oop location | + + oop := interpreterProxy stackValue: 0. + (interpreterProxy methodArgumentCount = 0 + and: [(interpreterProxy isBytes: oop) + and: [(interpreterProxy byteSizeOf: oop) = 16]]) ifFalse: - - oop := interpreterProxy stackObjectValue: 0. - (interpreterProxy failed - or: [interpreterProxy methodArgumentCount ~= 0 - or: [(interpreterProxy isBytes: oop) not - or: [(interpreterProxy byteSizeOf: oop) ~= 16]]]) ifTrue: [^interpreterProxy primitiveFail]. location := interpreterProxy firstIndexableField: oop. self cCode: [self MakeUUID: location] inSmalltalk: [| uuid | uuid := UUID new. 1 to: 16 do: [:i| location at: i - 1 put: (uuid at: i)]]. ^oop! From lists at fniephaus.com Wed Jun 29 19:58:24 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed Jun 29 19:58:38 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: pasted1 Type: image/png Size: 256813 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/6751abc6/pasted1-0001.png From lists at fniephaus.com Wed Jun 29 20:00:38 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed Jun 29 20:00:50 2016 Subject: [Vm-dev] Where area the Travis-CI builds? In-Reply-To: References: Message-ID: Hi Eliot, The (hopefully green) "build passing" badge in our README.md [1] is the Travis CI badge and already links to our builds. There also is a similar badge to our Windows builds on AppVeyor. Cheers, Fabio [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/README.md -- On Wed, Jun 29, 2016 at 7:00 PM Eliot Miranda wrote: > > Hi All, > > what's the URL for the Travis-CI builds and can we add a link to > README.md to point to them? TIA > > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/9b7baa88/attachment.htm From lists at fniephaus.com Wed Jun 29 20:05:25 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed Jun 29 20:05:39 2016 Subject: [Vm-dev] Urgent, .gitignore is broken and I can't commit fixes while it is. In-Reply-To: <549C7823-6975-4163-8FE8-0F9DC94122BB@gmx.de> References: <549C7823-6975-4163-8FE8-0F9DC94122BB@gmx.de> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: pasted1 Type: image/png Size: 75597 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/ba81fc8b/pasted1-0001.png From tim at rowledge.org Wed Jun 29 20:24:24 2016 From: tim at rowledge.org (tim Rowledge) Date: Wed Jun 29 20:24:02 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: References: <1466501703.2453.6.camel@gmail.com> <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> Message-ID: <5EF8A2E4-6AFE-4929-93B3-0C6023FFDAF8@rowledge.org> > On 29-06-2016, at 12:58 PM, Fabio Niephaus wrote: > > Hi all, > > We have just renamed the repository to "opensmalltalk-vm". > Please update your local Git repositories with the following: > > git remote set-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git So for those of us attempting to make sense of this within the recommended ?SourceTree? I think this must be a) Repository Settings -> tab ?remotes? b) click on ?origin? ^ ?Edit? c) change https://github.com/OpenSmalltalk/vm.git to https://github.com/OpenSmalltalk/opensmalltalk-vm.git Yes? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CBA: Compare if Biorhythms Amenable From tim at rowledge.org Wed Jun 29 20:44:16 2016 From: tim at rowledge.org (tim Rowledge) Date: Wed Jun 29 20:43:55 2016 Subject: [Vm-dev] git build problem on Pi In-Reply-To: References: <6F2162CF-5F8E-48D7-8ADE-5626A0796F83@rowledge.org> Message-ID: <00ADE42F-69D1-4146-ACFC-6093B02562C9@rowledge.org> > On 25-06-2016, at 7:55 AM, Damien Pollet wrote: > > On 24 June 2016 at 19:40, tim Rowledge wrote: > I have the .git directory but it contains no ?hooks? directory. > > You can create it when needed; I believe it gets created or not depending on your git version or based on some template, and when it does it only contains example files that do nothing. > > In this case, whatever script that tries to cp stuff into it could just do mkdir -p beforehand to ensure the directory is there. It looks to me that the ./scripts/updateSCCSVersions is doing exactly that and yet failed to make the .git/hooks directory And now running it days later it actually makes the hooks directory. Maybe it got updated since I last tried? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number From lists at fniephaus.com Wed Jun 29 20:44:27 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Wed Jun 29 20:44:40 2016 Subject: [Vm-dev] Why OpenSmalltalk/vm not googlable and not searchable on GitHub? In-Reply-To: <5EF8A2E4-6AFE-4929-93B3-0C6023FFDAF8@rowledge.org> References: <1466501703.2453.6.camel@gmail.com> <40BA1C9D-8076-41AF-8BA2-76D2EA405561@gmail.com> <5EF8A2E4-6AFE-4929-93B3-0C6023FFDAF8@rowledge.org> Message-ID: Yes, sounds good! Thanks On Wed, 29 Jun 2016 at 22:24, tim Rowledge wrote: > > > > On 29-06-2016, at 12:58 PM, Fabio Niephaus wrote: > > > > Hi all, > > > > We have just renamed the repository to "opensmalltalk-vm". > > Please update your local Git repositories with the following: > > > > git remote set-url origin > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > So for those of us attempting to make sense of this within the recommended > ?SourceTree? I think this must be > a) Repository Settings -> tab ?remotes? > b) click on ?origin? ^ ?Edit? > c) change https://github.com/OpenSmalltalk/vm.git to > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > Yes? > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: CBA: Compare if Biorhythms Amenable > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/ddd26880/attachment.htm From eliot.miranda at gmail.com Wed Jun 29 22:55:22 2016 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Jun 29 22:55:25 2016 Subject: [Vm-dev] Urgent, .gitignore is broken and I can't commit fixes while it is. In-Reply-To: References: <549C7823-6975-4163-8FE8-0F9DC94122BB@gmx.de> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: pasted1 Type: image/png Size: 75597 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160629/ed5cd89d/pasted1-0001.png From commits at source.squeak.org Thu Jun 30 00:00:46 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Jun 30 00:00:47 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1892.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1892.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1892 Author: eem Time: 29 June 2016, 4:59:05.109418 pm UUID: 51671a87-df9b-49c2-8972-b9fe8eb0cf5f Ancestors: VMMaker.oscog-eem.1891 Fix assert failure in primitiveVoidVMStateForMethod. The instructrionPointer must be pushed after the frame is married. In 1892 the Liverpool Football Club is founded by John Houlding, the owner of Anfield. Houlding decides to form his own team after Everton leaves Anfield in an argument over rent. =============== Diff against VMMaker.oscog-eem.1891 =============== Item was changed: ----- Method: CoInterpreterPrimitives>>primitiveVoidVMStateForMethod (in category 'system control primitives') ----- primitiveVoidVMStateForMethod "The receiver is a compiledMethod. Clear all VM state associated with the method, including any machine code, or machine code pcs in context objects." | activeContext methodObj hasCogMethod theFrame thePage | super primitiveFlushCacheByMethod. "One might think (as this author did) that the heap scan is unnecessary if the method does not have a cog method. But it could be the case that the code zone has recently been reclaimed and so not having a cog method is no indication that it didn't have a cog method some time in the recent past, and that there are indeed still contexts with machine code pcs out there. The only steps that can be avoided is divorcing frames in the stack zone, and scanning to unlink and free if there isn't a cog method." methodObj := self stackTop. + activeContext := self ensureFrameIsMarried: framePointer SP: stackPointer. + self ensurePushedInstructionPointer. - self push: instructionPointer. self externalWriteBackHeadFramePointers. - activeContext := self ensureFrameIsMarried: framePointer SP: stackPointer - objectMemory wordSize. (hasCogMethod := self methodHasCogMethod: methodObj) ifTrue: [self divorceMachineCodeFramesWithMethod: methodObj]. self ensureAllContextsWithMethodHaveBytecodePCs: methodObj. hasCogMethod ifTrue: [cogit unlinkSendsTo: methodObj andFreeIf: true]. (self isStillMarriedContext: activeContext) ifTrue: [theFrame := self frameOfMarriedContext: activeContext. thePage := stackPages stackPageFor: theFrame. self assert: thePage headFP = theFrame. self setStackPageAndLimit: thePage. stackPointer := thePage headSP. framePointer := thePage headFP. instructionPointer := self popStack. self assert: methodObj = self stackTop] ifFalse: [self zeroStackPage. "to avoid assert in marryContextInNewStackPageAndInitializeInterpreterRegisters:" self marryContextInNewStackPageAndInitializeInterpreterRegisters: activeContext. self popStack. "pop bogus machine-code instructionPointer" self assert: methodObj = self stackTop. self siglong: reenterInterpreter jmp: ReturnToInterpreter]! From commits at source.squeak.org Thu Jun 30 00:37:15 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Jun 30 00:37:17 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1893.mcz Message-ID: Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1893.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1893 Author: eem Time: 29 June 2016, 5:35:30.7422 pm UUID: ed498bfa-0631-4cf2-8bfb-c49e20505d40 Ancestors: VMMaker.oscog-eem.1892 Fix a couple of cases that should use mositiveMachineIntegerValue: and nuke an unnecessary stackObjectValue:. In 1893: Riots of Mons during the Belgian general strike of 1893, The day after, Belgian parliament approved Universal suffrage. The Independent Labour Party of the United Kingdom has its first meeting. The United States overthrows the Kingdom of Hawaii: Lorrin A. Thurston and the Citizen's Committee of Public Safety in Hawaii with the intervention of the United States Marine Corps overthrow the government of Queen Liliuokalani. =============== Diff against VMMaker.oscog-eem.1892 =============== Item was changed: ----- Method: IA32ABIPlugin>>primBoxedFree (in category 'primitives-memory management') ----- primBoxedFree "Free the memory referenced by the receiver, an Alien." "proxy primFree ^ " | addr rcvr ptr sizeField | + rcvr := interpreterProxy stackValue: 0. - rcvr := interpreterProxy stackObjectValue: 0. (interpreterProxy byteSizeOf: rcvr) >= (2 * interpreterProxy bytesPerOop) ifFalse: [^interpreterProxy primitiveFailFor: PrimErrBadReceiver]. ptr := interpreterProxy firstIndexableField: rcvr. sizeField := ptr at: 0. addr := ptr at: 1. "Don't you dare to free Squeak's memory!!" (sizeField >= 0 or: [addr = 0 or: [interpreterProxy isInMemory: addr]]) ifTrue: [^interpreterProxy primitiveFailFor: PrimErrInappropriate]. self cCode: 'free((void *)addr)' inSmalltalk: [self Cfree: addr]. ptr at: 0 put: 0; at: 1 put: 0 "cleanup"! Item was changed: ----- Method: IA32ABIPlugin>>primFree (in category 'primitives-memory management') ----- primFree "Free the memory referenced by the argument, an integer." " primFree: address " | addr | + addr := interpreterProxy stackPositiveMachineIntegerValue: 0. - addr := interpreterProxy positive32BitValueOf: (interpreterProxy stackValue: 0). interpreterProxy failed ifTrue: [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. "Don't you dare to free Squeak's memory!!" (addr = 0 or: [interpreterProxy isInMemory: addr]) ifTrue: [^interpreterProxy primitiveFailFor: PrimErrInappropriate]. self cCode: 'free((void *)addr)' inSmalltalk: [self Cfree: addr]. interpreterProxy pop: 1! Item was changed: ----- Method: IA32ABIPlugin>>primReturnFromContextThrough (in category 'primitives-callbacks') ----- primReturnFromContextThrough "Return a result from a callback to the callback's callee. The primitive has a signature of either of the forms: result primReturnFromContext: callbackContext through: jmpBuf result primSignal: aSemaphore andReturnFromContext: callbackContext through: jmpBuf . If of the second form answer true if this is not the most recent callback, and signal aSemaphore if it is, so as to implement LIFO ordering of callbacks." | mac vmCallbackContext vmCallbackReturnValue isMostRecent | + vmCallbackContext := self cCoerceSimple: (interpreterProxy positiveMachineIntegerValueOf: (interpreterProxy stackValue: 0)) - vmCallbackContext := self cCoerceSimple: (interpreterProxy positive32BitValueOf: (interpreterProxy stackValue: 0)) to: #'VMCallbackContext *'. (interpreterProxy failed or: [vmCallbackContext = 0]) ifTrue: [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. (mac := interpreterProxy methodArgumentCount) = 3 ifTrue: [isMostRecent := vmCallbackContext = self getMostRecentCallbackContext. isMostRecent ifFalse: [interpreterProxy methodReturnValue: interpreterProxy trueObject. ^nil]. (interpreterProxy fetchClassOf: (interpreterProxy stackValue: 2)) = interpreterProxy classSemaphore ifFalse: [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. [interpreterProxy signalNoResume: (interpreterProxy stackValue: 2)] whileFalse]. vmCallbackReturnValue := self cCoerceSimple: (self startOfData: (interpreterProxy stackValue: mac)) to: #'VMCallbackReturnValue *'. self cCode: "C needs a typedef for structs to be assigned, but that implies a struct class for just one assignment." [self mem: (self addressOf: vmCallbackContext rvs) cp: (self addressOf: vmCallbackReturnValue crvrvs) y: (self sizeof: vmCallbackContext rvs)] inSmalltalk: [vmCallbackContext rvs: vmCallbackReturnValue crvrvs]. (interpreterProxy returnAs: (interpreterProxy integerObjectOf: vmCallbackReturnValue type + 1) ThroughCallback: vmCallbackContext Context: (interpreterProxy stackValue: 1)) ifFalse: [^interpreterProxy primitiveFailFor: PrimErrBadArgument]. "NOTREACHED"! From btc at openinworld.com Thu Jun 30 01:22:59 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 30 01:23:22 2016 Subject: [Vm-dev] Malloc Benchmarking Message-ID: I haven't worked out quite how to read this, but as a low-level benchmark thought it might be of random interest... http://highlandsun.com/hyc/malloc/ cheers -ben From btc at openinworld.com Thu Jun 30 05:01:16 2016 From: btc at openinworld.com (Ben Coman) Date: Thu Jun 30 05:01:39 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-eem.1893.mcz In-Reply-To: <577469bf.c21c620a.3deaa.4d58SMTPIN_ADDED_MISSING@mx.google.com> References: <577469bf.c21c620a.3deaa.4d58SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Jun 30, 2016 at 8:36 AM, wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1893.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.1893 > Author: eem > Time: 29 June 2016, 5:35:30.7422 pm > UUID: ed498bfa-0631-4cf2-8bfb-c49e20505d40 > Ancestors: VMMaker.oscog-eem.1892 > > Fix a couple of cases that should use mositiveMachineIntegerValue I didn't realise you had such close ties to this US Military project... http://www.snopes.com/photos/technology/insectdrone.asp Of course with git, you might do a "commit --amend" if you noticed this before pushing to the server ;) except we'd then be denied an occasional chuckle. cheers -ben From yuriy.tymchuk at me.com Thu Jun 30 08:28:27 2016 From: yuriy.tymchuk at me.com (Yuriy Tymchuk) Date: Thu Jun 30 08:28:34 2016 Subject: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready In-Reply-To: References: <5756949A.9010307@gmail.com> <5757CAFB.9060407@gmail.com> Message-ID: <38816887-4C4D-4985-BDE1-0F17911FDD79@me.com> Maybe I will find some time to hack the tree-matching rules to highlight the matched piece of code. It?s so frustrating that they don?t do it? Uko > On 30 Jun 2016, at 10:17, Marcus Denker wrote: > > > > > finalizationProcess > "The finalization process arranges to send mourn to each element of the VM's finalization queue, > which is accessed via primitiveFetchMourner. The VM signals FinalizationSemaphore whenever > the queue is non-empty. This process loops, waiting on the semaphore, fetches the first element > of the queue and then spawns a process at a higher priority to acually send the mourn messages. > If an error occurs in the higher priority mourn loop process then this process will simply spawn > another process, hence ensuring that errors in finalization methods don't break finalization. > > In addition this process also runs the old finalization scheme, supporting clients of the older, > WeakRegistry based scheme. Hopefully this will go away when all cleints have moved over." > | throttle firstMourner | > throttle := Semaphore new. > [FinalizationSemaphore wait; initSignals. > "Support the old scheme until things have changed over..." > self doOldFinalization. > [firstMourner := self primitiveFetchMourner. > firstMourner notNil] whileTrue: > [[throttle signal. > self mournLoopWith: firstMourner] forkAt: Processor activePriority + 1. > throttle wait]] > > Doh! So I wrote a naked block, not a loop !! So it did nothing. Thank you!! I think the compiler should warn about naked blocks. > > > I added a new Code-Critic rule "RBDeadBlockRule", with > > initialize > super initialize. > self matcher > matches: '`{:node | node isBlock and: [node parent isSequence > and: [ node isLastStatementInBlock not ]]}' > do: [ :node :answer | node ] > > This now shows a warning in the tools (the explanation is shown when clicking on the ? button): > It does not yet highlight the block and has no automatic transformation to fix the problem, but as > a first step it should be nice to have. > > > > > This is in 60 update 126. > > (I did not read the mail again before doing it, so now it is called "dead", not "naked", we can change > that... dead somehow makes it look to be related a "dead context"...). > > Marcus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160630/f587a7ac/attachment.htm From bert at freudenbergs.de Thu Jun 30 09:50:35 2016 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Jun 30 09:50:37 2016 Subject: [Vm-dev] [OT] git gui (was: Why OpenSmalltalk/vm not googlable) Message-ID: On Wed, Jun 29, 2016 at 10:24 PM, tim Rowledge wrote: > the recommended ?SourceTree? > How do you like that app? I'm using Github's own app (https://desktop.github.com/) but I'm not a newbie, doing git on the command line often too. - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160630/173fb022/attachment-0001.htm From estebanlm at gmail.com Thu Jun 30 09:56:07 2016 From: estebanlm at gmail.com (Esteban Lorenzano) Date: Thu Jun 30 09:56:11 2016 Subject: [Vm-dev] [OT] git gui (was: Why OpenSmalltalk/vm not googlable) In-Reply-To: References: Message-ID: <821FE51F-8E1F-4804-9C27-E7A0B1110FD5@gmail.com> > On 30 Jun 2016, at 11:50, Bert Freudenberg wrote: > > On Wed, Jun 29, 2016 at 10:24 PM, tim Rowledge > wrote: > the recommended ?SourceTree? > > How do you like that app? > > I'm using Github's own app (https://desktop.github.com/ ) but I'm not a newbie, doing git on the command line often too. I tried github app and didn?t like it a lot? I?m happy with SourceTree :) Esteban > > - Bert - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160630/17777781/attachment.htm From nicolas.cellier.aka.nice at gmail.com Thu Jun 30 09:57:48 2016 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Thu Jun 30 09:57:51 2016 Subject: [Vm-dev] [OT] git gui (was: Why OpenSmalltalk/vm not googlable) In-Reply-To: <821FE51F-8E1F-4804-9C27-E7A0B1110FD5@gmail.com> References: <821FE51F-8E1F-4804-9C27-E7A0B1110FD5@gmail.com> Message-ID: 2016-06-30 11:56 GMT+02:00 Esteban Lorenzano : > > > On 30 Jun 2016, at 11:50, Bert Freudenberg wrote: > > On Wed, Jun 29, 2016 at 10:24 PM, tim Rowledge wrote: > >> the recommended ?SourceTree? >> > > How do you like that app? > > I'm using Github's own app (https://desktop.github.com/) but I'm not a > newbie, doing git on the command line often too. > > > I tried github app and didn?t like it a lot? I?m happy with SourceTree :) > > Esteban > > +1 for Sourcetree, mostly intuitive, and all the power of git thru the Terminal > > - Bert - > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160630/13f232aa/attachment.htm From lists at fniephaus.com Thu Jun 30 11:22:02 2016 From: lists at fniephaus.com (Fabio Niephaus) Date: Thu Jun 30 11:22:14 2016 Subject: [Vm-dev] [OT] git gui (was: Why OpenSmalltalk/vm not googlable) In-Reply-To: References: <821FE51F-8E1F-4804-9C27-E7A0B1110FD5@gmail.com> Message-ID: +1 for Sourcetree. Some features were missing in the GitHub client the last time I used it. Sourcetree is much more mature I'd say. -- On Thu, Jun 30, 2016 at 11:57 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote: > 2016-06-30 11:56 GMT+02:00 Esteban Lorenzano : > >> >> >> On 30 Jun 2016, at 11:50, Bert Freudenberg wrote: >> >> On Wed, Jun 29, 2016 at 10:24 PM, tim Rowledge wrote: >> >>> the recommended ?SourceTree? >>> >> >> How do you like that app? >> >> I'm using Github's own app (https://desktop.github.com/) but I'm not a >> newbie, doing git on the command line often too. >> >> >> I tried github app and didn?t like it a lot? I?m happy with SourceTree :) >> >> Esteban >> >> > +1 for Sourcetree, mostly intuitive, and all the power of git thru the > Terminal > >> >> - Bert - >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160630/85772d2b/attachment.htm From commits at source.squeak.org Thu Jun 30 12:03:49 2016 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Jun 30 12:03:50 2016 Subject: [Vm-dev] VM Maker: VMMaker.oscog-cb.1894.mcz Message-ID: ClementBera uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-cb.1894.mcz ==================== Summary ==================== Name: VMMaker.oscog-cb.1894 Author: cb Time: 30 June 2016, 2:02:37.049787 pm UUID: b3c32cc0-576b-4a14-9572-b5323dfa774f Ancestors: VMMaker.oscog-eem.1893 Accesses on remote instance variables can't be done on forwarders: to happen, the method with the inst var access needs to be inlined hence there's either a guard ensuring the object is not a forwarder or the type of the object is known (immutable literal, inlined object allocation such as Array, FullBlockClosure, immediate rcvr, etc.) =============== Diff against VMMaker.oscog-eem.1893 =============== Item was added: + ----- Method: StackToRegisterMappingCogit>>genLoadTemp:in: (in category 'bytecode generator support') ----- + genLoadTemp: objectIndex in: destReg + destReg = ReceiverResultReg ifTrue: [ optStatus isReceiverResultRegLive: false ]. + self ssAllocateRequiredReg: destReg. + self MoveMw: (self frameOffsetOfTemporary: objectIndex) r: FPReg R: destReg.! Item was removed: - ----- Method: StackToRegisterMappingCogit>>genLoadUnFwdTemp:in: (in category 'bytecode generator support') ----- - genLoadUnFwdTemp: objectIndex in: destReg - destReg = ReceiverResultReg ifTrue: [ optStatus isReceiverResultRegLive: false ]. - self ssAllocateRequiredReg: destReg. - self MoveMw: (self frameOffsetOfTemporary: objectIndex) r: FPReg R: destReg. - objectRepresentation - genEnsureOopInRegNotForwarded: destReg - scratchReg: TempReg.! Item was changed: ----- Method: StackToRegisterMappingCogit>>genPushMaybeContextRemoteInstVar:inObjectAt: (in category 'bytecode generator support') ----- genPushMaybeContextRemoteInstVar: slotIndex inObjectAt: index self ssAllocateCallReg: ReceiverResultReg and: SendNumArgsReg. + self genLoadTemp: index in: ReceiverResultReg. - self genLoadUnFwdTemp: index in: ReceiverResultReg. ^ self genPushMaybeContextSlotIndex: slotIndex! Item was changed: ----- Method: StackToRegisterMappingCogit>>genPushRemoteInstVar:inObjectAt: (in category 'bytecode generator support') ----- genPushRemoteInstVar: index inObjectAt: objectIndex | objectReg resultReg | self assert: needsFrame. objectReg := self allocateRegNotConflictingWith: 0. + self genLoadTemp: objectIndex in: objectReg. - self genLoadUnFwdTemp: objectIndex in: objectReg. resultReg := self availableRegOrNoneNotConflictingWith: (self registerMaskFor: objectReg). resultReg = NoReg ifTrue: [resultReg := objectReg]. objectRepresentation genLoadSlot: byte1 sourceReg: objectReg destReg: resultReg. ^self ssPushRegister: resultReg! Item was changed: ----- Method: StackToRegisterMappingCogit>>genStorePop:MaybeContextRemoteInstVar:ofObjectAt:needsStoreCheck: (in category 'bytecode generator support') ----- genStorePop: popBoolean MaybeContextRemoteInstVar: slotIndex ofObjectAt: objectIndex needsStoreCheck: needsStoreCheck "The reason we need a frame here is that assigning to an inst var of a context may involve wholesale reorganization of stack pages, and the only way to preserve the execution state of an activation in that case is if it has a frame." self assert: needsFrame. + self genLoadTemp: objectIndex in: ReceiverResultReg. - self genLoadUnFwdTemp: objectIndex in: ReceiverResultReg. self genStorePop: popBoolean MaybeContextSlotIndex: slotIndex needsStoreCheck: needsStoreCheck. ^ 0! Item was changed: ----- Method: StackToRegisterMappingCogit>>genStorePop:RemoteInstVar:ofObjectAt:needsStoreCheck: (in category 'bytecode generator support') ----- genStorePop: popBoolean RemoteInstVar: slotIndex ofObjectAt: objectIndex needsStoreCheck: needsStoreCheck self assert: needsFrame. + self genLoadTemp: objectIndex in: ReceiverResultReg. - self genLoadUnFwdTemp: objectIndex in: ReceiverResultReg. self genStorePop: popBoolean slotIndex: slotIndex destReg: ReceiverResultReg needsStoreCheck: needsStoreCheck needsRestoreRcvr: false. ^ 0! From tim at rowledge.org Thu Jun 30 17:32:20 2016 From: tim at rowledge.org (tim Rowledge) Date: Thu Jun 30 17:31:57 2016 Subject: [Vm-dev] [OT] git gui (was: Why OpenSmalltalk/vm not googlable) In-Reply-To: References: Message-ID: <3C1976D4-34AF-415C-8A31-D981A9B05F47@rowledge.org> > On 30-06-2016, at 2:50 AM, Bert Freudenberg wrote: > > On Wed, Jun 29, 2016 at 10:24 PM, tim Rowledge wrote: > the recommended ?SourceTree? > > How do you like that app? So far I find it utterly incomprehensible; not especially because of any fault in the app but because none of the git stuff makes any sense yet. I?ve had no time to read any doc about it. > > I'm using Github's own app (https://desktop.github.com/) but I'm not a newbie, doing git on the command line often too. I?ve used that, but purely as a way to upload test Scratch versions etc to the raspberrypi archive. As far as I could make out that was pretty much all it could do. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Airline Food