Hi Fabio,

On Mon, Jan 13, 2020 at 2:00 PM Fabio Niephaus <lists at fniephaus.com> wrote:

> On Mon, Jan 13, 2020 at 10:57 PM Fabio Niephaus <lists at fniephaus.com>
> 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.  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 <tim at rowledge.org> 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 <eliot.miranda at gmail.com>
> 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; tim at rowledge.org; http://www.rowledge.org/tim
> > > Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead.  No
> kidding.
> > >
> > >
> > >
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200113/246e8b64/attachment.html>