[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