could we agree to remove caseOf: and caseOf:otherwise:
Locked
12345
12345
Re: could we agree to remove caseOf: and caseOf:otherwise:
 
|
On 15 February 2011 20:15, <[hidden email]> wrote:
> Em 15/02/2011 10:37, Igor Stasenko < [hidden email] > escreveu: > > Whereas I understand we are community of spirited and humorous programmers, I think that statements like: > >> I agree. Then probably, Pharo should move it to separate >> 'Crap-compat' package. > > Are not amenable to the "good energy" Stef is willing to have in the Pharo team. > >> ;-P > > And the emoticon puts a tongue! > > The 'nickname' brings a judgment of value which I think may stir more > feelings and doesn't bring anything useful to Pharo... > Yes, in this discussion i wearing hat of an asshole. With humor , of course. Hey.. i'm not killing people and don't burning heretics. Also, the importance of outcome of this discussion is too small for being taken too seriously. I can live with or without #caseOf: (but better without), so relax and have fun :) >> You don't need to remove #caseOf: implementation. I can stay. Just >> remove a compiler hacks for it :) >> P.S. i patched MessageNode class>>initialize to test if VMMaker can >> work without compiler support of caseof: and as it was expected it >> works quite well. >> I recompiled VMMaker package and then generated full source code of >> everything, and then built VM. No any errors. > > And what would be the results of Levente's benchmark? > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
Em 15/02/2011 17:03, Igor Stasenko < [hidden email] > escreveu:
On 15 February 2011 19:23, wrote: > > Em 13/02/2011 21:21, Stephen Taylor < [hidden email] > > > escreveu: Igor Stasenko wrote: > > > >> > >> >> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 > >> >> 82. When a variable's value is equal to any of these... > >> > >> > Don't try to convince me that there are sort of problems which > >> > can be solved only by using case statement :) > > Igor's attitude, which I'll take as sample of a school of thought > > is dangerously similar to the one which in name of keeping certain > > aspects of Smalltalk "pure" or near to the origins has made its > > acceptance fall as the other aspects of the technology (OO, WIMP, > > etc.), made their way into other languages/platforms/technologies. > > > I am not opposed to innovations or cross-breeding techs. My purism > lies on simple principle: KISS. If something could be made simpler > without losing key features then it should done. Your KISS principle has to come at odds with another one, which was the reason why the construct was put in place: performance. This is called engineering, it is the art of trade off. > > > >> You didn't answer the question though. > > And then this: to the first concrete example, no complete answer > > comes out which we could check if the code construct is indeed > > only a syntactic sugar, or deserves incorporation in the toolset > > of the language... > > I don't see a need of explaining how to interpret a simple > translation without using caseOf: statement. You don't, because you already decided that what it is at stake doesn't matter for Pharo. I'm just trying to recap here: the construct is not here to mud the purity of a beatiful OO language nor be incentive to bad code smells. It has been put to solve a particular problem in a very specific part of the system. > > >> > First, get rid of these integers in your code. That's the > >> killer - yes, we can usually design around cases where > >> we'd use case constructs (though I'm not convinced they're the > >> spawn of the devil) but what about cases where we're interfacing > >> with external data sources and we don't get to redesign the whole > >> system to suit our needs? > > FWIW, this kind of need, namely having to take alternate actions > > due different integer codes is pretty common when interfacing with > > industrial boards, a lot of protocols use this as well and most of > > them are already in use, some even have international standards. > And i suspect that all these standards are properly documented, and > each signal/number having its description, so you can represent them > by names, not by numbers. > I may lost something, but how will you convert the numbers in names to start with? > > So the answer "redesign your world to fit our world-view" does not > > cut in... > > > I'm not asking you to redesign C world to fit smalltalk view. Use > each tool what it made for. What i asking is to not use a > microscope for hammering nails. Hammer is much better tool for that. > This statement is called in Informal Logic "the Fallacy of the False Analogy". > > Also, another argument I've seen in this thread which is pretty > >commonplace w.r.t. performance must be extirpated in our discourse: > >"the performance x to y slower than is very good considering > >{dynamic} languages (or similar statement)". > > Performance counts! > Sure. At some point if you train long enough you can hammer nail > using microscope much faster than using hammer. But that still > doesn't means that you doing it right :) As I already pointed out, your base reasoning is false, this is consequentially /non sequitur/. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Igor Stasenko
On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <[hidden email]> wrote:
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?
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by csrabak
On 15 February 2011 20:38, <[hidden email]> wrote:
> Em 15/02/2011 17:03, Igor Stasenko < [hidden email] > escreveu: > On 15 February 2011 19:23, wrote: > >> > Em 13/02/2011 21:21, Stephen Taylor < [hidden email] > >> > escreveu: Igor Stasenko wrote: >> > >> >> >> >> >> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 >> >> >> 82. When a variable's value is equal to any of these... >> >> >> >> > Don't try to convince me that there are sort of problems which >> >> > can be solved only by using case statement :) >> > Igor's attitude, which I'll take as sample of a school of thought >> > is dangerously similar to the one which in name of keeping certain >> > aspects of Smalltalk "pure" or near to the origins has made its >> > acceptance fall as the other aspects of the technology (OO, WIMP, >> > etc.), made their way into other languages/platforms/technologies. >> > >> I am not opposed to innovations or cross-breeding techs. My purism >> lies on simple principle: KISS. If something could be made simpler >> without losing key features then it should done. > > Your KISS principle has to come at odds with another one, which was the reason why the construct was put in place: performance. > > This is called engineering, it is the art of trade off. > So we will never agree here. We are different and having different view on it. >> >> >> >> You didn't answer the question though. >> > And then this: to the first concrete example, no complete answer >> > comes out which we could check if the code construct is indeed >> > only a syntactic sugar, or deserves incorporation in the toolset >> > of the language... >> > I don't see a need of explaining how to interpret a simple >> translation without using caseOf: statement. > > You don't, because you already decided that what it is at stake doesn't > matter for Pharo. > > I'm just trying to recap here: the construct is not here to mud the purity of a beatiful OO language nor be incentive to bad code smells. It has been put to solve a particular problem in a very specific part of the system. > nope. I suspecting that it is there to mimic C switch statement.. because some people, when discovering something new, often trying to bring everything they knew/used before. Even if it doesn't fit.. But they are loving they old toys too much for just leaving them behind. Or they faulty thinking that some cool technique that served well for them in one case, will serve as well everywhere , not depending on environment. Such people are not trying to adapt themselves to new environment, instead they trying to adapt environment for themselves. > >> >> >> > First, get rid of these integers in your code. That's the >> >> killer - yes, we can usually design around cases where >> >> we'd use case constructs (though I'm not convinced they're the >> >> spawn of the devil) but what about cases where we're interfacing >> >> with external data sources and we don't get to redesign the whole >> >> system to suit our needs? >> > FWIW, this kind of need, namely having to take alternate actions >> > due different integer codes is pretty common when interfacing with >> > industrial boards, a lot of protocols use this as well and most of >> > them are already in use, some even have international standards. >> And i suspect that all these standards are properly documented, and >> each signal/number having its description, so you can represent them >> by names, not by numbers. >> > > I may lost something, but how will you convert the numbers in names to start with? > name := numbers at: number. where numbers is dictionary/table/whatever which contains translation. Even C code using defines to represent numbers by names. So, what you prefer to see in code. This: switch (response) case 1: .. case 2: .. case 3: .. or this: #define Yes 1 #define No 2 #define NotSure 3 switch (response) case Yes: .. case No: .. case NotSure: ... and what code to your thinking having better chance to evolve and/or live longer than its original author? > >> > So the answer "redesign your world to fit our world-view" does not >> > cut in... >> > >> I'm not asking you to redesign C world to fit smalltalk view. Use >> each tool what it made for. What i asking is to not use a >> microscope for hammering nails. Hammer is much better tool for that. >> > > This statement is called in Informal Logic "the Fallacy of the False Analogy". > You may call it however you like. Just don't convince me that it is a good idea to come to lab and use microscope for hammering nails. Because its shape somewhat reminds the hammer you using in garage. >> > Also, another argument I've seen in this thread which is pretty >> >commonplace w.r.t. performance must be extirpated in our discourse: >> >"the performance x to y slower than is very good considering >> >{dynamic} languages (or similar statement)". >> > Performance counts! >> Sure. At some point if you train long enough you can hammer nail >> using microscope much faster than using hammer. But that still >> doesn't means that you doing it right :) > > As I already pointed out, your base reasoning is false, this is consequentially /non sequitur/. > > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
On 15 February 2011 20:58, Eliot Miranda <[hidden email]> wrote:
> > > On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 15 February 2011 19:59, Eliot Miranda <[hidden email]> wrote: >> > >> > >> > On Mon, Feb 14, 2011 at 11:00 PM, Stéphane Ducasse >> > <[hidden email]> 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'm not forcing you or someone else to take it out. I just don't see a need to keep it in compiler, because its not worth it. It adds too much complexity to code generation and decompilation. Maybe it will be a lot slower without compiler support. But i'd rather implement a primitive which will speed up a dictionary lookup by a factor of X, than keep supporting this huge pile of complexity in compiler. >> >> >> >> >> - 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. >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
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 > > <[hidden email]> 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. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Tue, Feb 15, 2011 at 12:39 PM, Stéphane Ducasse <[hidden email]> wrote: Eliot 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? 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"
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
2011/2/15 Eliot Miranda <[hidden email]>:
> > > On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 15 February 2011 19:59, Eliot Miranda <[hidden email]> wrote: >> > >> > >> > On Mon, Feb 14, 2011 at 11:00 PM, Stéphane Ducasse >> > <[hidden email]> 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. >> > > |
|
|
In reply to this post by Schwab,Wilhelm K
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. > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
2011/2/15 Eliot Miranda <[hidden email]>:
> > > On Tue, Feb 15, 2011 at 12:39 PM, Stéphane Ducasse > <[hidden email]> 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 >> > > <[hidden email]> 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. >> > >> > >> >> > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Tue, Feb 15, 2011 at 1:10 PM, Nicolas Cellier <[hidden email]> wrote: 2011/2/15 Eliot Miranda <[hidden email]>: 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 |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
Eliot, Now I fully understand the pain you'd have to go through (and others involved in the VM) if we'd remove this method we don't "like"... I guess it's way easier to live with #caseOf: than live without it... CogIA32Compiler>>#computeMaximumSize, when one method is worth a thousand words... Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: Eliot Miranda <[hidden email]> To: [hidden email] Sent: Tue, February 15, 2011 3:56:11 PM Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: On Tue, Feb 15, 2011 at 12:39 PM, Stéphane Ducasse <[hidden email]> wrote: Eliot 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? 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"
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
2011/2/15 Eliot Miranda <[hidden email]>:
> > > On Tue, Feb 15, 2011 at 1:10 PM, Nicolas Cellier > <[hidden email]> wrote: >> >> 2011/2/15 Eliot Miranda <[hidden email]>: >> > >> > >> > On Tue, Feb 15, 2011 at 12:39 PM, Stéphane Ducasse >> > <[hidden email]> 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. > doh, I engaged a process of generating a vm which generates a vm which generates a ... Should better read twice before posting an answer :) Nicolas |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Benoit St-Jean
On 15 February 2011 22:28, Benoit St-Jean <[hidden email]> wrote:
> Eliot, > > Now I fully understand the pain you'd have to go through (and others > involved in the VM) if we'd remove this method we don't "like"... I guess > it's way easier to live with #caseOf: than live without it... > yeah, in smalltalk you can just reify it to a lot of classes (one for each instruction) and implement #computeMaximumSize per each. Oh.. and you even don't have to do that per each.. if you look at code, it has size=6 for jumps. So, you can implement only 1 method in base 'jump' class, while others will simply reuse it. > CogIA32Compiler>>#computeMaximumSize, when one method is worth a thousand > words... > > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ________________________________ > From: Eliot Miranda <[hidden email]> > To: [hidden email] > Sent: Tue, February 15, 2011 3:56:11 PM > Subject: Re: [Pharo-project] could we agree to remove caseOf: and > caseOf:otherwise: > > > > On Tue, Feb 15, 2011 at 12:39 PM, Stéphane Ducasse > <[hidden email]> 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 >> > > <[hidden email]> 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. >> > >> > >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Benoit St-Jean
But it looks like a DSL to me.
So caseOf: could be moved to Cog. Stef On Feb 15, 2011, at 10:28 PM, Benoit St-Jean wrote: > Eliot, > > Now I fully understand the pain you'd have to go through (and others involved in the VM) if we'd remove this method we don't "like"... I guess it's way easier to live with #caseOf: than live without it... > > CogIA32Compiler>>#computeMaximumSize, when one method is worth a thousand words... > > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > From: Eliot Miranda <[hidden email]> > To: [hidden email] > Sent: Tue, February 15, 2011 3:56:11 PM > Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: > > > > On Tue, Feb 15, 2011 at 12:39 PM, Stéphane Ducasse <[hidden email]> 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 > > > <[hidden email]> 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. > > > > > > > > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
Eliot a final question.
So how will you handle OPAL compiler change in Cog? Do you require that marcus and jorge have to deal with decompiler of caseOf: in addition to all the rest? Is it a strong requirement? Because then this is clear that Opal will be delayed. But may be it is not that important after all. Just curious. Stef (if you think that I focus on details then I'm certainly an idiot). |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Stéphane Ducasse
On Tue, Feb 15, 2011 at 11:17 PM, Stéphane Ducasse <[hidden email]> wrote: But it looks like a DSL to me. No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants.
So caseOf: could be moved to Cog. Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous.
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Stéphane Ducasse
On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse <[hidden email]> wrote: Eliot a final question. OPAL is a Smalltalk compiler. I can therefore assume that it will compile Smalltalk. caseOf: is valid Smalltalk and so will be compiled by OPAL. Whether Marcus chooses to optimise caseOf: or not is up to him.
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 16 February 2011 18:15, Eliot Miranda <[hidden email]> wrote:
> > > On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse > <[hidden email]> wrote: >> >> Eliot a final question. >> So how will you handle OPAL compiler change in Cog? >> Do you require that marcus and jorge have to deal with decompiler of >> caseOf: in addition to all the rest? >> Is it a strong requirement? Because then this is clear that Opal will be >> delayed. But may be it is not that important after all. >> Just curious. > > OPAL is a Smalltalk compiler. I can therefore assume that it will compile > Smalltalk. caseOf: is valid Smalltalk and so will be compiled by OPAL. > Whether Marcus chooses to optimise caseOf: or not is up to him. And this was the question from the beginning of this thread :) Except that not all realized that Stef were talking about new compiler (Opal), not existing one. I am perfectly fine with current state of Compiler.. and it is really not worth adding/removing something from it, because in Pharo plans to integrate new compiler infrastructure. So, it is obvious that any work on old compiler is a waste of time and energy. >> >> Stef >> (if you think that I focus on details then I'm certainly an idiot). >> >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote: > > > On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse <[hidden email]> wrote: > Eliot a final question. > So how will you handle OPAL compiler change in Cog? > Do you require that marcus and jorge have to deal with decompiler of caseOf: in addition to all the rest? > Is it a strong requirement? Because then this is clear that Opal will be delayed. But may be it is not that important after all. > Just curious. > > OPAL is a Smalltalk compiler. I can therefore assume that it will compile Smalltalk. caseOf: is valid Smalltalk and so will be compiled by OPAL. Whether Marcus chooses to optimise caseOf: or not is up to him. This is exactly my point. > > > Stef > (if you think that I focus on details then I'm certainly an idiot). > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |