February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3708 in pharo: Selection text color enh

by pharo＠googlecode.com

Updates: Cc: gazzaguru2 tudor.girba Benjamin.VanRyseghem.Pharo Comment #1 on issue 3708 by aplan...(a)gmail.com: Selection text color enh http://code.google.com/p/pharo/issues/detail?id=3708 SLICE-Issue-3708-Selection-text-color-enh in Inbox Attachments: selectionTextColor.png 156 KB

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Eliot Miranda

On Tue, Feb 15, 2011 at 1:10 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/2/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Tue, Feb 15, 2011 at 12:39 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> Eliot > >> > >> I can understand that well. Now we could just let this code in VMMaker > and > >> not inlining. > >> We fix 8 users and we are done. I have concerned that we have a complex > >> solution because it is complex > >> for a couple of use case. Of course we can do nothing (and we will > >> probably not do it now) but in that case we can > >> also stop pharo right now because a large part of the system could > follow > >> the exact same principle. > > > > That's a false distinction. There's nothing wrong with caseOf: and not > > addressing it will not leave Pharo any the worse. Case statements are > not > > in themselves evil in the right context. The main problems with the > > index/dictionary approach are that > > a) the solution is no longer contained in a single method > > b) the dictionary is metadata that needs to be updated in an initialize > > method; forget to initialize the dictionary when an index changes and > your > > program is broken. > > As my first wife said "don't sweat the petty stuff; pet the sweaty > stuff". > > > > BTW, there's a false assumption that has been stated in this thread that > the > > caseOf: statement is only used with explicit integers. It can be used > with > > anything. Expressions, class constants etc. > >> > >> BTW why marcus and jorge work on Opal because the compiler is just > working > >> good? > >> > >> Now I will focus on 1.2, FS, Opal if I can help, and the rest but > caseOf: > >> will be in our radar. > >> > >> Just a remark if people would have spend the time to write mail to fix > the > >> users of caseof: in the image and > >> other non VMmaker package we would have get already done. > > > > Fix this (rhetorical - I think this is /much/ better as a single case > > statement than as an index/dictionary refactoring, both in Smalltalk and > > when translated to C): > > CogIA32Compiler>>computeMaximumSize > > "Compute the maximum size for each opcode. This allows jump offsets to > > be determined, provided that all backward branches are long branches." > > "N.B. The ^maxSize := N forms are to get around the compiler's long > branch > > limits which are exceeded when each case jumps around the otherwise." > > opcode caseOf: { > > "Noops & Pseudo Ops" > > [Label] -> [^maxSize := 0]. > > [AlignmentNops] -> [^maxSize := (operands at: 0) - 1]. > > [Fill16] -> [^maxSize := 2]. > > [Fill32] -> [^maxSize := 4]. > > [FillFromWord] -> [^maxSize := 4]. > > [Nop] -> [^maxSize := 1]. > > "Specific Control/Data Movement" > > [CDQ] -> [^maxSize := 1]. > > [IDIVR] -> [^maxSize := 2]. > > [IMULRR] -> [^maxSize := 3]. > > [CPUID] -> [^maxSize := 2]. > > [CMPXCHGAwR] -> [^maxSize := 7]. > > [CMPXCHGMwrR] -> [^maxSize := 8]. > > [LFENCE] -> [^maxSize := 3]. > > [MFENCE] -> [^maxSize := 3]. > > [SFENCE] -> [^maxSize := 3]. > > [LOCK] -> [^maxSize := 1]. > > [XCHGAwR] -> [^maxSize := 6]. > > [XCHGMwrR] -> [^maxSize := 7]. > > [XCHGRR] -> [^maxSize := 2]. > > "Control" > > [Call] -> [^maxSize := 5]. > > [JumpR] -> [^maxSize := 2]. > > [Jump] -> [self resolveJumpTarget. ^maxSize := 5]. > > [JumpLong] -> [self resolveJumpTarget. ^maxSize := 5]. > > [JumpZero] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpNegative] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpNonNegative] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpNoOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpCarry] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpNoCarry] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpLess] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpGreater] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpBelow] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpAboveOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpAbove] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpBelowOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpLongZero] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpLongNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPNotEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPLess] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPGreater] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPOrdered] -> [self resolveJumpTarget. ^maxSize := 6]. > > [JumpFPUnordered] -> [self resolveJumpTarget. ^maxSize := 6]. > > [RetN] -> [^maxSize := (operands at: 0) = 0 > > ifTrue: [1] > > ifFalse: [3]]. > > "Arithmetic" > > [AddCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]]. > > [AndCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]]. > > [CmpCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]]. > > [OrCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]]. > > [SubCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]]. > > [AddCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]. > > [CmpCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]. > > [SubCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]. > > [XorCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]. > > [AddRR] -> [^maxSize := 2]. > > [AndRR] -> [^maxSize := 2]. > > [CmpRR] -> [^maxSize := 2]. > > [OrRR] -> [^maxSize := 2]. > > [XorRR] -> [^maxSize := 2]. > > [SubRR] -> [^maxSize := 2]. > > [NegateR] -> [^maxSize := 2]. > > [LoadEffectiveAddressMwrR] > > -> [^maxSize := ((self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [6]) > > + ((self concreteRegister: (operands at: 1)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [LogicalShiftLeftCqR] -> [^maxSize := (operands at: 0) = 1 > > ifTrue: [2] > > ifFalse: [3]]. > > [LogicalShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 > > ifTrue: [2] > > ifFalse: [3]]. > > [ArithmeticShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 > > ifTrue: [2] > > ifFalse: [3]]. > > [LogicalShiftLeftRR] -> [self computeShiftRRSize]. > > [LogicalShiftRightRR] -> [self computeShiftRRSize]. > > [ArithmeticShiftRightRR] -> [self computeShiftRRSize]. > > [AddRdRd] -> [^maxSize := 4]. > > [CmpRdRd] -> [^maxSize := 4]. > > [SubRdRd] -> [^maxSize := 4]. > > [MulRdRd] -> [^maxSize := 4]. > > [DivRdRd] -> [^maxSize := 4]. > > [SqrtRd] -> [^maxSize := 4]. > > "Data Movement" > > [MoveCqR] -> [^maxSize := (operands at: 0) = 0 ifTrue: [2] ifFalse: [5]]. > > [MoveCwR] -> [^maxSize := 5]. > > [MoveRR] -> [^maxSize := 2]. > > [MoveAwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > > ifTrue: [5] > > ifFalse: [6]]. > > [MoveRAw] -> [^maxSize := (self concreteRegister: (operands at: 0)) = EAX > > ifTrue: [5] > > ifFalse: [6]]. > > [MoveRMwr] -> [^maxSize := ((self isQuick: (operands at: 1)) > > ifTrue: [3] > > ifFalse: [6]) > > + ((self concreteRegister: (operands at: 2)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveRdM64r] -> [^maxSize := ((self isQuick: (operands at: 1)) > > ifTrue: [5] > > ifFalse: [8]) > > + ((self concreteRegister: (operands at: 2)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveMbrR] -> [^maxSize := ((self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [6]) > > + ((self concreteRegister: (operands at: 1)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveRMbr] -> [^maxSize := ((self isQuick: (operands at: 1)) > > ifTrue: [3] > > ifFalse: [6]) > > + ((self concreteRegister: (operands at: 2)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveM16rR] -> [^maxSize := ((self isQuick: (operands at: 0)) > > ifTrue: [4] > > ifFalse: [7]) > > + ((self concreteRegister: (operands at: 1)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveM64rRd] -> [^maxSize := ((self isQuick: (operands at: 0)) > > ifTrue: [5] > > ifFalse: [8]) > > + ((self concreteRegister: (operands at: 1)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveMwrR] -> [^maxSize := ((self isQuick: (operands at: 0)) > > ifTrue: [3] > > ifFalse: [6]) > > + ((self concreteRegister: (operands at: 1)) = ESP > > ifTrue: [1] > > ifFalse: [0])]. > > [MoveXbrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= > > ESP. > > ^maxSize := (self concreteRegister: (operands at: 1)) = EBP > > ifTrue: [5] > > ifFalse: [4]]. > > [MoveXwrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= > > ESP. > > ^maxSize := (self concreteRegister: (operands at: 1)) = EBP > > ifTrue: [4] > > ifFalse: [3]]. > > [MoveRXwrR] -> [self assert: (self concreteRegister: (operands at: 1)) ~= > > ESP. > > ^maxSize := (self concreteRegister: (operands at: 2)) = EBP > > ifTrue: [4] > > ifFalse: [3]]. > > [PopR] -> [^maxSize := 1]. > > [PushR] -> [^maxSize := 1]. > > [PushCw] -> [^maxSize := 5]. > > [PrefetchAw] -> [^maxSize := self hasSSEInstructions ifTrue: [7] ifFalse: > > [0]]. > > "Conversion" > > [ConvertRRd] -> [^maxSize := 4] }. > > ^0 "to keep C compiler quiet" > > In which case the alternative could be to reify Instructions and let > them respondsTo: maxSize, but one would still need a decoder integer > -> InstructionClass. > That doesn't work in this context because the above has to be translated to c *without* classes. > But if it is for the benefit of a single method, it's legitimate to > wonder why bother and create so many classes. > > Nicolas > > >> > >> Stef > >> > >> > >> > > > >> > > > >> > > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse > >> > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> > >> > >> Eliot > >> > >> > >> > >> you use caseOf: for the generation of C in Slang and VM maker. > >> > >> Now this means that > >> > >> - it does not need to be inlined > >> > > > >> > > No. If it is not inlined the simulator will go *much* slower. e.g. > >> > > CogVMSimulatorLSB>>byteAt: byteAddress > >> > > | lowBits long | > >> > > lowBits := byteAddress bitAnd: 3. > >> > > long := self longAt: byteAddress - lowBits. > >> > > ^(lowBits caseOf: { > >> > > [0] -> [ long ]. > >> > > [1] -> [ long bitShift: -8 ]. > >> > > [2] -> [ long bitShift: -16 ]. > >> > > [3] -> [ long bitShift: -24 ] > >> > > }) bitAnd: 16rFF > >> > > > >> > > >> > so why not put it: > >> > > >> > ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF > >> > > >> > ? > >> > Or this will be slower than caseOf: ? > >> > > >> > Because that was the way the code was written. I just copied the > >> > method. Further, it is only one example. I'm not going to rewrite > the > >> > VMMaker's uses of caseOf: jyst to suit some whim of purity. It is > making > >> > unnecessary work. Taking it out is *much* more work (/and/ emotional > >> > energy) than just leaving it alone. Can't we try and be constructive? > >> > > >> > > >> > > >> > >> > >> > >> - it could be packaged with VMMaker > >> > > > >> > > No. It needs to be in the compiler to be inlined. Why have you got > >> > > on this > >> > > hobby-horse? It is a non-issue. caseOf: ios not widelty used but > >> > > extremely > >> > > useful in certain circumstances. This has the feeling of a > religious > >> > > pogrom, not a rational approach to the system. IIABDFI = If It > Ain't > >> > > Broke, > >> > > Don't Fix It. > >> > > >> > This concept kinda appeal to me. > >> > From other side, i am also strongly feel that house should be kept > clean > >> > :) > >> > > >> > >> > >> > >> Are these two points correct? > >> > > > >> > > No, IMO, definitely not. > >> > > > >> > >> > >> > >> Stef > >> > >> > >> > > > >> > > > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Igor Stasenko AKA sig. > >> > > >> > > >> > >> > > > > > >

Feb. 15, 2011

[Pharo-project] Issue 3708 in pharo: Selection text color enh

by pharo＠googlecode.com

Status: FixProposed Owner: aplan...(a)gmail.com Labels: Milestone-1.3 New issue 3708 by aplan...(a)gmail.com: Selection text color enh http://code.google.com/p/pharo/issues/detail?id=3708 Because selection text is currently black, it isn't possible to use more constrasted colors for text, list and tree selection. So, the goal here is to be able to setup a style with constrasting colors (High constrasts style accessible from the setting browser in the futur, useful for demo mode or for people who need big letters and high constrated colors). This is the first step. See screenshot. To do so, MorphTreeMorph has been reviewed together with the new MessageListBrowser and the new Finder tools (less classes and integration with MorphTreeMorph improved, MorphTreeMorph cleaned btw).

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Nicolas Cellier

2011/2/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Feb 15, 2011 at 12:39 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Eliot >> >> I can understand that well. Now we could just let this code in VMMaker and >> not inlining. >> We fix 8 users and we are done. I have concerned that we have a complex >> solution because it is complex >> for a couple of use case. Of course we can do nothing (and we will >> probably not do it now) but in that case we can >> also stop pharo right now because a large part of the system could follow >> the exact same principle. > > That's a false distinction. Â There's nothing wrong with caseOf: and not > addressing it will not leave Pharo any the worse. Â Case statements are not > in themselves evil in the right context. Â The main problems with the > index/dictionary approach are that > a) the solution is no longer contained in a single method > b) the dictionary is metadata that needs to be updated in an initialize > method; forget to initialize the dictionary when an index changes and your > program is broken. > As my first wife said "don't sweat the petty stuff; pet the sweaty stuff". > > BTW, there's a false assumption that has been stated in this thread that the > caseOf: statement is only used with explicit integers. Â It can be used with > anything. Â Expressions, class constants etc. >> >> BTW why marcus and jorge work on Opal because the compiler is just working >> good? >> >> Now I will focus on 1.2, FS, Opal if I can help, and the rest but caseOf: >> will be in our radar. >> >> Just a remark if people would have spend the time to write mail to fix the >> users of caseof: in the image and >> other non VMmaker package we would have get already done. > > Fix this (rhetorical - I think this is /much/ better as a single case > statement than as an index/dictionary refactoring, both in Smalltalk and > when translated to C): > CogIA32Compiler>>computeMaximumSize > "Compute the maximum size for each opcode. Â This allows jump offsets to > be determined, provided that all backward branches are long branches." > "N.B. Â The ^maxSize := N forms are to get around the compiler's long branch > limits which are exceeded when each case jumps around the otherwise." > opcode caseOf: { > "Noops & Pseudo Ops" > [Label] -> [^maxSize := 0]. > [AlignmentNops] -> [^maxSize := (operands at: 0) - 1]. > [Fill16] -> [^maxSize := 2]. > [Fill32] -> [^maxSize := 4]. > [FillFromWord] -> [^maxSize := 4]. > [Nop] -> [^maxSize := 1]. > "Specific Control/Data Movement" > [CDQ] -> [^maxSize := 1]. > [IDIVR] -> [^maxSize := 2]. > [IMULRR] -> [^maxSize := 3]. > [CPUID] -> [^maxSize := 2]. > [CMPXCHGAwR] -> [^maxSize := 7]. > [CMPXCHGMwrR] -> [^maxSize := 8]. > [LFENCE] -> [^maxSize := 3]. > [MFENCE] -> [^maxSize := 3]. > [SFENCE] -> [^maxSize := 3]. > [LOCK] -> [^maxSize := 1]. > [XCHGAwR] -> [^maxSize := 6]. > [XCHGMwrR] -> [^maxSize := 7]. > [XCHGRR] -> [^maxSize := 2]. > "Control" > [Call] -> [^maxSize := 5]. > [JumpR] -> [^maxSize := 2]. > [Jump] -> [self resolveJumpTarget. ^maxSize := 5]. > [JumpLong] -> [self resolveJumpTarget. ^maxSize := 5]. > [JumpZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNegative] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNonNegative] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNoOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpCarry] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNoCarry] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLess] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpGreater] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpBelow] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpAboveOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpAbove] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpBelowOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLongZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLongNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPNotEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPLess] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPGreater] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPOrdered] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPUnordered] -> [self resolveJumpTarget. ^maxSize := 6]. > [RetN] -> [^maxSize := (operands at: 0) = 0 > ifTrue: [1] > ifFalse: [3]]. > "Arithmetic" > [AddCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [AndCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [CmpCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [OrCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [SubCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [AddCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [CmpCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [SubCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [XorCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [AddRR] -> [^maxSize := 2]. > [AndRR] -> [^maxSize := 2]. > [CmpRR] -> [^maxSize := 2]. > [OrRR] -> [^maxSize := 2]. > [XorRR] -> [^maxSize := 2]. > [SubRR] -> [^maxSize := 2]. > [NegateR] -> [^maxSize := 2]. > [LoadEffectiveAddressMwrR] > -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [LogicalShiftLeftCqR] -> [^maxSize := (operands at: 0) = 1 > ifTrue: [2] > ifFalse: [3]]. > [LogicalShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 > ifTrue: [2] > ifFalse: [3]]. > [ArithmeticShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 > ifTrue: [2] > ifFalse: [3]]. > [LogicalShiftLeftRR] -> [self computeShiftRRSize]. > [LogicalShiftRightRR] -> [self computeShiftRRSize]. > [ArithmeticShiftRightRR] -> [self computeShiftRRSize]. > [AddRdRd] -> [^maxSize := 4]. > [CmpRdRd] -> [^maxSize := 4]. > [SubRdRd] -> [^maxSize := 4]. > [MulRdRd] -> [^maxSize := 4]. > [DivRdRd] -> [^maxSize := 4]. > [SqrtRd] -> [^maxSize := 4]. > "Data Movement" > [MoveCqR] -> [^maxSize := (operands at: 0) = 0 ifTrue: [2] ifFalse: [5]]. > [MoveCwR] -> [^maxSize := 5]. > [MoveRR] -> [^maxSize := 2]. > [MoveAwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [MoveRAw] -> [^maxSize := (self concreteRegister: (operands at: 0)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [MoveRMwr] -> [^maxSize := ((self isQuick: (operands at: 1)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 2)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveRdM64r] -> [^maxSize := ((self isQuick: (operands at: 1)) > ifTrue: [5] > ifFalse: [8]) > + ((self concreteRegister: (operands at: 2)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveMbrR] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveRMbr] -> [^maxSize := ((self isQuick: (operands at: 1)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 2)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveM16rR] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [4] > ifFalse: [7]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveM64rRd] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [5] > ifFalse: [8]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveMwrR] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveXbrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= > ESP. > ^maxSize := (self concreteRegister: (operands at: 1)) = EBP > ifTrue: [5] > ifFalse: [4]]. > [MoveXwrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= > ESP. > ^maxSize := (self concreteRegister: (operands at: 1)) = EBP > ifTrue: [4] > ifFalse: [3]]. > [MoveRXwrR] -> [self assert: (self concreteRegister: (operands at: 1)) ~= > ESP. > ^maxSize := (self concreteRegister: (operands at: 2)) = EBP > ifTrue: [4] > ifFalse: [3]]. > [PopR] -> [^maxSize := 1]. > [PushR] -> [^maxSize := 1]. > [PushCw] -> [^maxSize := 5]. > [PrefetchAw] -> [^maxSize := self hasSSEInstructions ifTrue: [7] ifFalse: > [0]]. > "Conversion" > [ConvertRRd] -> [^maxSize := 4] }. > ^0 "to keep C compiler quiet" In which case the alternative could be to reify Instructions and let them respondsTo: maxSize, but one would still need a decoder integer -> InstructionClass. But if it is for the benefit of a single method, it's legitimate to wonder why bother and create so many classes. Nicolas >> >> Stef >> >> >> > > >> > > >> > > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse >> > > <stephane.ducasse(a)inria.fr> wrote: >> > >> >> > >> Eliot >> > >> >> > >> you use caseOf: for the generation of C in Slang and VM maker. >> > >> Now this means that >> > >> Â Â Â Â - it does not need to be inlined >> > > >> > > No. Â If it is not inlined the simulator will go *much* slower. Â e.g. >> > > CogVMSimulatorLSB>>byteAt: byteAddress >> > > | lowBits long | >> > > lowBits := byteAddress bitAnd: 3. >> > > long := self longAt: byteAddress - lowBits. >> > > ^(lowBits caseOf: { >> > > [0] -> [ long ]. >> > > [1] -> [ long bitShift: -8 Â ]. >> > > [2] -> [ long bitShift: -16 ]. >> > > [3] -> [ long bitShift: -24 ] >> > > }) bitAnd: 16rFF >> > > >> > >> > so why not put it: >> > >> > ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF >> > >> > ? >> > Or this will be slower than caseOf: ? >> > >> > Because that was the way the code was written. Â I just copied the >> > method. Â Further, it is only one example. Â I'm not going to rewrite the >> > VMMaker's uses of caseOf: jyst to suit some whim of purity. Â It is making >> > unnecessary work. Â Taking it out is *much* more work (/and/ emotional >> > energy) than just leaving it alone. Â Can't we try and be constructive? >> > >> > >> > >> > >> >> > >> Â Â Â Â - it could be packaged with VMMaker >> > > >> > > No. Â It needs to be in the compiler to be inlined. Â Why have you got >> > > on this >> > > hobby-horse? Â It is a non-issue. Â caseOf: ios not widelty used but >> > > extremely >> > > useful in certain circumstances. Â This has the feeling of a religious >> > > pogrom, not a rational approach to the system. Â IIABDFI = If It Ain't >> > > Broke, >> > > Don't Fix It. >> > >> > This concept kinda appeal to me. >> > From other side, i am also strongly feel that house should be kept clean >> > :) >> > >> > >> >> > >> Are these two points correct? >> > > >> > > No, IMO, definitely not. >> > > >> > >> >> > >> Stef >> > >> >> > > >> > > >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko AKA sig. >> > >> > >> >> > >

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Casimiro de Almeida Barreto

Em 15-02-2011 16:55, Schwab,Wilhelm K escreveu: > I am not completely certain who is on which side here anymore, other than #caseOf: is at the center of it. I think I saw Eliot say that Cog uses it; if I got that right, it's a pretty compelling reason to keep it in the image. Doing that, either for Cog's benefit, or even just for the convenience of a subset of users does not necessarily imply that Pharo itself needs to use the message. That is about the limit of what I can offer in the form of guidance, and it is really more of a question: could Pharo be changed to ignore the message, and then keep it in the image for Cog and other users? Maybe that is too idealistic, or just plain naive :) > > Mapping integers from the outside world to objects and/or behavior is something that I do a lot. I have to more or less agree with Sig; case statements as such generally point to room for a design to better exploit messaging. There are indeed scenarios (especially if not exclusively in external interfacing) that call for mapping numbers to actions. I have had great results with dictionaries for that purpose, but I am not trying to squeeze every last byte code per second out of a portable VM. Yeah, implementations using dictionaries are quite elegant. And they're not usually expensive in terms of processing. Anyways, when processing external input, IO is usually much slower than relating a numeric value to a symbol & then performing an action... There are lots of alternatives to performing a "caseOf:" thing, so I just don't see things as a question of "smalltalk purity". > There have been situations in which Smalltalkers have climbed the ivory tower and looked with contempt on things that make the world work. I am not convinced that is happening here. >

Feb. 15, 2011

Re: [Pharo-project] weak announcements

by Tudor Girba

I committed the packages in PharoTaskForces. Cheers, Doru On 15 Feb 2011, at 19:20, StÃ©phane Ducasse wrote: > > >> Hi, >> >> Yes, it is meant to be integrated in Pharo 1.3. >> >> Ok, but then PharoTaskForces should not delete the packages after they are integrated. > > they will just be moved to pharo for history management. > >> The reason is that I want to use these announcements before you release 1.3, and thus it will appear in ConfigurationOfGlamour. Is that Ok? > > Sure! > > >> >> Cheers, >> Doru >> >> >> On 15 Feb 2011, at 18:53, StÃ©phane Ducasse wrote: >> >>> if this is to be integrated in 1.3 (which I hope :)) then I would prefer PharoTaskForces >>> >>> Stef >>> >>> >>>> Hi everyone, >>>> >>>> So, the current situation is that we can make rather quickly on:send:to: work weakly. >>>> >>>> There is an almost working version in Lukas' repository, and Esteban and me will try to get it to work. Now, the question is where to publish this. I would suggest to create an official squeaksource.com/announcements repository. >>>> >>>> Is that Ok for you, or do you prefer to have it in squeaksource.com/PharoTaskForces? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 15 Feb 2011, at 18:21, Tudor Girba wrote: >>>> >>>>> Hi Esteban, >>>>> >>>>> I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 15 Feb 2011, at 17:37, Tudor Girba wrote: >>>>> >>>>>> Hi Esteban, >>>>>> >>>>>> I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. >>>>>> >>>>>> Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? >>>>>> >>>>>> The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: >>>>>> >>>>>>> Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector->nil and we need to think in a way to clean this. But this is doable :) >>>>>>> In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. >>>>>>> >>>>>>> Cheers, >>>>>>> Esteban >>>>>>> >>>>>>> El 14/02/2011, a las 6:55p.m., Tudor Girba escribiÃ³: >>>>>>> >>>>>>>> Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: >>>>>>>>> :( >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Esteban >>>>>>>>> >>>>>>>>> Inicio del mensaje reenviado: >>>>>>>>> >>>>>>>>>> De: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 >>>>>>>>>> Para: Pharo-project(a)lists.gforge.inria.fr >>>>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements... >>>>>>>>>> Responder a: Pharo-project(a)lists.gforge.inria.fr >>>>>>>>>> >>>>>>>>>> good question :) >>>>>>>>>> >>>>>>>>>> On FHi, >>>>>>>>>>> I'm working with weak announcements, >>>>>>>>>> >>>>>>>>>> good we need that. >>>>>>>>>> Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). >>>>>>>>>> Now it would be good to have first a solution at image level >>>>>>>>>> >>>>>>>>>>> trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) >>>>>>>>>>> I try to explain: >>>>>>>>>>> >>>>>>>>>>> This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. >>>>>>>>>>> Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? >>>>>>>>>>> I tried some hacks (really ugly hacks, btw), but fail completely. >>>>>>>>>>> Any idea? >>>>>>>>>>> >>>>>>>>>>> best, >>>>>>>>>>> Esteban >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> >>>>>>>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Reasonable is what we are accustomed with." >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every now and then stop and ask yourself if the war you're fighting is the right one." >>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "The coherence of a trip is given by the clearness of the goal." >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> >> > > -- www.tudorgirba.com "What we can governs what we wish."

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Nicolas Cellier

2011/2/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 15 February 2011 19:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse >> > <stephane.ducasse(a)inria.fr> wrote: >> >> >> >> Eliot >> >> >> >> you use caseOf: for the generation of C in Slang and VM maker. >> >> Now this means that >> >> Â Â Â Â - it does not need to be inlined >> > >> > No. Â If it is not inlined the simulator will go *much* slower. Â e.g. >> > CogVMSimulatorLSB>>byteAt: byteAddress >> > | lowBits long | >> > lowBits := byteAddress bitAnd: 3. >> > long := self longAt: byteAddress - lowBits. >> > ^(lowBits caseOf: { >> > [0] -> [ long ]. >> > [1] -> [ long bitShift: -8 Â ]. >> > [2] -> [ long bitShift: -16 ]. >> > [3] -> [ long bitShift: -24 ] >> > }) bitAnd: 16rFF >> > >> >> so why not put it: >> >> ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF >> >> ? >> Or this will be slower than caseOf: ? > > Because that was the way the code was written. Â I just copied the method. > Â Further, it is only one example. Â I'm not going to rewrite the VMMaker's > uses of caseOf: jyst to suit some whim of purity. Â It is making unnecessary > work. Â Taking it out is *much* more work (/and/ emotional energy) than just > leaving it alone. Â Can't we try and be constructive? > I agree with Eliot, byteAt: byteAt:put: are the easy part to rewrite - plus they are copy/pasted a number of times ;) The other cog's caseOf: are tougher and if caseOf: just works, why bother... Nicolas >> >> >> >> >> Â Â Â Â - it could be packaged with VMMaker >> > >> > No. Â It needs to be in the compiler to be inlined. Â Why have you got on >> > this >> > hobby-horse? Â It is a non-issue. Â caseOf: ios not widelty used but >> > extremely >> > useful in certain circumstances. Â This has the feeling of a religious >> > pogrom, not a rational approach to the system. Â IIABDFI = If It Ain't >> > Broke, >> > Don't Fix It. >> >> This concept kinda appeal to me. >> From other side, i am also strongly feel that house should be kept clean >> :) >> >> >> >> >> Are these two points correct? >> > >> > No, IMO, definitely not. >> > >> >> >> >> Stef >> >> >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > >

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Eliot Miranda

On Tue, Feb 15, 2011 at 12:39 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Eliot > > I can understand that well. Now we could just let this code in VMMaker and > not inlining. > We fix 8 users and we are done. I have concerned that we have a complex > solution because it is complex > for a couple of use case. Of course we can do nothing (and we will probably > not do it now) but in that case we can > also stop pharo right now because a large part of the system could follow > the exact same principle. > That's a false distinction. There's nothing wrong with caseOf: and not addressing it will not leave Pharo any the worse. Case statements are not in themselves evil in the right context. The main problems with the index/dictionary approach are that a) the solution is no longer contained in a single method b) the dictionary is metadata that needs to be updated in an initialize method; forget to initialize the dictionary when an index changes and your program is broken. As my first wife said "don't sweat the petty stuff; pet the sweaty stuff". BTW, there's a false assumption that has been stated in this thread that the caseOf: statement is only used with explicit integers. It can be used with anything. Expressions, class constants etc. BTW why marcus and jorge work on Opal because the compiler is just working > good? > > Now I will focus on 1.2, FS, Opal if I can help, and the rest but caseOf: > will be in our radar. > > Just a remark if people would have spend the time to write mail to fix the > users of caseof: in the image and > other non VMmaker package we would have get already done. > Fix this (rhetorical - I think this is /much/ better as a single case statement than as an index/dictionary refactoring, both in Smalltalk and when translated to C): CogIA32Compiler>>computeMaximumSize "Compute the maximum size for each opcode. This allows jump offsets to be determined, provided that all backward branches are long branches." "N.B. The ^maxSize := N forms are to get around the compiler's long branch limits which are exceeded when each case jumps around the otherwise." opcode caseOf: { "Noops & Pseudo Ops" [Label] -> [^maxSize := 0]. [AlignmentNops] -> [^maxSize := (operands at: 0) - 1]. [Fill16] -> [^maxSize := 2]. [Fill32] -> [^maxSize := 4]. [FillFromWord] -> [^maxSize := 4]. [Nop] -> [^maxSize := 1]. "Specific Control/Data Movement" [CDQ] -> [^maxSize := 1]. [IDIVR] -> [^maxSize := 2]. [IMULRR] -> [^maxSize := 3]. [CPUID] -> [^maxSize := 2]. [CMPXCHGAwR] -> [^maxSize := 7]. [CMPXCHGMwrR] -> [^maxSize := 8]. [LFENCE] -> [^maxSize := 3]. [MFENCE] -> [^maxSize := 3]. [SFENCE] -> [^maxSize := 3]. [LOCK] -> [^maxSize := 1]. [XCHGAwR] -> [^maxSize := 6]. [XCHGMwrR] -> [^maxSize := 7]. [XCHGRR] -> [^maxSize := 2]. "Control" [Call] -> [^maxSize := 5]. [JumpR] -> [^maxSize := 2]. [Jump] -> [self resolveJumpTarget. ^maxSize := 5]. [JumpLong] -> [self resolveJumpTarget. ^maxSize := 5]. [JumpZero] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpNegative] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpNonNegative] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpNoOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpCarry] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpNoCarry] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpLess] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpGreater] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpBelow] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpAboveOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpAbove] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpBelowOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpLongZero] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpLongNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPNotEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPLess] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPGreater] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPOrdered] -> [self resolveJumpTarget. ^maxSize := 6]. [JumpFPUnordered] -> [self resolveJumpTarget. ^maxSize := 6]. [RetN] -> [^maxSize := (operands at: 0) = 0 ifTrue: [1] ifFalse: [3]]. "Arithmetic" [AddCqR] -> [^maxSize := (self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [(self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]]. [AndCqR] -> [^maxSize := (self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [(self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]]. [CmpCqR] -> [^maxSize := (self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [(self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]]. [OrCqR] -> [^maxSize := (self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [(self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]]. [SubCqR] -> [^maxSize := (self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [(self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]]. [AddCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]. [CmpCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]. [SubCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]. [XorCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]. [AddRR] -> [^maxSize := 2]. [AndRR] -> [^maxSize := 2]. [CmpRR] -> [^maxSize := 2]. [OrRR] -> [^maxSize := 2]. [XorRR] -> [^maxSize := 2]. [SubRR] -> [^maxSize := 2]. [NegateR] -> [^maxSize := 2]. [LoadEffectiveAddressMwrR] -> [^maxSize := ((self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [6]) + ((self concreteRegister: (operands at: 1)) = ESP ifTrue: [1] ifFalse: [0])]. [LogicalShiftLeftCqR] -> [^maxSize := (operands at: 0) = 1 ifTrue: [2] ifFalse: [3]]. [LogicalShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 ifTrue: [2] ifFalse: [3]]. [ArithmeticShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 ifTrue: [2] ifFalse: [3]]. [LogicalShiftLeftRR] -> [self computeShiftRRSize]. [LogicalShiftRightRR] -> [self computeShiftRRSize]. [ArithmeticShiftRightRR] -> [self computeShiftRRSize]. [AddRdRd] -> [^maxSize := 4]. [CmpRdRd] -> [^maxSize := 4]. [SubRdRd] -> [^maxSize := 4]. [MulRdRd] -> [^maxSize := 4]. [DivRdRd] -> [^maxSize := 4]. [SqrtRd] -> [^maxSize := 4]. "Data Movement" [MoveCqR] -> [^maxSize := (operands at: 0) = 0 ifTrue: [2] ifFalse: [5]]. [MoveCwR] -> [^maxSize := 5]. [MoveRR] -> [^maxSize := 2]. [MoveAwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX ifTrue: [5] ifFalse: [6]]. [MoveRAw] -> [^maxSize := (self concreteRegister: (operands at: 0)) = EAX ifTrue: [5] ifFalse: [6]]. [MoveRMwr] -> [^maxSize := ((self isQuick: (operands at: 1)) ifTrue: [3] ifFalse: [6]) + ((self concreteRegister: (operands at: 2)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveRdM64r] -> [^maxSize := ((self isQuick: (operands at: 1)) ifTrue: [5] ifFalse: [8]) + ((self concreteRegister: (operands at: 2)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveMbrR] -> [^maxSize := ((self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [6]) + ((self concreteRegister: (operands at: 1)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveRMbr] -> [^maxSize := ((self isQuick: (operands at: 1)) ifTrue: [3] ifFalse: [6]) + ((self concreteRegister: (operands at: 2)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveM16rR] -> [^maxSize := ((self isQuick: (operands at: 0)) ifTrue: [4] ifFalse: [7]) + ((self concreteRegister: (operands at: 1)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveM64rRd] -> [^maxSize := ((self isQuick: (operands at: 0)) ifTrue: [5] ifFalse: [8]) + ((self concreteRegister: (operands at: 1)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveMwrR] -> [^maxSize := ((self isQuick: (operands at: 0)) ifTrue: [3] ifFalse: [6]) + ((self concreteRegister: (operands at: 1)) = ESP ifTrue: [1] ifFalse: [0])]. [MoveXbrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= ESP. ^maxSize := (self concreteRegister: (operands at: 1)) = EBP ifTrue: [5] ifFalse: [4]]. [MoveXwrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= ESP. ^maxSize := (self concreteRegister: (operands at: 1)) = EBP ifTrue: [4] ifFalse: [3]]. [MoveRXwrR] -> [self assert: (self concreteRegister: (operands at: 1)) ~= ESP. ^maxSize := (self concreteRegister: (operands at: 2)) = EBP ifTrue: [4] ifFalse: [3]]. [PopR] -> [^maxSize := 1]. [PushR] -> [^maxSize := 1]. [PushCw] -> [^maxSize := 5]. [PrefetchAw] -> [^maxSize := self hasSSEInstructions ifTrue: [7] ifFalse: [0]]. "Conversion" [ConvertRRd] -> [^maxSize := 4] }. ^0 "to keep C compiler quiet" > > Stef > > > > > > > > > > > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse > > > <stephane.ducasse(a)inria.fr> wrote: > > >> > > >> Eliot > > >> > > >> you use caseOf: for the generation of C in Slang and VM maker. > > >> Now this means that > > >> - it does not need to be inlined > > > > > > No. If it is not inlined the simulator will go *much* slower. e.g. > > > CogVMSimulatorLSB>>byteAt: byteAddress > > > | lowBits long | > > > lowBits := byteAddress bitAnd: 3. > > > long := self longAt: byteAddress - lowBits. > > > ^(lowBits caseOf: { > > > [0] -> [ long ]. > > > [1] -> [ long bitShift: -8 ]. > > > [2] -> [ long bitShift: -16 ]. > > > [3] -> [ long bitShift: -24 ] > > > }) bitAnd: 16rFF > > > > > > > so why not put it: > > > > ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF > > > > ? > > Or this will be slower than caseOf: ? > > > > Because that was the way the code was written. I just copied the method. > Further, it is only one example. I'm not going to rewrite the VMMaker's > uses of caseOf: jyst to suit some whim of purity. It is making unnecessary > work. Taking it out is *much* more work (/and/ emotional energy) than just > leaving it alone. Can't we try and be constructive? > > > > > > > > >> > > >> - it could be packaged with VMMaker > > > > > > No. It needs to be in the compiler to be inlined. Why have you got on > this > > > hobby-horse? It is a non-issue. caseOf: ios not widelty used but > extremely > > > useful in certain circumstances. This has the feeling of a religious > > > pogrom, not a rational approach to the system. IIABDFI = If It Ain't > Broke, > > > Don't Fix It. > > > > This concept kinda appeal to me. > > From other side, i am also strongly feel that house should be kept clean > :) > > > > >> > > >> Are these two points correct? > > > > > > No, IMO, definitely not. > > > > > >> > > >> Stef > > >> > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > > > >

Feb. 15, 2011

Re: [Pharo-project] A new GUI visual designer

by StÃ©phane Ducasse

For me I do not know. Just want to get educated. Building my taste and after I will be able to have a point of view. Stef On Feb 15, 2011, at 9:24 PM, Richard Durr wrote: > I do not really like QT and would prefer somethink more mac like. > > On Tue, Feb 15, 2011 at 9:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > tx! > > > Here is more information: > > > > http://stackoverflow.com/questions/596382/what-describes-an-outlet-best-in-… > > http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concep… > > >

Feb. 15, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by StÃ©phane Ducasse

Eliot I can understand that well. Now we could just let this code in VMMaker and not inlining. We fix 8 users and we are done. I have concerned that we have a complex solution because it is complex for a couple of use case. Of course we can do nothing (and we will probably not do it now) but in that case we can also stop pharo right now because a large part of the system could follow the exact same principle. BTW why marcus and jorge work on Opal because the compiler is just working good? Now I will focus on 1.2, FS, Opal if I can help, and the rest but caseOf: will be in our radar. Just a remark if people would have spend the time to write mail to fix the users of caseof: in the image and other non VMmaker package we would have get already done. Stef > > > > > > On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> Eliot > >> > >> you use caseOf: for the generation of C in Slang and VM maker. > >> Now this means that > >> - it does not need to be inlined > > > > No. If it is not inlined the simulator will go *much* slower. e.g. > > CogVMSimulatorLSB>>byteAt: byteAddress > > | lowBits long | > > lowBits := byteAddress bitAnd: 3. > > long := self longAt: byteAddress - lowBits. > > ^(lowBits caseOf: { > > [0] -> [ long ]. > > [1] -> [ long bitShift: -8 ]. > > [2] -> [ long bitShift: -16 ]. > > [3] -> [ long bitShift: -24 ] > > }) bitAnd: 16rFF > > > > so why not put it: > > ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF > > ? > Or this will be slower than caseOf: ? > > Because that was the way the code was written. I just copied the method. Further, it is only one example. I'm not going to rewrite the VMMaker's uses of caseOf: jyst to suit some whim of purity. It is making unnecessary work. Taking it out is *much* more work (/and/ emotional energy) than just leaving it alone. Can't we try and be constructive? > > > > >> > >> - it could be packaged with VMMaker > > > > No. It needs to be in the compiler to be inlined. Why have you got on this > > hobby-horse? It is a non-issue. caseOf: ios not widelty used but extremely > > useful in certain circumstances. This has the feeling of a religious > > pogrom, not a rational approach to the system. IIABDFI = If It Ain't Broke, > > Don't Fix It. > > This concept kinda appeal to me. > From other side, i am also strongly feel that house should be kept clean :) > > >> > >> Are these two points correct? > > > > No, IMO, definitely not. > > > >> > >> Stef > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 15, 2011