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

David T. Lewis lewis at mail.msen.com
Thu Mar 21 00:14:06 UTC 2013


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:
 
  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



More information about the Vm-dev mailing list