Signed at:[put:] primitives for bits classes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Signed at:[put:] primitives for bits classes

Eliot Miranda-2
 
Hi All,

    right now we have a lot of different at:[put:] primitive variations.  Spur supports 8 bit (variableByteSubclass:), 16 bit (variableDoubleByteSubclass:), 32 bit (variableWordSubclass:) and 64 bit (variableDoubleWordSubclass:) formats natively.  V3 supports only 8 & 32 bit.  This message is about simplifying things in Spur.

The primitives at: 60 & at:put: 61, provide unsigned access to 8, 16, 32 & 64 bit formats.  These primitives are implemented in the JIT for maximum performance.

The primitives at: 63 & at:put: 64, provide Character access to 8, 16, & 32 bit formats (characters are in the range 0 to 2^30 - 1).  These primitives are implemented in the JIT for maximum performance.

The primitives at: 143 & at:put: 144 provide 16-bit signed access to bits classes, irrespective of format.  These are used to implement 16-bit sound samples above the 32 bit (variableWordSubclass:) format.  These primitives have no JIT implementation.

The primitives at: 165 at:put: 165 provide 32-bit signed access bits classes, irrespective of format.  These are used to implement various 32-bit signed 2's complement tables above the 32 bit (variableWordSubclass:) format.  These primitives have no JIT implementation.

Since primitives 143 & 144 don't respect the format of the underlying instance their semantics are effectively locked down.  But since, in current usage, 164 & 165 match the formats of the classes in which they're implemented, and I'm unaware of any abuses, these could be extended.

I propose extending the semantics of 164 & 165 so that they match 60 & 61, except that they provide signed access to 8, 16, 32 & 64 bit pure bits formats, and providing JIT implementations for maximum performance.  Doing so should be easy; they are very close to the JIT implementations of 60 & 61.

Once this is done we could eliminate use of 143 & 144 if we changed SoundBuffer to use primitives 164 & 165 and to have a variableDoubleWordSubclass: format.

Objections?

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Signed at:[put:] primitives for bits classes

timrowledge
 


> On 20-06-2018, at 11:46 AM, Eliot Miranda <[hidden email]> wrote:
>
> I propose extending the semantics of 164 & 165 so that they match 60 & 61, except that they provide signed access to 8, 16, 32 & 64 bit pure bits formats, and providing JIT implementations for maximum performance.  Doing so should be easy; they are very close to the JIT implementations of 60 & 61.
>
> Once this is done we could eliminate use of 143 & 144 if we changed SoundBuffer to use primitives 164 & 165 and to have a variableDoubleWordSubclass: format.

Sounds like a sensible simplification to me; less code is better code in general! How many releases should we go through before removing 143/4 ?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Do files get embarrassed when they get unzipped?


Reply | Threaded
Open this post in threaded view
|

Re: Signed at:[put:] primitives for bits classes

Eliot Miranda-2
 
Hi Tim,

On Wed, Jun 20, 2018 at 12:24 PM, tim Rowledge <[hidden email]> wrote:
 


> On 20-06-2018, at 11:46 AM, Eliot Miranda <[hidden email]> wrote:
>
> I propose extending the semantics of 164 & 165 so that they match 60 & 61, except that they provide signed access to 8, 16, 32 & 64 bit pure bits formats, and providing JIT implementations for maximum performance.  Doing so should be easy; they are very close to the JIT implementations of 60 & 61.
>
> Once this is done we could eliminate use of 143 & 144 if we changed SoundBuffer to use primitives 164 & 165 and to have a variableDoubleWordSubclass: format.

Sounds like a sensible simplification to me; less code is better code in general! How many releases should we go through before removing 143/4 ?

I don't think it's pressing to remove them.  They're not very complex and they're layered on top of existing Interpreter support for at:put: (commonAt et al).

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Signed at:[put:] primitives for bits classes

timrowledge
 


> On 20-06-2018, at 12:53 PM, Eliot Miranda <[hidden email]> wrote:
>
>> Sounds like a sensible simplification to me; less code is better code in general! How many releases should we go through before removing 143/4 ?
>>
> I don't think it's pressing to remove them.  They're not very complex and they're layered on top of existing Interpreter support for at:put: (commonAt et al).

I guess not; think of it more as a general faint whine about wanting to remove as much as possible in order to simplify something or other, reduce cognitive load for us old people, things were better in my day, git orff moi lawn!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
May the bugs of many programs nest on your hard drive.


Reply | Threaded
Open this post in threaded view
|

Re: Signed at:[put:] primitives for bits classes

David T. Lewis
In reply to this post by Eliot Miranda-2
 
On Wed, Jun 20, 2018 at 11:46:26AM -0700, Eliot Miranda wrote:

>  
> Hi All,
>
>     right now we have a lot of different at:[put:] primitive variations.
> Spur supports 8 bit (variableByteSubclass:), 16 bit
> (variableDoubleByteSubclass:), 32 bit (variableWordSubclass:) and 64 bit
> (variableDoubleWordSubclass:) formats natively.  V3 supports only 8 & 32
> bit.  This message is about simplifying things in Spur.
>
> The primitives at: 60 & at:put: 61, provide unsigned access to 8, 16, 32 &
> 64 bit formats.  These primitives are implemented in the JIT for maximum
> performance.
>
> The primitives at: 63 & at:put: 64, provide Character access to 8, 16, & 32
> bit formats (characters are in the range 0 to 2^30 - 1).  These primitives
> are implemented in the JIT for maximum performance.
>
> The primitives at: 143 & at:put: 144 provide 16-bit signed access to bits
> classes, irrespective of format.  These are used to implement 16-bit sound
> samples above the 32 bit (variableWordSubclass:) format.  These primitives
> have no JIT implementation.
>
> The primitives at: 165 at:put: 165 provide 32-bit signed access bits
> classes, irrespective of format.  These are used to implement various
> 32-bit signed 2's complement tables above the 32 bit
> (variableWordSubclass:) format.  These primitives have no JIT
> implementation.
>
> Since primitives 143 & 144 don't respect the format of the underlying
> instance their semantics are effectively locked down.  But since, in
> current usage, 164 & 165 match the formats of the classes in which they're
> implemented, and I'm unaware of any abuses, these could be extended.
>
> I propose extending the semantics of 164 & 165 so that they match 60 & 61,
> except that they provide signed access to 8, 16, 32 & 64 bit pure bits
> formats, and providing JIT implementations for maximum performance.  Doing
> so should be easy; they are very close to the JIT implementations of 60 &
> 61.
>
> Once this is done we could eliminate use of 143 & 144 if we changed
> SoundBuffer to use primitives 164 & 165 and to have a
> variableDoubleWordSubclass: format.
>
> Objections?
>

No objection at all, but if you extend the semantics of 164 and 165 as
proposed, wouldn't you simply install those newly extended implementations
into the 143 and 144 slots such that existing senders in the image get
the expected results without knowing that you changed anything? I'm
assuming that the goal is to simplify and improve the implementation within
the VM as opposed to freeing up the numbering assignments of 143 and 144
for other purposes.

Dave
 
Reply | Threaded
Open this post in threaded view
|

Is there a smarter way to get the performance of numbered prims without the headaches? (was: Signed at:[put:] primitives for bits classes)

David T. Lewis
In reply to this post by Eliot Miranda-2
 
On Wed, Jun 20, 2018 at 12:53:29PM -0700, Eliot Miranda wrote:

>  
> On Wed, Jun 20, 2018 at 12:24 PM, tim Rowledge <[hidden email]> wrote:
> >
> > > On 20-06-2018, at 11:46 AM, Eliot Miranda <[hidden email]> wrote:
> > >
> > > I propose extending the semantics of 164 & 165 so that they match 60 & 61,
> > > except that they provide signed access to 8, 16, 32 & 64 bit pure bits
> > > formats, and providing JIT implementations for maximum performance.  Doing
> > > so should be easy; they are very close to the JIT implementations of 60 & 61.
> > >
> > > Once this is done we could eliminate use of 143 & 144 if we changed
> > > SoundBuffer to use primitives 164 & 165 and to have a
> > > variableDoubleWordSubclass: format.
> >
> > Sounds like a sensible simplification to me; less code is better code in
> > general! How many releases should we go through before removing 143/4 ?
>
> I don't think it's pressing to remove them.  They're not very complex and
> they're layered on top of existing Interpreter support for at:put:
> (commonAt et al).

Let me take this as an opportunity to issue an official RFT (Request for
Fresh Thinking).

Starting with three assertions that I claim to be true:

  1) Numbered primitives are needed for performance, required by the the JIT.

  2) Named primitives are good.

  3) Numbered primmitives are evil.

Is there some way that we might achieve the benefits of numbered primitives
for performance, while also using named primitives on the image side for
maintainability and comprehension?

In other words, could we invent some scheme whereby primitives are identified
by name in the image, and those names become associated with primitive numbers
at load time? Here, "load time" is a hand-waving reference to either "assign
the numbers at image load time" or "assign an integer primitive number at
the time of first resolving the primitive name to a function address".

In the image, named references to primitives are good. In the VM, integer
references to primitive functions are good. Is it possible to have both?

I am thinking that a solution might involve statically defined primitive
numbers assigned in #initializePrimitiveTable, augmented by dynamically
assigned primitive numbers allocated at primitive function load time.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Signed at:[put:] primitives for bits classes

Eliot Miranda-2
In reply to this post by David T. Lewis
 
Hi David,

> On Jun 20, 2018, at 4:37 PM, David T. Lewis <[hidden email]> wrote:
>
>
>> On Wed, Jun 20, 2018 at 11:46:26AM -0700, Eliot Miranda wrote:
>>
>> Hi All,
>>
>>    right now we have a lot of different at:[put:] primitive variations.
>> Spur supports 8 bit (variableByteSubclass:), 16 bit
>> (variableDoubleByteSubclass:), 32 bit (variableWordSubclass:) and 64 bit
>> (variableDoubleWordSubclass:) formats natively.  V3 supports only 8 & 32
>> bit.  This message is about simplifying things in Spur.
>>
>> The primitives at: 60 & at:put: 61, provide unsigned access to 8, 16, 32 &
>> 64 bit formats.  These primitives are implemented in the JIT for maximum
>> performance.
>>
>> The primitives at: 63 & at:put: 64, provide Character access to 8, 16, & 32
>> bit formats (characters are in the range 0 to 2^30 - 1).  These primitives
>> are implemented in the JIT for maximum performance.
>>
>> The primitives at: 143 & at:put: 144 provide 16-bit signed access to bits
>> classes, irrespective of format.  These are used to implement 16-bit sound
>> samples above the 32 bit (variableWordSubclass:) format.  These primitives
>> have no JIT implementation.
>>
>> The primitives at: 165 at:put: 165 provide 32-bit signed access bits
>> classes, irrespective of format.  These are used to implement various
>> 32-bit signed 2's complement tables above the 32 bit
>> (variableWordSubclass:) format.  These primitives have no JIT
>> implementation.
>>
>> Since primitives 143 & 144 don't respect the format of the underlying
>> instance their semantics are effectively locked down.  But since, in
>> current usage, 164 & 165 match the formats of the classes in which they're
>> implemented, and I'm unaware of any abuses, these could be extended.
>>
>> I propose extending the semantics of 164 & 165 so that they match 60 & 61,
>> except that they provide signed access to 8, 16, 32 & 64 bit pure bits
>> formats, and providing JIT implementations for maximum performance.  Doing
>> so should be easy; they are very close to the JIT implementations of 60 &
>> 61.
>>
>> Once this is done we could eliminate use of 143 & 144 if we changed
>> SoundBuffer to use primitives 164 & 165 and to have a
>> variableDoubleWordSubclass: format.
>>
>> Objections?
>>
>
> No objection at all, but if you extend the semantics of 164 and 165 as
> proposed, wouldn't you simply install those newly extended implementations
> into the 143 and 144 slots such that existing senders in the image get
> the expected results without knowing that you changed anything? I'm
> assuming that the goal is to simplify and improve the implementation within
> the VM as opposed to freeing up the numbering assignments of 143 and 144
> for other purposes.

The goal is to have the same effect as efficient JITted implementations of 143 & 144.  Given this only involves changing unsigned to signed when creating my modified versions of 60 & 61, the easiest way is to extend the semantics of 164 & 165, which also means no new primitive numbers.  They’re no longer a scarce resource, except that the vm has a single table rather than a pages table (which VW has), si keeping numbers in numbered primitive low saves work for the moment.

>
> Dave
>
Reply | Threaded
Open this post in threaded view
|

Re: Is there a smarter way to get the performance of numbered prims without the headaches? (was: Signed at:[put:] primitives for bits classes)

Florin Mateoc-4
In reply to this post by David T. Lewis
 
On 6/20/2018 10:04 PM, David T. Lewis wrote:

> Let me take this as an opportunity to issue an official RFT (Request for
> Fresh Thinking).
>
> Starting with three assertions that I claim to be true:
>
>   1) Numbered primitives are needed for performance, required by the the JIT.
>
>   2) Named primitives are good.
>
>   3) Numbered primmitives are evil.
>
> Is there some way that we might achieve the benefits of numbered primitives
> for performance, while also using named primitives on the image side for
> maintainability and comprehension?
>
> In other words, could we invent some scheme whereby primitives are identified
> by name in the image, and those names become associated with primitive numbers
> at load time? Here, "load time" is a hand-waving reference to either "assign
> the numbers at image load time" or "assign an integer primitive number at
> the time of first resolving the primitive name to a function address".
>
> In the image, named references to primitives are good. In the VM, integer
> references to primitive functions are good. Is it possible to have both?
>
> I am thinking that a solution might involve statically defined primitive
> numbers assigned in #initializePrimitiveTable, augmented by dynamically
> assigned primitive numbers allocated at primitive function load time.
>
> Dave
>

Hi Dave,

VisualAge does this by using pool variables.

The pragmas are defined through (and display) the name of the pool variables (e.g. <primitive: VMprObjectBasicAt>), but
the pool variables hold integers - say if you inspect them, you get integers

Florin

Reply | Threaded
Open this post in threaded view
|

Re: Signed at:[put:] primitives for bits classes

David T. Lewis
In reply to this post by Eliot Miranda-2
 
On Wed, Jun 20, 2018 at 07:05:38PM -0700, Eliot Miranda wrote:

>  
> Hi David,
>
> > On Jun 20, 2018, at 4:37 PM, David T. Lewis <[hidden email]> wrote:
> >
> >
> >> On Wed, Jun 20, 2018 at 11:46:26AM -0700, Eliot Miranda wrote:
> >>
> >> Hi All,
> >>
> >>    right now we have a lot of different at:[put:] primitive variations.
> >> Spur supports 8 bit (variableByteSubclass:), 16 bit
> >> (variableDoubleByteSubclass:), 32 bit (variableWordSubclass:) and 64 bit
> >> (variableDoubleWordSubclass:) formats natively.  V3 supports only 8 & 32
> >> bit.  This message is about simplifying things in Spur.
> >>
> >> The primitives at: 60 & at:put: 61, provide unsigned access to 8, 16, 32 &
> >> 64 bit formats.  These primitives are implemented in the JIT for maximum
> >> performance.
> >>
> >> The primitives at: 63 & at:put: 64, provide Character access to 8, 16, & 32
> >> bit formats (characters are in the range 0 to 2^30 - 1).  These primitives
> >> are implemented in the JIT for maximum performance.
> >>
> >> The primitives at: 143 & at:put: 144 provide 16-bit signed access to bits
> >> classes, irrespective of format.  These are used to implement 16-bit sound
> >> samples above the 32 bit (variableWordSubclass:) format.  These primitives
> >> have no JIT implementation.
> >>
> >> The primitives at: 165 at:put: 165 provide 32-bit signed access bits
> >> classes, irrespective of format.  These are used to implement various
> >> 32-bit signed 2's complement tables above the 32 bit
> >> (variableWordSubclass:) format.  These primitives have no JIT
> >> implementation.
> >>
> >> Since primitives 143 & 144 don't respect the format of the underlying
> >> instance their semantics are effectively locked down.  But since, in
> >> current usage, 164 & 165 match the formats of the classes in which they're
> >> implemented, and I'm unaware of any abuses, these could be extended.
> >>
> >> I propose extending the semantics of 164 & 165 so that they match 60 & 61,
> >> except that they provide signed access to 8, 16, 32 & 64 bit pure bits
> >> formats, and providing JIT implementations for maximum performance.  Doing
> >> so should be easy; they are very close to the JIT implementations of 60 &
> >> 61.
> >>
> >> Once this is done we could eliminate use of 143 & 144 if we changed
> >> SoundBuffer to use primitives 164 & 165 and to have a
> >> variableDoubleWordSubclass: format.
> >>
> >> Objections?
> >>
> >
> > No objection at all, but if you extend the semantics of 164 and 165 as
> > proposed, wouldn't you simply install those newly extended implementations
> > into the 143 and 144 slots such that existing senders in the image get
> > the expected results without knowing that you changed anything? I'm
> > assuming that the goal is to simplify and improve the implementation within
> > the VM as opposed to freeing up the numbering assignments of 143 and 144
> > for other purposes.
>
> The goal is to have the same effect as efficient JITted implementations
> of 143 & 144.  Given this only involves changing unsigned to signed when
> creating my modified versions of 60 & 61, the easiest way is to extend
> the semantics of 164 & 165, which also means no new primitive numbers.
> They???re no longer a scarce resource, except that the vm has a single
> table rather than a pages table (which VW has), si keeping numbers in
> numbered primitive low saves work for the moment.
>

For the proposed change to extend semantics of 164 and 165: +1, good idea.

As for changing the image to take advantage of the improvement, it would
not be good to introduce a tight coupling between the image version and
the VM version for purposes of performance unless there is a real and
measurable performance improvement. I don't know if that is the case here,
so I can't say if changing e.g. SoundBuffer>>at: to call different
primitive numbers is a good idea.

There is one sure way to find out: Try it and measure the results :-)

Dave