Hi All, currently the following slots in the specialObjectsArray are unused in both Squeak and Pharo (& I suspect Cuis). newArray at: 32 put: nil. "was the prototype Float" newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" newArray at: 34 put: nil. "was the prototype Point" The specialObjectsArray already contains ByteArray newArray at: 27 put: ByteArray. I would like to have a full set of little-endian unsigned integer arrays. In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is big endian), and DoubleWordArray. The VM's at:[put:] directly supports these four at the JIT level giving us efficient unsigned access. There is also efficient signed access for some signed arrays but these are less useful (at least in theVM simulator). I want to make all four unsigned integer array classs available to plugins etc via the interpreterProxy. So here's a formal request to reserve these values for use as follows: newArray at: 27 put: ByteArray. ... newArray at: 32 put: DoubleByteArray. newArray at: 33 put: WordArray. newArray at: 34 put: DoubleWordArray. _,,,^..^,,,_ best, Eliot |
Speaking from my magnificent golden embossed throne in the Great Hall of our bigly cathedral, I say unto you "go for it my son, and may you have success"
> On 2020-01-13, at 9:47 AM, Eliot Miranda <[hidden email]> wrote: > > Hi All, > > currently the following slots in the specialObjectsArray are unused in both Squeak and Pharo (& I suspect Cuis). > > newArray at: 32 put: nil. "was the prototype Float" > newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" > newArray at: 34 put: nil. "was the prototype Point" > > The specialObjectsArray already contains ByteArray > newArray at: 27 put: ByteArray. > > I would like to have a full set of little-endian unsigned integer arrays. In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is big endian), and DoubleWordArray. The VM's at:[put:] directly supports these four at the JIT level giving us efficient unsigned access. There is also efficient signed access for some signed arrays but these are less useful (at least in theVM simulator). > > I want to make all four unsigned integer array classs available to plugins etc via the interpreterProxy. So here's a formal request to reserve these values for use as follows: > newArray at: 27 put: ByteArray. > ... > newArray at: 32 put: DoubleByteArray. > newArray at: 33 put: WordArray. > newArray at: 34 put: DoubleWordArray. > > _,,,^..^,,,_ > best, Eliot > > tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead. No kidding. |
Hi Eliot,
If you believe plugins would benefit from these three classes, please go ahead. There's not too much space left in the current specialObjectsArray, but while we're talking about it: may I propose to add SmallFloat64 at index 12 ("was BlockContext"). Or how does Cog find/use this class in 64-bit images? newArray at: 10 put: BoxedFloat64. ... newArray at: 12 put: SmallFloat64. "was BlockContext." Fabio On Mon, Jan 13, 2020 at 8:22 PM tim Rowledge <[hidden email]> wrote: > > Speaking from my magnificent golden embossed throne in the Great Hall of our bigly cathedral, I say unto you "go for it my son, and may you have success" > > > > On 2020-01-13, at 9:47 AM, Eliot Miranda <[hidden email]> wrote: > > > > Hi All, > > > > currently the following slots in the specialObjectsArray are unused in both Squeak and Pharo (& I suspect Cuis). > > > > newArray at: 32 put: nil. "was the prototype Float" > > newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" > > newArray at: 34 put: nil. "was the prototype Point" > > > > The specialObjectsArray already contains ByteArray > > newArray at: 27 put: ByteArray. > > > > I would like to have a full set of little-endian unsigned integer arrays. In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is big endian), and DoubleWordArray. The VM's at:[put:] directly supports these four at the JIT level giving us efficient unsigned access. There is also efficient signed access for some signed arrays but these are less useful (at least in theVM simulator). > > > > I want to make all four unsigned integer array classs available to plugins etc via the interpreterProxy. So here's a formal request to reserve these values for use as follows: > > newArray at: 27 put: ByteArray. > > ... > > newArray at: 32 put: DoubleByteArray. > > newArray at: 33 put: WordArray. > > newArray at: 34 put: DoubleWordArray. > > > > _,,,^..^,,,_ > > best, Eliot > > > > > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead. No kidding. > > > |
On Mon, Jan 13, 2020 at 10:57 PM Fabio Niephaus <[hidden email]> wrote:
> > Hi Eliot, > > If you believe plugins would benefit from these three classes, please > go ahead. There's not too much space left in the current > specialObjectsArray, but while we're talking about it: may I propose > to add SmallFloat64 at index 12 ("was BlockContext"). Or how does Cog > find/use this class in 64-bit images? Just had a look and it looks like Cog relies on the class to be at a fixed index in classTableFirstPage: classSmallFloat <api> ^self fetchPointer: self smallFloatTag ofObject: classTableFirstPage Not sure this is a clean solution? > > newArray at: 10 put: BoxedFloat64. > ... > newArray at: 12 put: SmallFloat64. "was BlockContext." > > > Fabio > > On Mon, Jan 13, 2020 at 8:22 PM tim Rowledge <[hidden email]> wrote: > > > > Speaking from my magnificent golden embossed throne in the Great Hall of our bigly cathedral, I say unto you "go for it my son, and may you have success" > > > > > > > On 2020-01-13, at 9:47 AM, Eliot Miranda <[hidden email]> wrote: > > > > > > Hi All, > > > > > > currently the following slots in the specialObjectsArray are unused in both Squeak and Pharo (& I suspect Cuis). > > > > > > newArray at: 32 put: nil. "was the prototype Float" > > > newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" > > > newArray at: 34 put: nil. "was the prototype Point" > > > > > > The specialObjectsArray already contains ByteArray > > > newArray at: 27 put: ByteArray. > > > > > > I would like to have a full set of little-endian unsigned integer arrays. In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is big endian), and DoubleWordArray. The VM's at:[put:] directly supports these four at the JIT level giving us efficient unsigned access. There is also efficient signed access for some signed arrays but these are less useful (at least in theVM simulator). > > > > > > I want to make all four unsigned integer array classs available to plugins etc via the interpreterProxy. So here's a formal request to reserve these values for use as follows: > > > newArray at: 27 put: ByteArray. > > > ... > > > newArray at: 32 put: DoubleByteArray. > > > newArray at: 33 put: WordArray. > > > newArray at: 34 put: DoubleWordArray. > > > > > > _,,,^..^,,,_ > > > best, Eliot > > > > > > > > > > > > tim > > -- > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > > Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead. No kidding. > > > > > > |
Hi Fabio, On Mon, Jan 13, 2020 at 2:00 PM Fabio Niephaus <[hidden email]> wrote: On Mon, Jan 13, 2020 at 10:57 PM Fabio Niephaus <[hidden email]> wrote: The point is that the immediate tag patterns map to the classes for those tag patterns. So taking the class table page as a zero-relative array 0 => nil 1 => SmallInteger - tag pattern 1 is SmallInteger in both 32 and 64 bit images) 2 => Character - tag pattern 2 is Character in both 32 and 64 bit images 3 => SmallInteger - tag pattern 3 is SmallInteger in 32 bit images (31 bit SmallIntegers) 4 => SmallFloat64 - tag pattern 4 is SmallFloat64 in 64-bit images 5 => nil 6 => nil 7 => nil And so the class of an immediate is obtained by indexing the classTableFirstPage with its tag pattern. Note also that in 64-bits testing for SmallInteger, Character and SmallFloat64 are single bit tests. One does not need to do e.g. (oop asInteger bitAnd: 7) = 2 to identify a Character; one can simply do oop asInteger anyMask: 2. I would describe this as clean simple and efficient. What strikes you as unclean about it?
There is no need to provide the immediate classes; ione never synthesizes their instances via their class object. One synthesizes using their tag pattern. I'm wanting to use index 12 for WideString, which is far more useful inside a plugin, given that we already have constructor functions for integer, character and float immediates. > _,,,^..^,,,_ best, Eliot |
On Tue, Jan 14, 2020 at 12:23 AM Eliot Miranda <[hidden email]> wrote:
> > Hi Fabio, > > On Mon, Jan 13, 2020 at 2:00 PM Fabio Niephaus <[hidden email]> wrote: >> >> On Mon, Jan 13, 2020 at 10:57 PM Fabio Niephaus <[hidden email]> wrote: >> > >> > Hi Eliot, >> > >> > If you believe plugins would benefit from these three classes, please >> > go ahead. There's not too much space left in the current >> > specialObjectsArray, but while we're talking about it: may I propose >> > to add SmallFloat64 at index 12 ("was BlockContext"). Or how does Cog >> > find/use this class in 64-bit images? >> >> Just had a look and it looks like Cog relies on the class to be at a >> fixed index in classTableFirstPage: >> >> classSmallFloat >> <api> >> ^self fetchPointer: self smallFloatTag ofObject: classTableFirstPage >> >> Not sure this is a clean solution? > > > The point is that the immediate tag patterns map to the classes for those tag patterns. So taking the class table page as a zero-relative array > > 0 => nil > 1 => SmallInteger - tag pattern 1 is SmallInteger in both 32 and 64 bit images) > 2 => Character - tag pattern 2 is Character in both 32 and 64 bit images > 3 => SmallInteger - tag pattern 3 is SmallInteger in 32 bit images (31 bit SmallIntegers) > 4 => SmallFloat64 - tag pattern 4 is SmallFloat64 in 64-bit images > 5 => nil > 6 => nil > 7 => nil > > And so the class of an immediate is obtained by indexing the classTableFirstPage with its tag pattern. Note also that in 64-bits testing for SmallInteger, Character and SmallFloat64 are single bit tests. One does not need to do e.g. (oop asInteger bitAnd: 7) = 2 to identify a Character; one can simply do oop asInteger anyMask: 2. > > I would describe this as clean simple and efficient. What strikes you as unclean about it? Thanks, Eliot. I forgot that the tag pattern correlates to the classTableFirstPage and I agree that this is indeed better than wasting another slot of specialObjectsArray. Fabio > >> >> > >> > newArray at: 10 put: BoxedFloat64. >> > ... >> > newArray at: 12 put: SmallFloat64. "was BlockContext." > > > There is no need to provide the immediate classes; ione never synthesizes their instances via their class object. One synthesizes using their tag pattern. I'm wanting to use index 12 for WideString, which is far more useful inside a plugin, given that we already have constructor functions for integer, character and float immediates. > >> > >> > >> > Fabio >> > >> > On Mon, Jan 13, 2020 at 8:22 PM tim Rowledge <[hidden email]> wrote: >> > > >> > > Speaking from my magnificent golden embossed throne in the Great Hall of our bigly cathedral, I say unto you "go for it my son, and may you have success" >> > > >> > > >> > > > On 2020-01-13, at 9:47 AM, Eliot Miranda <[hidden email]> wrote: >> > > > >> > > > Hi All, >> > > > >> > > > currently the following slots in the specialObjectsArray are unused in both Squeak and Pharo (& I suspect Cuis). >> > > > >> > > > newArray at: 32 put: nil. "was the prototype Float" >> > > > newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" >> > > > newArray at: 34 put: nil. "was the prototype Point" >> > > > >> > > > The specialObjectsArray already contains ByteArray >> > > > newArray at: 27 put: ByteArray. >> > > > >> > > > I would like to have a full set of little-endian unsigned integer arrays. In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is big endian), and DoubleWordArray. The VM's at:[put:] directly supports these four at the JIT level giving us efficient unsigned access. There is also efficient signed access for some signed arrays but these are less useful (at least in theVM simulator). >> > > > >> > > > I want to make all four unsigned integer array classs available to plugins etc via the interpreterProxy. So here's a formal request to reserve these values for use as follows: >> > > > newArray at: 27 put: ByteArray. >> > > > ... >> > > > newArray at: 32 put: DoubleByteArray. >> > > > newArray at: 33 put: WordArray. >> > > > newArray at: 34 put: DoubleWordArray. >> > > > >> > > > _,,,^..^,,,_ >> > > > best, Eliot >> > > > >> > > > >> > > >> > > >> > > tim >> > > -- >> > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> > > Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead. No kidding. >> > > >> > > >> > > >> > > > -- > _,,,^..^,,,_ > best, Eliot > |
In reply to this post by Eliot Miranda-2
> On 14.01.2020, at 00:22, Eliot Miranda <[hidden email]> wrote: > > Hi Fabio, > > On Mon, Jan 13, 2020 at 2:00 PM Fabio Niephaus <[hidden email]> wrote: > On Mon, Jan 13, 2020 at 10:57 PM Fabio Niephaus <[hidden email]> wrote: > > > > Hi Eliot, > > > > If you believe plugins would benefit from these three classes, please > > go ahead. There's not too much space left in the current > > specialObjectsArray, but while we're talking about it: may I propose > > to add SmallFloat64 at index 12 ("was BlockContext"). Or how does Cog > > find/use this class in 64-bit images? > > Just had a look and it looks like Cog relies on the class to be at a > fixed index in classTableFirstPage: > > classSmallFloat > <api> > ^self fetchPointer: self smallFloatTag ofObject: classTableFirstPage > > Not sure this is a clean solution? > > The point is that the immediate tag patterns map to the classes for those tag patterns. So taking the class table page as a zero-relative array > > 0 => nil > 1 => SmallInteger - tag pattern 1 is SmallInteger in both 32 and 64 bit images) > 2 => Character - tag pattern 2 is Character in both 32 and 64 bit images > 3 => SmallInteger - tag pattern 3 is SmallInteger in 32 bit images (31 bit SmallIntegers) > 4 => SmallFloat64 - tag pattern 4 is SmallFloat64 in 64-bit images > 5 => nil > 6 => nil > 7 => nil > > And so the class of an immediate is obtained by indexing the classTableFirstPage with its tag pattern. Note also that in 64-bits testing for SmallInteger, Character and SmallFloat64 are single bit tests. One does not need to do e.g. (oop asInteger bitAnd: 7) = 2 to identify a Character; one can simply do oop asInteger anyMask: 2. > > I would describe this as clean simple and efficient. What strikes you as unclean about it? > > > > > > newArray at: 10 put: BoxedFloat64. > > ... > > newArray at: 12 put: SmallFloat64. "was BlockContext." > > There is no need to provide the immediate classes; ione never synthesizes their instances via their class object. > One synthesizes using their tag pattern. Unless you're not the Cog VM but RSqueak, SqueakJS, or similar. Then you have no tag. :D Best regards -Tobias > I'm wanting to use index 12 for WideString, which is far more useful inside a plugin, given that we already have constructor functions for integer, character and float immediates. > > > > > > > Fabio > > > > On Mon, Jan 13, 2020 at 8:22 PM tim Rowledge <[hidden email]> wrote: > > > > > > Speaking from my magnificent golden embossed throne in the Great Hall of our bigly cathedral, I say unto you "go for it my son, and may you have success" > > > > > > > > > > On 2020-01-13, at 9:47 AM, Eliot Miranda <[hidden email]> wrote: > > > > > > > > Hi All, > > > > > > > > currently the following slots in the specialObjectsArray are unused in both Squeak and Pharo (& I suspect Cuis). > > > > > > > > newArray at: 32 put: nil. "was the prototype Float" > > > > newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger" > > > > newArray at: 34 put: nil. "was the prototype Point" > > > > > > > > The specialObjectsArray already contains ByteArray > > > > newArray at: 27 put: ByteArray. > > > > > > > > I would like to have a full set of little-endian unsigned integer arrays. In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is big endian), and DoubleWordArray. The VM's at:[put:] directly supports these four at the JIT level giving us efficient unsigned access. There is also efficient signed access for some signed arrays but these are less useful (at least in theVM simulator). > > > > > > > > I want to make all four unsigned integer array classs available to plugins etc via the interpreterProxy. So here's a formal request to reserve these values for use as follows: > > > > newArray at: 27 put: ByteArray. > > > > ... > > > > newArray at: 32 put: DoubleByteArray. > > > > newArray at: 33 put: WordArray. > > > > newArray at: 34 put: DoubleWordArray. > > > > > > > > _,,,^..^,,,_ > > > > best, Eliot > > > > > > > > > > > > > > > > > tim > > > -- > > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > > > Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead. No kidding. > > > > > > > > > |
In reply to this post by Eliot Miranda-2
Hi Eliot, Folks,
Speaking for Cuis. On 1/13/2020 2:47 PM, Eliot Miranda via Cuis-dev wrote:
Yep. The same in Cuis.
Same in Spur Cuis (if you load the optional "Collections-TwoAndEightByteArrays.pck.st" package).
Sounds good to me. Thanks, -- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev https://github.com/jvuletich https://www.linkedin.com/in/juan-vuletich-75611b3 @JuanVuletich |
In reply to this post by Eliot Miranda-2
Hi Folks,
Cuis already includes Float64Array in the base image. As usual, feel free to take the code to your preferred dialect. Primitives such those for FloatArray would be a welcome addition! Cheers, -- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev https://github.com/jvuletich https://www.linkedin.com/in/juan-vuletich-75611b3 @JuanVuletich On 1/13/2020 8:24 PM, Eliot Miranda via Cuis-dev wrote:
|
In reply to this post by Eliot Miranda-2
Hi Eliot, Folks,
Speaking for Cuis. On 1/13/2020 2:47 PM, Eliot Miranda wrote:
Yep. The same in Cuis.
Same in Spur Cuis (if you load the optional "Collections-TwoAndEightByteArrays.pck.st" package).
Sounds good to me. Thanks, -- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev https://github.com/jvuletich https://www.linkedin.com/in/juan-vuletich-75611b3 @JuanVuletich |
In reply to this post by Eliot Miranda-2
Hi Folks,
Cuis already includes Float64Array in the base image. As usual, feel free to take the code to your preferred dialect. Primitives such those for FloatArray would be a welcome addition! Cheers, -- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev https://github.com/jvuletich https://www.linkedin.com/in/juan-vuletich-75611b3 @JuanVuletich On 1/13/2020 8:24 PM, Eliot Miranda wrote:
|
Free forum by Nabble | Edit this page |