[Vm-dev] Spur Object 64 bit format

[Igor Stasenko]

IMO, reversing the tag value (0/1) doesn't changes much..
And camp division between two reminds me big vs little endian fights
described by Jonathan Swift :)

If we wanna gain more performance, i think we should put our attention to
another place(s).



On 14 November 2013 15:14, Jecel Assumpcao Jr. <jecel at merlintec.com> wrote:

>
> Eliot Miranda wrote:
> > On Tue, Nov 12, 2013 at 3:56 AM, Clément Bera wrote:
> > > By the way as you are talking about Immediate objects tags and Spur's
> object
> > > representation, I read on other VMs reports that it is faster in
> overall performance
> > > to have pointers tagged with the xxx1 and SmallIntegers tagged with
> xxx0,
> > > because SmallIntegers arithmetics is then much faster.
> >
> > I'm sure that was true 20 years ago when register operations were about
> the
> > same speed as memory operations.  But now that memory operations are at
> > least an order of magnitude slower I suspect that adjusting the tags
> (all register
> > operations) are in the noise.  But I agree it *would* be interesting to
> measure.
>
> Another issue is that the 680x0 had addressing modes that aren't common
> on current processors. Having SmallIntegers be xxx0 means you don't have
> to untag them to add or subtract and then retag them. Shifts and
> multiplies require a single scaling factor beyond the basic operation.
> But the xxx1 for OOPs introduce complications: if you are going to
> access a fixed instance variable, for example instance variable 3, then
> you can deal with it at assembly time:
>
>   MOVE.L (-1+4*(3+1),A5),D1 ; where A5 is the OOP
>
> But if you are going to access a field in an Array then you have to do
> it at runtime:
>
>   MOVE.L (-1+4*FixedFields,A5,D2*4),D1  ; where A5 is the OOP and D2 is
> the index
>
> While it takes several instructions to do the same thing on a current
> processor, the 680X0 took quite a few clock cycles to execute the single
> instruction above and it took several words in memory to encode it, so
> the gain was mostly imaginary.
>
> -- Jecel
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131114/a330794b/attachment.htm