[Vm-dev] Accelerating LargeIntegersPlugin phase 2

[David T. Lewis]

I'll mention also that, although much work remains to be done in merging
oscog and trunk VM code bases, I think that overall we are doing very
well with the primitives.  The VM primitives are now almost all in class
InterpreterPrimitives, and changes can easily by adopted in both branches.
Likewise, the plugins such as LargeIntegersPlugin can easily be kept in
sync in the two branches.

That means that changes like these can be tested and adopted in either
branch at the convenience of the person doing the work. I'm doing my
best to pick up changes as they are added to Cog, and Eliot is doing
likewise with changes that show up first in the interpreter VM.

I don't happen to have a big endian machine, but hopefully someone else
has one and can help out with the testing, using either an interpreter
VM or Cog VM.

Dave

On Sun, Jan 20, 2013 at 11:19:00AM +0100, Nicolas Cellier wrote:
>  
> Hi Steph,
> thanks, I think this might be usefull.
> These experiments were carried alone without any form of coordination.
> So, to not waste too much energy, the first step is to get some kind
> of blessing from Eliot.
> If he is OK and we have a chance of integrating the changes back in
> COG, then we can start testing.
> 
> Nicolas
> 
> 2013/1/20 stephane ducasse <stephane.ducasse at gmail.com>:
> >
> > Nicolas
> >
> > if you want we can set up a jenkins build for your code. We have all the machines and
> > it costs us so much energy but it is really starting to pay back.
> > Just ask.
> > The inria service will get out of beta 24 of january.
> >
> > Stef
> >
> > On Jan 19, 2013, at 11:40 PM, Nicolas Cellier wrote:
> >
> >>
> >> I've now added support for BigEndian machine to LargeIntegersPlugin
> >> v2.0 (32 bits digits)
> >> On such machine, LargeIntegers (Positive or Negative) will be stored
> >> in big-endian (native) 32 bits words.
> >> If course, images will be saved with that peculiar byteOrder by a new VM.
> >> I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity.
> >> Eliot, let me know if you have bigger plan for that bit, and if so,
> >> please assign another one to my experiments.
> >> It will be easy to add reverse support to make an image readable by an
> >> old VM, if ever...
> >>
> >> Of course, I've got no such BigEndian machine.
> >> So it's up to a good soul to test it for me... (or a CI machine?)
> >> To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the
> >> SmalltalkHub repository, then follow usual cog svn branch instructions
> >> to generate, compile, ...
> >>
> >> Before using the new VM on a BigEndian machine, a pre-requisite is to
> >> load/merge Kernel-nice.734 because it contains a definitions of
> >> #digitAt: #digitAt:put: and #digitLength compatible across different
> >> VM.
> >>
> >> There might be some nasty side effect if you try to copy
> >> LargeInt<->ByteArray with available primitives (I know some packages
> >> do it). When we are cheating (by letting LargeInt variable-byte) there
> >> must be a price to pay... Maybe I'll try to address this known
> >> limitation later.
> >>
> >> That's all for now, my VM hacking are mostly late-night, and I need a
> >> little rest.
> >> Let me know if you ever try the adventure of using dangerous early
> >> hour coding ;)
> >>
> >> Nicolas
> >>
> >> 2013/1/19 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> >>> I published code on SmalltalkHub (nice occasion to test it, and I did
> >>> not want to pollute source.squeak.org with experimental) in sync with
> >>> .oscog branch.
> >>> MCHttpRepository
> >>>        location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main'
> >>>        user: 'nice'
> >>>        password: ''
> >>>
> >>> I also blogged about it
> >>> http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html
> >>>
> >>> I didn't take any care to make the code 64bits friendly. This will
> >>> require a review...
> >>>
> >>> Nicolas
> >