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

Re: [Pharo-project] 1.1.1 one-click-cog crash

by Nicolas Cellier

ls -ltr ? 2011/2/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I just put the 1.1.1 cog one-click on an Ubuntu 10.10 machine and got a segment fault. Â This is a machine that I did not build, and can access only via an NX client remote connection (probably not a factor). Â The sequence of events was that I had the machine download the zip, expanded it, and then double clicked the shell script - "nothing happened." Â I then ran it from a terminal and saw only Segmentation fault." Â The non-cog one click runs on the machine. > > Is there any logging that I can make available? > > Bill > > > > > > >

Feb. 15, 2011

[Pharo-project] 1.1.1 one-click-cog crash

by Schwab,Wilhelm K

Hello all, I just put the 1.1.1 cog one-click on an Ubuntu 10.10 machine and got a segment fault. This is a machine that I did not build, and can access only via an NX client remote connection (probably not a factor). The sequence of events was that I had the machine download the zip, expanded it, and then double clicked the shell script - "nothing happened." I then ran it from a terminal and saw only Segmentation fault." The non-cog one click runs on the machine. Is there any logging that I can make available? Bill

Feb. 15, 2011

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

by GÃ¶ran Krampe

On 02/14/2011 09:59 AM, Sven Van Caekenberghe wrote: > On 14 Feb 2011, at 00:18, GÃ¶ran Krampe wrote: >> Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade: >> >> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >> http://goran.krampe.se/blog/Squeak/Tirade2.rdoc >> http://goran.krampe.se/blog/Squeak/Tirade3.rdoc >> >> (sorry for lack of nice CSS there) >> >> NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver. >> >> Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver. >> >> Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure. >> >> So, given the Pros/Cons above, let's see how Tirade would fit: >> >> * Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left. >> >> * Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this: >> >> tiradeOn: recorder >> "Create Tirade by sending messages to a Tirade recorder." >> recorder message1; message2; message3 >> >> In that way you can still use senders/implementors etc of the message selectors. >> >> * Easy to store outside of the language: yes, trivial, and fast to write and read >> >> * Very resilient against framework/library changes if we use a declarative style. > > Tirade looks cool, very nice idea, simple and powerful. Nice name too. > > Some questions: > > - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? Sure! :) But it was still evolving, although slowly, when I got distracted by other things. So I hadn't come to the "let's put it in BNF stone"-phase. > - there does not seem to be a way to deal with non-ascii strings like 'GÃ¶ran', shouldn't there be something like JSON escapes ? Ehm... my memory is weak here - I actually don't know what the code does - but I agree with people saying UTF8. > - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) Sure, might be nice! :) Or one could say that in order to work nicely with "known readers" the first message could be: reader: #CoolFormatReader. ...there are endless ways to do that. > - has this since 2009 been used anywhere ? I am using it in Deltastreams (although that project is not usable yet and has been dormant) and a collegue actually used it in one of his little projects - other than that I have no idea. > - how about inter Smalltalk interoperability ? Sure, one might investigate that. If so then I think that number parsing is the most brittle part. The code is very small and I wrote it using vanilla Squeak I think so porting would probably be quite simple. > > Sven > > regards, GÃ¶ran PS. You could use Tirade for simple inter-Smalltalk communication too - since over a Socket it would constitute an RPC mechanism.

Feb. 15, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #75 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 What I've done about SHWorkspace is just a little patch. In fact this whole class can be emptied. If you want, I can take a look at the shout package, and remove useless things :) But a better solution could be to change the list of tools pushed in a core image to create a Dev one and to remove all the SH tools (for 1.3)

Feb. 15, 2011

Re: [Pharo-project] Loading Seaside into Pharo 1.2 core

by Michael Roberts

ok cool. Yes, Torsten is right that i want to load this into Core. Not just for deployment though, but i like working with smaller images. It is also a way of exercising the core image and trying to improve that code base, testing it etc. What i was really after which Dale answered was more details on the API which i was struggling with staring at the latest specs (wow!) and trying to figure it out. One 3.0.4 is published i will give that a go too. cheers, Mike On Tue, Feb 15, 2011 at 5:22 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > On 02/15/2011 01:55 AM, Torsten Bergmann wrote: >> >> Dale wrote: >>> >>> I am presently working on Seaside 3.0.4 which will correctly load into >>> Pharo1.2, >> >> According to his mail Mike wants to load it into a Pharo1.2-Core >> (maybe for minimal deployment) - not into a Pharo1.2-Developer image. > > I want to clarify that the 3.0.4 configuration _is_ intended to correctly > load into PharoCore1.2. > > Dale > >

Feb. 15, 2011

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

by Craig Latta

Hi Cesar-- > Fantastic wishlist! However, maybe because the synthetic nature of > the proposal... Well, I'm cheating here, because I've already implemented the givens (live method transfer and modules). See [1] and [2]. > ...I think I missed something: > > How can a "...a method be transferred to another live system." as per > your "4." and "Represent the state of that GUI with an object" and > even be "amenable to framework change" simultaneously? When you're done composing a GUI with an editor, you've got an object that represents the GUI, typically a hierarchy of widgets and event-handlers (perhaps similar to a VisualWorks viewspec, but an original object instead of a transcription of one). The precise nature of the objects in that hierarchy depends on your GUI framework. But whatever it is, you can transfer a method using it to another live system, because (at least in the stuff I wrote) you can transfer any method no matter what its literals are. So given that, you're dealing with first-class objects all the time. That's what makes this scheme adaptable to GUI framework change. You can examine GUI objects, ask them to convert themselves to another framework's structures, etc. with familiar Smalltalk tools. There are no "dead-data" formats to worry about, because all method literals get transferred as part of fundamental system behavior, without any special consideration by the GUI framework. thanks, -C [1] http://netjam.org/spoon (main site) [2] http://thiscontext.wordpress.com (blog) -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

Feb. 15, 2011

Re: [Pharo-project] Pharo 1.2 virtual sprint

by laurent laffont

Which day you prefer ? Laurent On Tue, Feb 15, 2011 at 10:00 AM, StÃ©phane Ducasse < Stephane.Ducasse(a)inria.fr> wrote: > If there is internet connection where I will be hacking with alain we can > participate :). > > Stef > > On Feb 14, 2011, at 10:01 PM, laurent laffont wrote: > > > Could we organize a Pharo 1.2 virtual sprint over IRC to resolve, kill, > eleminate, eradicate, destroy remaining issues ? and learn together too. > > > > I can do this next week from monday to wednesday evening (France time > zone). > > > > Laurent > > > >

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 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. > 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

Feb. 15, 2011

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

by Benoit St-Jean

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 <eliot.miranda(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr 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 <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] [COTDC] 12 - PluggableListMorphByItem

by Nicolas Cellier

2011/2/15 Igor Stasenko <siguctua(a)gmail.com>: > On 15 February 2011 19:03, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> "Essentially useless in its current form. Probably intended to eventually >> deal with actual objects in the list rather than indexing/string-forms." > > > every time i looking at those pluggableXYZ. and it always one thought > don't let me rest: > Â - we don't need them. > > They are implementing/perverting functionality of base widgets. > Because for most of them, they addding no value comparing > to base widgets, but just some extended interface(s) on top. > Totally agree with Igor. Looking at the name, it already smells like a case of composition by inheritance. It reminds me the RWBinaryOrTextStreamWhatElse hierarchy. Maybe it has some cousins like PluggableMultipleSelectionListMorphByItem PluggableTreeMorphByItem etc... ;) If Pluggability is a noble feature for a GUI to have, maybe there is no much reason to carry a HardcodedListMorphByItem... Nicolas > >> Regards, Gary >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 15, 2011