June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo4] Slots: Code Generation and an Example

by stepharo

This is so cool. I remember when we played one afternoon in 2008 to see if this interplay would work. Stef On 27/6/14 10:19, Marcus Denker wrote: > Hi, > > So now Opal delegates code generation for read and write to the Slot meta objects. > The methods called are #emitValue: and #emitStore:, the parameter is an IRBuilder. > > With this the implementor of a Slot is free to generate whatever bytecode needed, it will > be inlined at the read or assignment site in the method. > > For the ivar Slot this is e.g. just > > emitStore: methodBuilder > > methodBuilder storeInstVar: index > > emitValue: methodBuilder > > methodBuilder pushInstVar: index. > > > Now the implementors of Slots should not need to be bothered about bytecode, therefore we have > in the superclass of all Slots defaults emit methods that implement a*reflective* read and write using > the MOP of the Slot itself (slower than code generation, but often enough): > > emitValue: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #read: > > emitStore: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #writeToSlot:of: > > > What this means is that for someone who wants to implement a slot, you do not have to deal with bytecode at all. > > Here is a simple Slot: > > Slot subclass: #TestSlot > instanceVariableNames: 'value' > classVariableNames: '' > category: 'Slot-Scopeâ > > > read: anObject > ^ value > > write: aValue to: anObject > value := aValue > > > So this is a strange kind of Slot that stores the value in itself, which means it is shared between all objects as there is only > one Slot meta object per class per slot. (not something you want to do in real world, but a nice demo) > > Now we can create a class (not yet easily as we have not yet enabled a class template, so lets use the ClassBuilder directly): > > PharoClassInstaller make: [ :builder | > builder name: #A; > slots: { TestSlot named: #iv }; > category: #Playground ]. > > > In class A we can implement accessors: > > iv > ^iv > > iv: anObject > iv := anObject > > > They look like normal ivar accesses, but in the background, the compiler delegated to the Slot the code generation, calling emit*, which leads > to the bytecode e.g. for the read: > > 21 <20> pushConstant: iv => TestSlot > 22 <70> self > 23 <E1> send: read: > 24 <7C> returnTop > > you could override the emit* methods to generate faster code, but to get something running it is not needed. > > To test, e.g. you can set the slot from one object and read it from another: > > A new iv: 6 > A new iv > > Then inspect the slot: > > (A slotNamed: #iv) inspect > > (this should all Work in 4.0 048, the example is there as TestSlot for now) > > ...next steps: > > 1) Class Definition template for classes with Slots > 2) How do we save these classes in Monticello? > 3) Virtual Slots (Boolean and PropertySlots) > > > Marcus

June 28, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Esteban A. Maringolo

2014-06-27 16:51 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Double dispatching is not always an option. >> :) > And it doesn't work in this case? Absolutely does work, it screams "double dispatch me!" using FillStyle as intermediary :) Regards! -- Esteban

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Eliot Miranda

On Fri, Jun 27, 2014 at 12:38 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > 2014-06-27 16:31 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo > > <emaringolo(a)gmail.com> wrote: > > >> Because Smalltalk lacks a "switch/case" control flow structure? :) > > and of course it has one that works just fine. > > Really? Which one? > > Or are you referring to this code pattern? > (a = 1) ifTrue: [^...]. > (a = 2) ifTrue: [^...]. > (a = 3) ifTrue: [^...]. > > Double dispatching is not always an option. > :) > And it doesn't work in this case? -- best, Eliot

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Sven Van Caekenberghe

he is referring to #caseOf: and #caseOf:otherwise: which are a bit controversial ;-) On 27 Jun 2014, at 21:38, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-06-27 16:31 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo >> <emaringolo(a)gmail.com> wrote: > >>> Because Smalltalk lacks a "switch/case" control flow structure? :) >> and of course it has one that works just fine. > > Really? Which one? > > Or are you referring to this code pattern? > (a = 1) ifTrue: [^...]. > (a = 2) ifTrue: [^...]. > (a = 3) ifTrue: [^...]. > > Double dispatching is not always an option. > :) > > > Esteban A. Maringolo >

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Esteban A. Maringolo

2014-06-27 16:31 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> Because Smalltalk lacks a "switch/case" control flow structure? :) > and of course it has one that works just fine. Really? Which one? Or are you referring to this code pattern? (a = 1) ifTrue: [^...]. (a = 2) ifTrue: [^...]. (a = 3) ifTrue: [^...]. Double dispatching is not always an option. :) Esteban A. Maringolo

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Eliot Miranda

On Fri, Jun 27, 2014 at 11:58 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > Because Smalltalk lacks a "switch/case" control flow structure? :) > and of course it has one that works just fine. Esteban A. Maringolo > > > 2014-06-27 15:42 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > I always wondering how anybody can write such code with smalltalk > > > > > > 2014-06-26 0:43 GMT+04:00 stepharo <stepharo(a)free.fr>: > Steph, it begs for double-dispatching. So why shoot InfiniteForm instead of fixing the code/ It makes no sense to me. Double-dispatching is a pattern you know well. Apply it here. > > > >> because when I see code like that, it makes me sick! > >> I wonder also when we migrate to Athens if we will not rewrite all that > >> anyway. > >> > >> fillRectangle: aRectangle basicFillStyle: aFillStyle > >> "Fill the given rectangle with the given, non-composite, fill > style." > >> > >> | pattern | > >> > >> (aFillStyle isKindOf: InfiniteForm) ifTrue: [ > >> ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle > >> ]. > >> > >> (aFillStyle isSolidFill) > >> ifTrue:[^self fillRectangle: aRectangle color: aFillStyle > >> asColor]. > >> > >> "We have a very special case for filling with infinite forms" > >> (aFillStyle isBitmapFill and:[aFillStyle origin = (0@0)]) ifTrue:[ > >> pattern := aFillStyle form. > >> (aFillStyle direction = (pattern width @ 0) > >> and:[aFillStyle normal = (0@pattern height)]) ifTrue:[ > >> "Can use an InfiniteForm" > >> ^self fillRectangle: aRectangle color: (InfiniteForm > with: > >> pattern)]. > >> ]. > >> "Use a BalloonCanvas instead" > >> self balloonFillRectangle: aRectangle fillStyle: aFillStyle. > >> > > > > -- best, Eliot

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Esteban A. Maringolo

Because Smalltalk lacks a "switch/case" control flow structure? :) Esteban A. Maringolo 2014-06-27 15:42 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I always wondering how anybody can write such code with smalltalk > > > 2014-06-26 0:43 GMT+04:00 stepharo <stepharo(a)free.fr>: > >> because when I see code like that, it makes me sick! >> I wonder also when we migrate to Athens if we will not rewrite all that >> anyway. >> >> fillRectangle: aRectangle basicFillStyle: aFillStyle >> "Fill the given rectangle with the given, non-composite, fill style." >> >> | pattern | >> >> (aFillStyle isKindOf: InfiniteForm) ifTrue: [ >> ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle >> ]. >> >> (aFillStyle isSolidFill) >> ifTrue:[^self fillRectangle: aRectangle color: aFillStyle >> asColor]. >> >> "We have a very special case for filling with infinite forms" >> (aFillStyle isBitmapFill and:[aFillStyle origin = (0@0)]) ifTrue:[ >> pattern := aFillStyle form. >> (aFillStyle direction = (pattern width @ 0) >> and:[aFillStyle normal = (0@pattern height)]) ifTrue:[ >> "Can use an InfiniteForm" >> ^self fillRectangle: aRectangle color: (InfiniteForm with: >> pattern)]. >> ]. >> "Use a BalloonCanvas instead" >> self balloonFillRectangle: aRectangle fillStyle: aFillStyle. >> >

June 27, 2014

Re: [Pharo-dev] Do we remove infiniteForm support?

by Denis Kudriashov

I always wondering how anybody can write such code with smalltalk 2014-06-26 0:43 GMT+04:00 stepharo <stepharo(a)free.fr>: > because when I see code like that, it makes me sick! > I wonder also when we migrate to Athens if we will not rewrite all that > anyway. > > fillRectangle: aRectangle basicFillStyle: aFillStyle > "Fill the given rectangle with the given, non-composite, fill style." > > | pattern | > > (aFillStyle isKindOf: InfiniteForm) ifTrue: [ > ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle > ]. > > (aFillStyle isSolidFill) > ifTrue:[^self fillRectangle: aRectangle color: aFillStyle asColor]. > > "We have a very special case for filling with infinite forms" > (aFillStyle isBitmapFill and:[aFillStyle origin = (0@0)]) ifTrue:[ > pattern := aFillStyle form. > (aFillStyle direction = (pattern width @ 0) > and:[aFillStyle normal = (0@pattern height)]) ifTrue:[ > "Can use an InfiniteForm" > ^self fillRectangle: aRectangle color: (InfiniteForm with: > pattern)]. > ]. > "Use a BalloonCanvas instead" > self balloonFillRectangle: aRectangle fillStyle: aFillStyle. > >

June 27, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

you are very fast, great work Damien ! On Fri, Jun 27, 2014 at 7:31 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Fri, Jun 27, 2014 at 3:19 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > finished Chapter 4. Damien your automatic conversion tool worked very > well > > for me, it has been a huge boost to my workflow, there are problems with > it > > that I keep reporting to its github repo . I definitely see if these > minor > > problems are removed that the automatic conversion will do 90% of the > work > > for you. I am sure these problems will be fixed very soon. > > > I've fixed all your conversion bugs. The only remaining problem is for > Emacs syntax highlighting. > > Thank you for reporting > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

June 27, 2014

Re: [Pharo-dev] Some assembly for a friday afternoon

by Igor Stasenko

Don't compare with smalltalk, compare with C! :) On 27 June 2014 19:23, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Impressive numbers and a nice examplz to grasp lots of NB/Asm details. > Le 27 juin 2014 18:55, "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> a > Ã©crit : > > > > > Soo, I started dabbling with the thing I talked about before last > summer, letting String parameters in NB calls have an encoding: option. > > (Thereâs already a slice in inbox to allow optional values other than > true/false) > > > > Thought Iâd start with decoding; hereâs a small preview of the part > which does the actual decoding, after needed string class has has been > determined and instantiated. > > While itâs a fallback path for when the platform doesnât support SSE or > other batch operations, itâs still using some neat tricks (imho) I thought > others might enjoy on a Friday afternoon :) > > > > emitStandardDecodeUTF8CharactersFrom: aSource to: aDestination > withCharSize: aCharSize scratchReg: scratchReg using: aGenerator > > "Emit decoding using only standard x86 ops" > > "We have already found what String class is needed for decoding > aSource, and created an instance of the proper size" > > "This implementation focuses on minimizing jumps and register > usage, at the cost of loading from source one byte at a time. > > "Input: > > aSource - memory pointer to C-string with UTF8 bytes > > aDestination - memoryPointer to first var field of > String instance > > scratchReg - a register which will be modified while > decoding > > > > aCharSize - The size in bytes of each character in our > destination string, known at emission time > > > > Clobbers: scratchReg > > aSource and aDestination will end up pointing to end of strings" > > > > | asm scratch32 sLowByte sHighByte loop done oneByte twoBytes > threeBytes | > > > > asm := aGenerator asm. > > loop := asm uniqueLabelName: 'utf8DecodeLoop'. > > done := asm uniqueLabelName: 'utf8DecodingDone'. > > scratch32 := scratchReg as32. > > sLowByte := scratch32 as8. > > sHighByte := sLowByte asHighByte. > > > > asm label: loop. > > "Unroll the inner loop as many times as we want, or, well, at > least as many times as the backwards jump will allow us to" > > 8 timesRepeat:[ > > oneByte := asm uniqueLabelName: 'utf8OneByteDecode'. > > twoBytes := asm uniqueLabelName: 'utf8TwoByteDecode'. > > threeBytes := asm uniqueLabelName: 'utf8ThreeByteDecode'. > > asm xor: scratch32 with:scratch32. > > asm or: sLowByte with: aSource ptr8. > > asm cmp: sLowByte with: 0. > > asm je: done. > > asm add: aSource with: 1. > > asm test: sLowByte with: 2r10000000 asUImm8. > > asm jz: oneByte. > > "We have a header, place its data bits as initial high byte > value" > > asm shl: scratch32 with: 8. > > asm xor: sHighByte with: 2r11000000 asUImm8. "Strip 2 byte > header" > > asm test: sHighByte with: 2r00100000. > > asm jz: twoBytes. > > aCharSize > 1 ifTrue: [ > > asm xor: sHighByte with: 2r00100000. "Strip 3 byte header" > > asm test: sHighByte with: 2r000100000. > > asm jz: threeBytes. > > "This is a 4-byte character" > > asm xor: sHighByte with:2r00010000."Strip 4 byte header" > > "Read one trailing byte, remove the header, and shift the data > out of low byte" > > asm or: sLowByte with: aSource ptr8. > > asm shl: sLowByte with:2. > > asm shl: scratch32 with: 6. > > asm add: aSource with: 1. > > asm label: threeBytes. > > "Read one trailing byte, remove the header, and shift the data > out of low byte" > > asm or: sLowByte with: aSource ptr8. > > asm shl: sLowByte with:2. > > asm shl: scratch32 with: 6. > > asm add: aSource with: 1. > > ]. > > asm label: twoBytes. > > "Read last trailing byte, remove header, and shift the data bits > into proper place" > > asm or: sLowByte with: aSource ptr8. > > asm shl: sLowByte with:2. > > asm shr: scratch32 with: 2. > > asm add: aSource with: 1. > > asm label: oneByte. > > asm mov: (aDestination ptr size: aCharSize) with: (scratch32 as: > aCharSize). > > asm add: aDestination with: aCharSize.]. > > asm jmp: loop. > > asm label: done. > > > > And the relevant test code for that: > > > > testStandardDecodeWide > > | bytes string | > > "bytes := (ZnUTF8Encoder new encodeString: 'Cash, like â¬, is > king'), #[0]." > > bytes := #[67 97 115 104 44 32 108 105 107 101 32 226 130 172 44 > 32 105 115 32 107 105 110 103 0]. > > string := WideString new: bytes size - 1. > > self testStandardDecode: bytes toWideString: string. > > ^ string > > > > testStandardDecode: utf8Bytes toWideString:aString > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ self nbCallout > > function: #(void #(char* utf8Bytes, char* aString )) > > emit: [ :gen :proxy :asm | > > asm pop: asm EBX; > > pop: asm ECX. > > self emitStandardDecodeUTF8CharactersFrom: asm > EBX to: asm ECX withCharSize: 4 scratchReg: asm EAX using: gen. > > asm mov: EAX with: gen proxy nilObject ] > > > > Which, though itâs currently cheating by pre-knowledn string class/size, > isnât alot of overhead: > > ext := NBExternalString new. > > [ext testStandardDecodeWide] bench '5,030,000 per second.' '5,080,000 > per second.' '5,190,000 per second.â > > Compared to an equivalent to testStandardDecodeWide, with emitStandardâ¦ > removed from the primitive: > > [ext testEmptyDecode] bench '5,850,000 per second.' '5,800,000 per > second.' '5,640,000 per second.' > > > > â¦ or compared to doing the decoding in image after the call: > > int := ZnUTF8Encoder new. > > [int decodeBytes:#[67 97 115 104 44 32 108 105 107 101 32 226 130 172 44 > 32 105 115 32 107 105 110 103 0]] bench '130,000 per second.' '131,000 per > second.' '132,000 per second.â > > > > Cheers, > > Henry > > > > -- Best regards, Igor Stasenko.

June 27, 2014