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
Hi Clément,
On Wed, Mar 18, 2015 at 7:26 AM, Clément Bera bera.clement@gmail.com 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]
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 < lewis@mail.msen.com> 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
On Wed, Mar 18, 2015 at 9:57 AM, Guillermo Polito <guillermopolito@gmail.com
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 < lewis@mail.msen.com> 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
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 lewis@mail.msen.com 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
On Wed, Mar 18, 2015 at 10:54 AM, stephane ducasse < stephane.ducasse@gmail.com> 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 < lewis@mail.msen.com> 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
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Mar 18, 2015 at 10:54 AM, stephane ducasse stephane.ducasse@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: AG: Add Gibberish
Hi:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com 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
On 18 Mar 2015, at 20:49, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com 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/
On 18.03.2015, at 20:49, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com 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 -
On Thu, Mar 19, 2015 at 04:17:51PM +0100, Bert Freudenberg wrote:
On 18.03.2015, at 20:49, Stefan Marr smalltalk@stefan-marr.de wrote:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com 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
On Mar 19, 2015, at 8:17 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 18.03.2015, at 20:49, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com 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 -
On 20 Mar 2015, at 09:42, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 19, 2015, at 8:17 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 18.03.2015, at 20:49, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com 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 -
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 < estebanlm@gmail.com> escribió:
On 20 Mar 2015, at 09:42, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 19, 2015, at 8:17 AM, Bert Freudenberg bert@freudenbergs.de
wrote:
On 18.03.2015, at 20:49, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi:
On 18 Mar 2015, at 20:17, tim Rowledge tim@rowledge.org wrote:
On 18-03-2015, at 12:10 PM, Eliot Miranda eliot.miranda@gmail.com
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 -
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
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: AG: Add Gibberish
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 stephane.ducasse@gmail.com:
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: AG: Add Gibberish
I see that clement. Stef
On 18 Mar 2015, at 21:18, Clément Béra bera.clement@gmail.com 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 stephane.ducasse@gmail.com:
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: AG: Add Gibberish
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Clément Bera -
Clément Béra
-
David T. Lewis -
Eliot Miranda -
Esteban Lorenzano -
Guillermo Polito -
Stefan Marr -
stephane ducasse -
tim Rowledge