[Vm-dev] SqueakJS named primitives in the interpreter modulej

[David T. Lewis]

On Wed, Jan 25, 2017 at 03:53:16PM +0100, Bert Freudenberg wrote:
>  
> On Wed, Jan 25, 2017 at 4:11 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > Sorry to reply to my own post, but I need to retract this. The profiler
> > shows that a big portion of the time is spent in
> >
> >     LargePositiveInteger(Integer)>>digitDiv:neg:
> >
> > I mistakenly assumed that primDigitDevNegative was not implemented for
> > the LargeIntegers module, but that is wrong, I see now that function
> > primDigitDivNegative() is implemented in the translated plugins. So maybe
> > it is not an efficient implementation when translated to JavaScript?
> >
> 
> It certainly is not efficient, and I did not yet try to improve its
> efficiency, but it is faster than the fallback code:
> 
> https://github.com/bertfreudenberg/SqueakJS/blob/master/plugins/LargeIntegers.js#L1798
> 
> What is the range of your LargeIntegers? SqueakJS does not implement most
> of prims 30-37, whereas the C VM at least does so with up to 64 bits IIRC?
> https://github.com/bertfreudenberg/SqueakJS/blob/master/vm.js#L4301
> 
> This is just laziness on my part (since the fallback + plugin works),
> there's no good reason not to implement a fast path for these if the
> numbers fall within the 53 bit range JS can handle directly. We do have the
> code for 31 bit SmallInts, so this should be relatively simple.
> 
> These prims could even be made to handle arbitrary-sized large ints (in
> which case the plugin wouldn't even be needed, and it would likely be much
> faster) but getting the semantics exactly right is not trivial.
> 

The large integers are microseconds since Posix epoch, so currently they
are 51 bits unsigned. They would begin using 52 bits in the year 2041, and
53 bits will not be needed until 2112. So these values should all fit within
a 53 bit direct integer representation in JavaScript.

For what it's worth:

  "UTC microseconds fits in a 53 bit register, with a couple of bits to spare"
  DateAndTime now utcMicroseconds asRegister: 53
  ==> a TwosComplementRegister with value 1485394271578388 (00101010001101111010101001101111010001010100100010100)
  
  "check register overflow, ok"
  (DateAndTime now utcMicroseconds asRegister: 53) overflow ==> false
  
  "52 bits required in 2041"
  DateAndTime utcMicroseconds:16r7FFFFFFFFFFFF offset: 0
  ==> 2041-05-10T11:56:53.685247+00:00

I would not expect any huge demand for optimizing this, after all I am
probably the only person on the planet using UTCDateAndTime ;-)

Interesting to note that the LargeIntegersPlugin assumes a binary world
of 8, 16, 32, 64... but we are now interested in tranlating its primitives
to a runtime with other native word sizes. It may still work, but it is
not likely to be optimal out of the box.

Dave