Float>>@ primitive fails

Float>>@ yCoord
"Answer a Point with the receiver as X and the argument as Y.
The traditional Make Point primitive is present because this operation may
be
performed a few thousand times when opening a complex window (for example).
The primitive is simply a VM level implementation of #x:y:, and does not
fail."
<primitive: 157>
^Point x: self y: yCoord

Why does this primitive fail?  The comment says that is does not.


Shaping

Shaping wrote:

> Why does this primitive fail?  The comment says that is does not.

I'm not convinced it ever /doesn't/ fail -- even with SmallInteger parameters.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:422304b0$2$38041$[hidden email]...
> Shaping wrote:
>
>> Why does this primitive fail?  The comment says that is does not.
>
> I'm not convinced it ever /doesn't/ fail -- even with SmallInteger
> parameters.


 Float>>@ yCoord
> "Answer a Point with the receiver as X and the argument as Y.
> The traditional Make Point primitive is present because this operation may
> be
> performed a few thousand times when opening a complex window (for
> example).
> The primitive is simply a VM level implementation of #x:y:, and does not
> fail."
> <primitive: 157>
> ^Point x: self y: yCoord

To be clear, I saw the debugger execute every bit of

  ^Point x: self y: yCoord.

on repeated occasions.


Shaping

Sorry, I misread.  Is there a way to make this primitive work?  Speed
matters these days.


Shaping

> Sorry, I misread.  Is there a way to make this primitive work?  Speed
> matters these days.

Just a guess based on the Squeak VM, but it might be stubbed with a
function call that fails the primitive.  Since it falls out to Smalltalk
code, one would have to look for it.  If my guess is correct, OA would
have to modify and recompile the VM to make it work.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Shaping wrote:

> To be clear, I saw the debugger execute every bit of
>
>   ^Point x: self y: yCoord.
>
> on repeated occasions.

Yes, that's what I see too.  Thinking about it more, I'm starting to suspect
that the comment is entirely wrong, and that Number>>@ doesn't have a primitive
implementation at all.  Its using the same primitive number, <157>, as Point
class>>x:y: -- which seems odd to me.  OTOH, removing the primitive actually
slows the @ operation down a little -- from 233 to 253 nanoseconds on my
machine (compared with 113 for Point class>>x:y:), so it must be doing
/something/ ;-)

    -- chris

Chris,

> Yes, that's what I see too.  Thinking about it more, I'm starting to suspect
> that the comment is entirely wrong, and that Number>>@ doesn't have a primitive
> implementation at all.  Its using the same primitive number, <157>, as Point
> class>>x:y: -- which seems odd to me.

Could it be looking at a reasonable byte size and/or number of instance
variables and transforming that many integers, or something like that?
(Please descramble the preceeding text into something that makes
sense<g>).  Anyway, I would expect that SmallInteger is the most likley
class to benefit from a quick way to create points.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]