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

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 21 00:21:35 UTC 2013


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.


>
>   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130320/ca0dbc04/attachment.htm


More information about the Vm-dev mailing list