Smalltalk › Squeak › Squeak VM

VM endianness

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Clément Béra

VM endianness

Hello,

Is there a primitive or a parameter that I can call from the image to know the endianness of the processor / VM ?

Thanks,

Clement

Eliot Miranda-2

Re: VM endianness

Hi Clément,

On Wed, Mar 18, 2015 at 7:26 AM, Clément Bera <[hidden email]> wrote:

Hello,

Is there a primitive or a parameter that I can call from the image to know the endianness of the processor / VM ?

Amazingly no (well it surprised me, anyway). Squeak has an elaborate BitBlt-based scheme for calculating it. But in Spur we know adoptInstance: between bit objects will work so we can do the following:

| f |

f := BoxedFloat64 new.

f at: 1 put: 1; at: 2 put: 1.

ByteArray adoptInstance: f.

f first = 1 ifTrue: [#little] ifFalse: [#big]

best,

Eliot

David T. Lewis

Re: VM endianness

In reply to this post by Clément Béra

It is easy to add a primitive for this, but it should not be necessary.
See SmalltalkImage>>calcEndianness in Squeak.

Dave

> Hello,
>
> Is there a primitive or a parameter that I can call from the image to know
> the endianness of the processor / VM ?
>
> Thanks,
>
> Clement
>

Guillermo Polito

Re: VM endianness

In Pharo it is similar. However, we would like to have an image where BitBlt and Form are not there.

El mié., 18 de mar. de 2015 a la(s) 5:52 p. m., David T. Lewis <[hidden email]> escribió:

It is easy to add a primitive for this, but it should not be necessary.
See SmalltalkImage>>calcEndianness in Squeak.

Dave

> Hello,
>
> Is there a primitive or a parameter that I can call from the image to know
> the endianness of the processor / VM ?
>
> Thanks,
>
> Clement
>

Eliot Miranda-2

Re: VM endianness

On Wed, Mar 18, 2015 at 9:57 AM, Guillermo Polito <[hidden email]> wrote:

In Pharo it is similar. However, we would like to have an image where BitBlt and Form are not there.

Here's one that works on both Spur and V3. It only works on a Cog or Stack VM (and hence is OK for Pharo) since it depends on Floats being stored in the platform order internally.

| f |

f := Float new.

f at: 2 put: 1. "store the least significant word of the float with 1; on big endian machines this is the second word"

Bitmap adoptInstance: f.

f first = 1 ifTrue: [#little] ifFalse: [#big]

El mié., 18 de mar. de 2015 a la(s) 5:52 p. m., David T. Lewis <[hidden email]> escribió:

It is easy to add a primitive for this, but it should not be necessary.
See SmalltalkImage>>calcEndianness in Squeak.

Dave

> Hello,
>
> Is there a primitive or a parameter that I can call from the image to know
> the endianness of the processor / VM ?
>
> Thanks,
>
> Clement
>

best,

Eliot

stephane ducasse-2

Re: VM endianness

In Pharo it is similar. However, we would like to have an image where BitBlt and Form are not there.

Here's one that works on both Spur and V3. It only works on a Cog or Stack VM (and hence is OK for Pharo) since it depends on Floats being stored in the platform order internally.

| f |
f := Float new.
f at: 2 put: 1. "store the least significant word of the float with 1; on big endian machines this is the second word"
Bitmap adoptInstance: f.
f first = 1 ifTrue: [#little] ifFalse: [#big]

Do you have a magic invocation that would not involved graphic objects?

What would be cool is to have vm parameter or something like that. We want to reduce the dependencies in the core.

Stef

El mié., 18 de mar. de 2015 a la(s) 5:52 p. m., David T. Lewis <[hidden email]> escribió:

It is easy to add a primitive for this, but it should not be necessary.
See SmalltalkImage>>calcEndianness in Squeak.

Dave

> Hello,
>
> Is there a primitive or a parameter that I can call from the image to know
> the endianness of the processor / VM ?
>
> Thanks,
>
> Clement
>

--
best,
Eliot

Eliot Miranda-2

Re: VM endianness

On Wed, Mar 18, 2015 at 10:54 AM, stephane ducasse <[hidden email]> wrote:

In Pharo it is similar. However, we would like to have an image where BitBlt and Form are not there.

Here's one that works on both Spur and V3. It only works on a Cog or Stack VM (and hence is OK for Pharo) since it depends on Floats being stored in the platform order internally.

| f |
f := Float new.
f at: 2 put: 1. "store the least significant word of the float with 1; on big endian machines this is the second word"
Bitmap adoptInstance: f.
f first = 1 ifTrue: [#little] ifFalse: [#big]

Do you have a magic invocation that would not involved graphic objects?
What would be cool is to have vm parameter or something like that. We want to reduce the dependencies in the core.

At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?

Stef

El mié., 18 de mar. de 2015 a la(s) 5:52 p. m., David T. Lewis <[hidden email]> escribió:

It is easy to add a primitive for this, but it should not be necessary.
See SmalltalkImage>>calcEndianness in Squeak.

Dave

> Hello,
>
> Is there a primitive or a parameter that I can call from the image to know
> the endianness of the processor / VM ?
>
> Thanks,
>
> Clement
>

--
best,
Eliot

best,

Eliot

timrowledge

Re: VM endianness

On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:

>
>
> On Wed, Mar 18, 2015 at 10:54 AM, stephane ducasse <[hidden email]> wrote:
>
>
>>
>> In Pharo it is similar. However, we would like to have an image where BitBlt and Form are not there.
>>
>> Here's one that works on both Spur and V3. It only works on a Cog or Stack VM (and hence is OK for Pharo) since it depends on Floats being stored in the platform order internally.
>>
>>
>> | f |
>> f := Float new.
>> f at: 2 put: 1. "store the least significant word of the float with 1; on big endian machines this is the second word"
>> Bitmap adoptInstance: f.
>> f first = 1 ifTrue: [#little] ifFalse: [#big]
>
> Do you have a magic invocation that would not involved graphic objects?
> What would be cool is to have vm parameter or something like that. We want to reduce the dependencies in the core.
>
> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?

No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: AG: Add Gibberish

Stefan Marr-3

Re: VM endianness

Hi:

> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
>
> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
>>
>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
>
> No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.

Shouldn’t the VM should abstract from such things? Why is there a need for this knowledge on the application side?

I guess, it is needed for low-level hacking at the language level?
But even if there is a good use case, this is information about the underlying system, and the VM should at least mediate reliably with a proper interface. All other solutions rely on an undefined implicit interface.

Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

stephane ducasse-2

Re: VM endianness

On 18 Mar 2015, at 20:49, Stefan Marr <[hidden email]> wrote:

>
> Hi:
>
>> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
>>
>> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
>>
>> No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.
>
> Shouldn’t the VM should abstract from such things? Why is there a need for this knowledge on the application side?
>
> I guess, it is needed for low-level hacking at the language level?
> But even if there is a good use case, this is information about the underlying system, and the VM should at least mediate reliably with a proper interface. All other solutions rely on an undefined implicit interface.

in fact first I would like to reduce the dependencies
then ideally removing all the isLittleEndian test and logic from the image would be good.

>
> Best regards
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>

stephane ducasse-2

Re: VM endianness

In reply to this post by timrowledge

Do you have a magic invocation that would not involved graphic objects?
What would be cool is to have vm parameter or something like that. We want to reduce the dependencies in the core.

At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?

No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.

How?

By construction if I asked this is that I did not know.

Stef

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: AG: Add Gibberish

Clément Béra

Re: VM endianness

Well, based on what other people said, I think this is:

| f |
f := Float new.
f at: 2 put: 1.
WordArray adoptInstance: f.
f first = 1 ifTrue: [#little] ifFalse: [#big]

Thanks for your answers.

2015-03-18 21:08 GMT+01:00 stephane ducasse <[hidden email]>:

Do you have a magic invocation that would not involved graphic objects?
What would be cool is to have vm parameter or something like that. We want to reduce the dependencies in the core.

At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?

No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.

How?
By construction if I asked this is that I did not know.

Stef

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: AG: Add Gibberish

stephane ducasse-2

Re: VM endianness

I see that clement.

Stef

On 18 Mar 2015, at 21:18, Clément Béra <[hidden email]> wrote:

Well, based on what other people said, I think this is:

| f |
f := Float new.
f at: 2 put: 1.
WordArray adoptInstance: f.
f first = 1 ifTrue: [#little] ifFalse: [#big]

Thanks for your answers.

2015-03-18 21:08 GMT+01:00 stephane ducasse <[hidden email]>:

Do you have a magic invocation that would not involved graphic objects?
What would be cool is to have vm parameter or something like that. We want to reduce the dependencies in the core.

At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?

No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.

How?
By construction if I asked this is that I did not know.

Stef

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: AG: Add Gibberish

Bert Freudenberg

Re: VM endianness

In reply to this post by Stefan Marr-3

> On 18.03.2015, at 20:49, Stefan Marr <[hidden email]> wrote:
>
>
> Hi:
>
>> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
>>
>> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
>>
>> No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.
>
> Shouldn’t the VM should abstract from such things? Why is there a need for this knowledge on the application side?
>
> I guess, it is needed for low-level hacking at the language level?

+1

This is only needed if you work around the VM, like when you use FFI. So IMHO the FFI plugin should support that primitive. Or maybe it does? Doesn't it provide special bytearray accessors?

- Bert -

smime.p7s (5K) Download Attachment

David T. Lewis

Re: VM endianness

On Thu, Mar 19, 2015 at 04:17:51PM +0100, Bert Freudenberg wrote:

>
> > On 18.03.2015, at 20:49, Stefan Marr <[hidden email]> wrote:
> >
> >> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
> >>
> >> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
> >>>
> >>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
> >>
> >> No need to use Bitmap if that?s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.
> >
> > Shouldn?t the VM should abstract from such things? Why is there a need for this knowledge on the application side?
> >
> > I guess, it is needed for low-level hacking at the language level?
>
> +1
>
> This is only needed if you work around the VM, like when you use FFI. So IMHO the FFI plugin should support that primitive. Or maybe it does? Doesn't it provide special bytearray accessors?
>
> - Bert -

I don't think it is needed at all, but it would be easy to add. For example,
on the interpreter VM it is just this:

InterpreterPrimitives>>primitiveBigEnder
"Answer true if running on a big endian machine."
<export: true>
self isBigEnder
ifTrue: [self pop: 1 thenPush: objectMemory trueObject]
ifFalse: [self pop: 1 thenPush: objectMemory falseObject]

It might look different in Cog, but I assume it would be equally trivial.

But do we really want to be hiding the logic for this in the VM (or plugin)?
We know that it can be implemented in the image, where everyone can see and
understand what it is doing. That seems like a good thing to me.

Dave

Eliot Miranda-2

Re: VM endianness

In reply to this post by Bert Freudenberg

On Mar 19, 2015, at 8:17 AM, Bert Freudenberg <[hidden email]> wrote:

>
>> On 18.03.2015, at 20:49, Stefan Marr <[hidden email]> wrote:
>>
>>
>> Hi:
>>
>>> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
>>>
>>> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
>>>>
>>>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
>>>
>>> No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.
>>
>> Shouldn’t the VM should abstract from such things? Why is there a need for this knowledge on the application side?
>>
>> I guess, it is needed for low-level hacking at the language level?
>
> +1
>
> This is only needed if you work around the VM, like when you use FFI. So IMHO the FFI plugin should support that primitive. Or maybe it does? Doesn't it provide special bytearray accessors?

Yes. Given FFI primitives its easy to construct a test out of longAt:put: and byteAt:. I didn't state it earlier cuz the prims aren't in the base VM.

>
> - Bert -
>
>
>

EstebanLM

Re: VM endianness

> On 20 Mar 2015, at 09:42, Eliot Miranda <[hidden email]> wrote:
>
>
>
>
> On Mar 19, 2015, at 8:17 AM, Bert Freudenberg <[hidden email]> wrote:
>
>>
>>> On 18.03.2015, at 20:49, Stefan Marr <[hidden email]> wrote:
>>>
>>>
>>> Hi:
>>>
>>>> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
>>>>
>>>> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
>>>>>
>>>>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
>>>>
>>>> No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.
>>>
>>> Shouldn’t the VM should abstract from such things? Why is there a need for this knowledge on the application side?
>>>
>>> I guess, it is needed for low-level hacking at the language level?
>>
>> +1
>>
>> This is only needed if you work around the VM, like when you use FFI. So IMHO the FFI plugin should support that primitive. Or maybe it does? Doesn't it provide special bytearray accessors?
>
> Yes. Given FFI primitives its easy to construct a test out of longAt:put: and byteAt:. I didn't state it earlier cuz the prims aren't in the base VM.

in the pharo vm, they are.

Esteban

>
>>
>> - Bert -
>>
>>
>>

Guillermo Polito

Re: VM endianness

So, following with this discussion ^^

This is the latest version we are using.

f := Float new: 2.

f at: 2 put: 1. "store the least significant word of the float with 1; on big endian machines this is the second word"

Bitmap adoptInstance: f.

^ f first = 1 ifTrue: [#little] ifFalse: [#big]

works, because both Float and Bitmap are compact. I just state it because to use another variable word class we should make it compact too.

Thanks,

Guille

El vie., 20 de mar. de 2015 a la(s) 11:11 a. m., Esteban Lorenzano <[hidden email]> escribió:

> On 20 Mar 2015, at 09:42, Eliot Miranda <[hidden email]> wrote:
>
>
>
>
> On Mar 19, 2015, at 8:17 AM, Bert Freudenberg <[hidden email]> wrote:
>
>>
>>> On 18.03.2015, at 20:49, Stefan Marr <[hidden email]> wrote:
>>>
>>>
>>> Hi:
>>>
>>>> On 18 Mar 2015, at 20:17, tim Rowledge <[hidden email]> wrote:
>>>>
>>>> On 18-03-2015, at 12:10 PM, Eliot Miranda <[hidden email]> wrote:
>>>>>
>>>>> At least it doesn't use BitBlt. Its got much less dependencies than the existing code and is much simpler. Isn't that worth something?
>>>>
>>>> No need to use Bitmap if that’s a real problem - make a trivial class that is ArrayedCollection variableWordSubclass:#EndianTestThing and use that.
>>>
>>> Shouldn’t the VM should abstract from such things? Why is there a need for this knowledge on the application side?
>>>
>>> I guess, it is needed for low-level hacking at the language level?
>>
>> +1
>>
>> This is only needed if you work around the VM, like when you use FFI. So IMHO the FFI plugin should support that primitive. Or maybe it does? Doesn't it provide special bytearray accessors?
>
> Yes. Given FFI primitives its easy to construct a test out of longAt:put: and byteAt:. I didn't state it earlier cuz the prims aren't in the base VM.

in the pharo vm, they are.

Esteban

>
>>
>> - Bert -
>>
>>
>>

David T. Lewis

Re: VM endianness

On Fri, Apr 03, 2015 at 08:40:58AM +0000, Guillermo Polito wrote:

>
> So, following with this discussion ^^
>
> This is the latest version we are using.
>
> f := Float new: 2.
> f at: 2 put: 1. "store the least significant word of the float with 1; on
> big endian machines this is the second word"
> Bitmap adoptInstance: f.
> ^ f first = 1 ifTrue: [#little] ifFalse: [#big]
>
> works, because both Float and Bitmap are compact. I just state it because
> to use another variable word class we should make it compact too.
>
> Thanks,
> Guille

FYI:

With in interpreter VM on Intel (which uses the original float ordering from
earlier Squeak images), you get a different result:

f := Float new: 2.
f at: 2 put: 1. "store the least significant word of the float with 1; on
big endian machines this is the second word"
Bitmap adoptInstance: f.
^ f first = 1 ifTrue: [#little] ifFalse: [#big] "==> #big"

Smalltalk isBigEndian "==> false"

This will not be an issue on Cog or Spur.

Dave