[Vm-dev] VM endianness

[David T. Lewis]

On Thu, Mar 19, 2015 at 04:17:51PM +0100, Bert Freudenberg wrote:
>  
> > On 18.03.2015, at 20:49, Stefan Marr <smalltalk at stefan-marr.de> wrote:
> > 
> >> On 18 Mar 2015, at 20:17, tim Rowledge <tim at rowledge.org> wrote:
> >> 
> >> On 18-03-2015, at 12:10 PM, Eliot Miranda <eliot.miranda at 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