[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Porting GNU Smalltalk to lightning 2

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Porting GNU Smalltalk to lightning 2
Date: Mon, 17 Nov 2014 12:19:33 -0200

2014-11-16 16:08 GMT-02:00 Holger Hans Peter Freyther <address@hidden>:
> On Mon, Oct 27, 2014 at 12:42:27AM -0200, Paulo César Pereira de Andrade 
> wrote:
> Good Evening,


>> >>   I may work on a new api to ensure the memory is synch'ed
>> >> tough. I hope to have lightning 2.0.6 released when it can
>> >> drive GNU Smalltalk :)
>> >
>> > I want to give it a try on ARM as well. Hopefully this week.
>>   I believe it is very likely to "just" work.
> work has been a bit busy. I finally built a version for our TI
> DM644x device (armv5) and something goes wrong during the bootstrap,
> I cross-compiled lightning and GST here.

  I did not test lightning on armv5 since the early bits. I am afraid
there may be issues there, where it could be generating armv6+
code in some code path.

> My first plan would be to execute the unit tests of lightning
> on my device to verify that it does the right thing.

  Please try it. If a test fails, please try running it manually with
something like:

$ (cd check; ./lightning -mcpu=4 the-test.tst)

that should force it to generate code that should work on any
armv5 board (I only tested lightning on armv5te or newer, but
have been only testing in armv7 for more than one year).

>>   For 64 bit, my patch is a complete hack. Need to write a
>> proper division code if there isn't an overflow fallback (or an
>> assertion if it must always exit). Probably just shift right
>> tag bits, divide, shift left tag bits...
> This is for lightning itself?

For GNU Smalltalk. The first patch just made it work for make check
(and that is why I suggested adding tests for 64 bit integers), the
second patch just used the multiplication and division by constant
by moving the constant to a register and using the code for "dynamic"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]