[squeak-dev] Re: [Vm-dev] New Cog VMs available...

[Nicolas Cellier]

2014-07-03 0:18 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
> Hi Nicolas,
>
>
> On Wed, Jul 2, 2014 at 2:51 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>>
>>
>> 2014-07-02 23:32 GMT+02:00 Frank Shearar <frank.shearar at gmail.com>:
>>
>> On 2 July 2014 22:19, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Jul 2, 2014 at 1:45 PM, Frank Shearar <frank.shearar at gmail.com
>>> >
>>> > wrote:
>>> >>
>>> >> On 1 July 2014 18:03, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> >> >
>>> >> > at http://www.mirandabanda.org/files/Cog/VM/VM.r3024/.
>>> >>
>>> >> CI updated accordingly! For Spur:
>>> >> http://build.squeak.org/job/SqueakTrunkOnSpur/29/console
>>> >
>>> >
>>> > and I'm working on the large integer failures right now.  that should
>>> fix
>>> > most of the errors.
>>>
>>> Excellent! That will end the streak of red in the SqueakTrunk build
>>> history.
>>>
>>> Thanks!
>>>
>>>
>> I've got a working solution ready for large int plugin.
>> digitDiv and montgomery are broken due to the same bug // 256...
>> I can publish if you want.
>>
>
> Forgive me but I went ahead and fixed it.  I just figured out that I could
> have the code generator output asserts at every divide by a power of two to
> check that the results agreed with signed shifts and hence easily caught
> all the places where there was a bug.  I've also realised that I can have
> the code generator output #if #else #endif code for remapOop:in: and so not
> incur any overhead in Spur, which doesn't GC during primitives.
>
> --
> best,
> Eliot
>
>
No matter, I'll publish later because it is a good cleanup...
Most of the divides are unsigned and OK (like // 8 and \\ 8 for counting
number of bytes/bits in a shift)
Only 3 places were broken: sub, div, and montgomery mul.

Anyway, it happens that I cannot publish because there is a bug in my image
(mostly an updated trunk image)...
I'm currently stuck with ZipWriteStream(DeflateStream)>>updateHashAt: which
tries to write at position 65537 in a buffer of length 65536
Huh?

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140703/e048dae0/attachment.htm