So who broke bitOr: ?

On a fresh Pi vm (as in svn updated yesterday)
16rFFFF bitOr:(16rFFFF bitShift: 16) ->  -1
On a slightly older Mac vm
16rFFFF bitOr:(16rFFFF bitShift: 16) ->  4294967295, aka 16rFFFFFFFF

This breaks, amongst other things, Color>bitPatternForDepth:, whcih pretty much trashes an image since that gets used to makes cursor bitmaps as you move the pointer around. Nicely fills your window with notifiers…

So come along; hands up the boy that did that! I’ll keep you all in late unless someone confesses. It’s only your own time you’re wasting! Was it *you* Molesworth?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PBC: Print and Break Chain

On 18.02.2015, at 12:06, tim Rowledge <[hidden email]> wrote:

> On a fresh Pi vm (as in svn updated yesterday)
> 16rFFFF bitOr:(16rFFFF bitShift: 16) ->  -1
> On a slightly older Mac vm
> 16rFFFF bitOr:(16rFFFF bitShift: 16) ->  4294967295, aka 16rFFFFFFFF

Uggh. Disgusting.

What exactly is a "fresh Pi VM"?

- Bert -

On 18-02-2015, at 12:15 PM, Bert Freudenberg <[hidden email]> wrote:

> On 18.02.2015, at 12:06, tim Rowledge <[hidden email]> wrote:
>
>> On a fresh Pi vm (as in svn updated yesterday)
>> 16rFFFF bitOr:(16rFFFF bitShift: 16) ->  -1
>> On a slightly older Mac vm
>> 16rFFFF bitOr:(16rFFFF bitShift: 16) ->  4294967295, aka 16rFFFFFFFF
>
> Uggh. Disgusting.
>
Exactly. And I should probably add that a few-week-old Pi vm got it right, so it’s a recent change.


> What exactly is a "fresh Pi VM”?

Uh, a freshly built vm for a Raspberry Pi? As in the things that have not only now sold 5m, but about 500,00 in the last 3 weeks, almost all Pi 2 … they’re taking over the planet I tell you!


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MW: Multiply Work

Also pretty sure that
16rFFFF0000 bitAnd: 16rFFFFFFFF should be  16rFFFF0000 and not -65536

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Motie Warriors does it take to change a lightbulb?”
"None. One of the dead ones will do it."

I meant that quite literally. As in, what's the output of "Smalltalk vmVersion"?

- Bert -

On Wed, Feb 18, 2015 at 12:06:41PM -0800, tim Rowledge wrote:
>
> On a fresh Pi vm (as in svn updated yesterday)
> 16rFFFF bitOr:(16rFFFF bitShift: 16) ->  -1
> On a slightly older Mac vm
> 16rFFFF bitOr:(16rFFFF bitShift: 16) ->  4294967295, aka 16rFFFFFFFF
>
> This breaks, amongst other things, Color>bitPatternForDepth:, whcih pretty much trashes an image since that gets used to makes cursor bitmaps as you move the pointer around. Nicely fills your window with notifiers?
>

It looks like a type declaration and/or slang inlining issue. Back up
a few versions in VMMaker.oscog and you will probably find the cause.

Eliot has been doing a lot of work related to 64-bit immediates, and you
may be running some version that introduces a bug in the 32-bit variation
(just guessing).

Dave

On Feb 18, 2015, at 5:21 PM, "David T. Lewis" <[hidden email]> wrote:

Mea culpa.  In getting 64-bit Sour working I broke Slang and that broke the bit logic primitives.  I just committed a working VMMaker.oscog.

Tim, Bert's question was germane.  The oscog VM was broken, not the interpreter one, and you could have said "freshly generated from VMMaker.oscog-???.nnn" ;-)


> Dave
>

On 18-02-2015, at 2:47 PM, Bert Freudenberg <[hidden email]> wrote:
>
> I meant that quite literally. As in, what's the output of "Smalltalk vmVersion”?

Well duh. I was in a hurry, completely misread and mis-answered. English is such a fun language.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Quality assurance: A way to ensure you never deliver shoddy goods accidentally.

On 18-02-2015, at 7:56 PM, Eliot Miranda <[hidden email]> wrote:
> Mea culpa.  In getting 64-bit Sour working I broke Slang and that broke the bit logic primitives.  I just committed a working VMMaker.oscog.

Fired up a vmmaker image as built by your script, updated  to oscog-eem1071.
Ran VMMaker generateConfiguration
        - attempted Squeak Stack VM (for Pi)
        - Boom!
        - attempted Squeak Spur Stack VM
        - seemed to generate ok.

So maybe it produces a working spur vm but it doesn’t seem to want to make a non-spur one!

The problem with the plain stack vm appears to be to do with
CCodeGenerator>sizeOfIntegralCType: which complained about #void. In translating NewObjectMemory>fwdTableInit: the ‘sendNode args first’ is ‘self baseHeaderSize’ and the result of -
        argType := self typeFor: sendNode args first self baseHeaderSize in: aTMethod.
is #void. That doesn’t seem quite right though since ObjectMemory>baseHeaderSIze is returning something -  though I can’t help noticing that a method

ObjectMemory>baseHeaderSize
"To support SmartSyntaxPluginCodeGenerator"
        ^self baseHeaderSize

.. somehow looks a touch *odd*. Can’t quite put my finger on it…

If I do the obvious and ugly hack of making #baseHeaderSize just return 4, then the codegen completes. I wonder if it will make a working vm?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Klingon Code Warrior:- 6) "Our competitors are without honor!"

On 19-02-2015, at 2:08 PM, tim Rowledge <[hidden email]> wrote:
> If I do the obvious and ugly hack of making #baseHeaderSize just return 4, then the codegen completes. I wonder if it will make a working vm?
So far, so good. A properly principled solution would clearly be nicer but at least it ain’t in-yer-face broken anymore.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- APRES MOE LE DELUGE - Larry and Curly get wet