[Vm-dev] VMBIGENDIAN question (was: A proposal to split VMMaker into subpackages)

[Nicolas Cellier]

2013/3/21 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
>
> On Wed, Mar 20, 2013 at 5:14 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>>
>> On Tue, Mar 19, 2013 at 09:29:53PM +0100, Nicolas Cellier wrote:
>> >
>> > Trying to backport the LargeInteger v2 plugins, I saw that there is an
>> > important difference in the shared variables, notably class variables
>> > vs poolDictionary, for example VMBIGENDIAN is not accessible in
>> > Interpreter plugins. So it would probably be the first job.
>> >
>>
>> Can you give me a pointer to the code for which this was a problem? I'd like
>> to understand the issue better.
>>
>> The VMBIGENDIAN macro was eliminated long ago in favor of a static variable
>> initialized at runtime:
>
>
> Not in Cog.  I don't see the point of using other than a macro for something that definitely *won't* change at runtime.
>

Of course, I need this information for accessing bytes of native-order
32 bits digit LargeIntegers.
Otherwise, I use it in BIG ENDIAN case to fail a few primitives that
intrusively presume what LargeInteger internal format should be.
All code is at http://smalltalkhub.com/#!/~nice/NiceVMExperiments

Like Eliot, if there is a macro, I prefer the macro.
It's not only about speed, it's also about space, I don't see why to
embed dead code that should never ever be executed.
I know, I know, slow memory is cheap, but not the one in my processor cache.
Et les petits ruisseaux font les grandes rivières.

I also know that in the smart world of C nothing is easy, and there is
no standard macro because some exotic architectures can change
endianness at runtime (ARM?) or have different endianness for float
and int, or who knows what worse we could invent...

Same kind of C rant, I wish there were a compile time macro for
sizeof(long) , that would remove a few warning in VM generated code,
but that's probably another thread.

Last thing about macros, I think the generated code does not use enough macros.
Maybe because there is no easy way to use one that we did not define ourselves?
For example, in handwritten C I would use some INT_MAX UINT_MAX or
this kind of stuff here and there.

Nicolas

>>
>>
>>   Name: VMMaker-tpr.40
>>   Author: tpr
>>   Time: 29 December 2005, 1:36:18 pm
>>   UUID: d58632a4-6ae7-4880-9cc9-a52fcd0d98fa
>>   Ancestors: VMMaker-tpr.39
>>
>>   use dave lewis' runtimediscovery of vm endianness instead of ugly macro
>>
>> A macro is faster than dereferencing a variable, but I would be surprised to
>> find a measurable difference in the overall context of calling a primitive.
>>
>> Meanwhile, platform endianness can be determined with #vmEndianness, which
>> is portable across the oscog and trunk branches. On oscog it uses the macro,
>> and for the interpreter in trunk it uses the cached value set at runtime.
>> So I think it should be possible to write the LargeInteger v2 primitives to
>> work on both branches.
>>
>> Thanks,
>> Dave
>>
>
>
>
> --
> best,
> Eliot
>