[Vm-dev] Accelerating LargeIntegersPlugin phase 2
stephane ducasse
stephane.ducasse at gmail.com
Sun Jan 20 10:28:41 UTC 2013
On Jan 20, 2013, at 11:19 AM, 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.
Ok
Just do not hesitate, the guys here will help. Git you can hack in your own connected with a jenkins build
with green tests and people can cherry pick what they want.
We are preparing the following set up:
- official pharo jenkins builds for VM and images (as few as possible)
- experimental build for … work under way/experiment….
- …
We really want to support people to focus on the right place and not spend their time on scripts and other
infrastructure tasks that can be fully automatized.
Stef
>
> 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
>>
More information about the Vm-dev
mailing list