Smalltalk › Squeak › Squeak VM

Small discrepancy in fileTimesInUTC between simulation & VM

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolas Cellier

Small discrepancy in fileTimesInUTC between simulation & VM

Hi all, Eliot,

Simulation says:

^(Smalltalk vmParameterAt: 48) anyMask: 128

VM says:

^imageHeaderFlags anyMask: 512

Is the difference intentional?

David T. Lewis

Re: Small discrepancy in fileTimesInUTC between simulation & VM

On Sun, Dec 27, 2020 at 02:51:44PM +0100, Nicolas Cellier wrote:

>
> Hi all, Eliot,
>
> Simulation says:
>
> ^(Smalltalk vmParameterAt: 48) anyMask: 128
>
> VM says:
>
> ^imageHeaderFlags anyMask: 512
>
> Is the difference intentional?

Eliot will give a better answer, but I am fairly sure that this is
intentional. See StackInterpreter>>getImageHeaderFlagsParameter for
example.

At first glance this looks like a conversion from Smalltalk Integer
to C int, but I think that is just a coincidence. The getImageHeaderFlags
method gives the value that is written to the snapshot file header,
but the first two bits of that value are not of interest for the
VM parameter, hence the shift right by 2 to get the value used for
the VM parameter.

As an aside, I find the use of bit masks (anyMask: or allMask:) for
bit testing to be hard to read, maybe it would be good to have this:

Integer>>testBit: bitNumber
"Answer whether the bit at bitNumber is set"
^ 0 ~= (self bitAt: bitNumber)

Dave

Eliot Miranda-2

Re: Small discrepancy in fileTimesInUTC between simulation & VM

In reply to this post by Nicolas Cellier

Hi Nicolas,

On Sun, Dec 27, 2020 at 5:52 AM Nicolas Cellier <[hidden email]> wrote:

Hi all, Eliot,

Simulation says:

^(Smalltalk vmParameterAt: 48) anyMask: 128

VM says:

^imageHeaderFlags anyMask: 512

Is the difference intentional?

It is, and it's a confusing mess for which I apologize. The issue is that the least significant two bits of the flags word are the full screen flag and the "vm is big endian" flag. Neither of these needs a setter since the full screen flag is set via the toggle full screen primitive and the "vm is big endian" is a constant depending on the VM. Hence Smalltalk vmParameterAt: 48 answers the flags bit shifted right 2 bits. I get bit by this all the time and wish I had not introduced the shift. Back in early October in VMMaker.oscog-eem.2837 I wrote completely incorrect code that screwed up several flags until VMMaker.oscog-eem.2848 that I fixed a week later. But unfortunately the damage is done. All we can do is comment the situation, while I beg forgiveness and forbearance.

_,,,^..^,,,_

best, Eliot

Nicolas Cellier

Re: Small discrepancy in fileTimesInUTC between simulation & VM

Hi both,

thanks for the hint, it's not obvious indeed !

We may eventually do like the simulation, always shift the flags, something like:

^self shiftedImageHeaderFlags anyMask: 128

The shift method would always be inlined, and I guess that the C compiler would generate equally efficient code for those two expressions

(flags >> 2) & 128.

flags & 512.

Anyway, we do not check flags in tight loops, do we?

Le mar. 29 déc. 2020 à 05:52, Eliot Miranda <[hidden email]> a écrit :

Hi Nicolas,

On Sun, Dec 27, 2020 at 5:52 AM Nicolas Cellier <[hidden email]> wrote:

Hi all, Eliot,

Simulation says:

^(Smalltalk vmParameterAt: 48) anyMask: 128

VM says:

^imageHeaderFlags anyMask: 512

Is the difference intentional?

It is, and it's a confusing mess for which I apologize. The issue is that the least significant two bits of the flags word are the full screen flag and the "vm is big endian" flag. Neither of these needs a setter since the full screen flag is set via the toggle full screen primitive and the "vm is big endian" is a constant depending on the VM. Hence Smalltalk vmParameterAt: 48 answers the flags bit shifted right 2 bits. I get bit by this all the time and wish I had not introduced the shift. Back in early October in VMMaker.oscog-eem.2837 I wrote completely incorrect code that screwed up several flags until VMMaker.oscog-eem.2848 that I fixed a week later. But unfortunately the damage is done. All we can do is comment the situation, while I beg forgiveness and forbearance.

_,,,^..^,,,_
best, Eliot

Eliot Miranda-2

Re: Small discrepancy in fileTimesInUTC between simulation & VM

Hi Nicolas,

On Jan 2, 2021, at 12:33 AM, Nicolas Cellier <[hidden email]> wrote:

Hi both,
thanks for the hint, it's not obvious indeed !
We may eventually do like the simulation, always shift the flags, something like:

    ^self shiftedImageHeaderFlags anyMask: 128

The shift method would always be inlined, and I guess that the C compiler would generate equally efficient code for those two expressions
    (flags >> 2) & 128.
    flags & 512.
Anyway, we do not check flags in tight loops, do we?

No, abd actually the flags are only processed at startup, snapshot, and the vmParameter primitives. Any flags which have an effect on execution (such as the fail-for-mixed-arithmetic flag) are extracted into variables at startup or in vmParameterAtPut abd read back into a flag bit from the variable at snapshot time.

Le mar. 29 déc. 2020 à 05:52, Eliot Miranda <[hidden email]> a écrit :

Hi Nicolas,

On Sun, Dec 27, 2020 at 5:52 AM Nicolas Cellier <[hidden email]> wrote:

Hi all, Eliot,

Simulation says:

^(Smalltalk vmParameterAt: 48) anyMask: 128

VM says:

^imageHeaderFlags anyMask: 512

Is the difference intentional?

It is, and it's a confusing mess for which I apologize. The issue is that the least significant two bits of the flags word are the full screen flag and the "vm is big endian" flag. Neither of these needs a setter since the full screen flag is set via the toggle full screen primitive and the "vm is big endian" is a constant depending on the VM. Hence Smalltalk vmParameterAt: 48 answers the flags bit shifted right 2 bits. I get bit by this all the time and wish I had not introduced the shift. Back in early October in VMMaker.oscog-eem.2837 I wrote completely incorrect code that screwed up several flags until VMMaker.oscog-eem.2848 that I fixed a week later. But unfortunately the damage is done. All we can do is comment the situation, while I beg forgiveness and forbearance.

_,,,^..^,,,_
best, Eliot