On Mon, Jul 30, 2012 at 10:52:59AM +0200, Moritz Lenz wrote:
> Hi Nick,
>
> thanks for looking into it. It's great to see Rakudo on more small devices.
I think I'm expected to return the borrowed phone charger which is powering
the swap drive, so I need to stop playing :-(
They've removed the pre-order restriction, so anyone with $35 (plus postage)
(plus borrowed (or otherwise) USB phone charger and SD card) can play too.
Curiously element14 report a delivery delay of only 3 weeks. RS say *17*
weeks.
> Am 30.07.2012 10:30, schrieb Nicholas Clark:
> > With QAST and PIRT merged, I can build Rakudo on a Raspberry Pi in about 12
> > hours, albeit with a lot of swapping (to a real disk)
> > This was NQP at 6bd8bc5eb0f7cd29, Rakudo at c1bfbbb233c86036.
> >
> > On Thu, Jun 28, 2012 at 09:49:32PM +0100, Nicholas Clark wrote:
> >
> > Still need this:
> >
> >> It seems that dyncall doesn't recognise arm6el as a class of ARM
> >> architecture
> >> which it supports. Given that it supports iOS, and has a configure option
> >> for
> >> ARM, it seems pretty clear that it does, so I bodged it this this:
> >>
> >> nick@raspberrypi ~/Perl/rakudo/nqp $ git diff
> >> diff --git a/Configure.pl b/Configure.pl
> >> index 5539471..f1a1c00 100644
> >> --- a/Configure.pl
> >> +++ b/Configure.pl
> >> @@ -125,7 +125,7 @@ MAIN: {
> >> system_or_die('cd 3rdparty\dyncall && Configure.bat' .
> >> $configure_a
> >> $config{'dyncall_build'} = "cd 3rdparty/dyncall && $make
> >> BUILD_DIR=
> >> } else {
> >> - system_or_die('cd 3rdparty/dyncall && sh configure');
> >> + system_or_die('cd 3rdparty/dyncall && sh configure
> >> --target-arm-arm
> >> if ($^O eq 'netbsd') {
> >> $config{'dyncall_build'} = "cd 3rdparty/dyncall &&
> >> BUILD_DIR=.
> >> } else {
>
> I guess we should take that upstream to the dyncall folks.
Yes, that seems the right place to solve this.
>
> > Still see this, and I really don't have time to dig into it:
> >
> >> NQP fails 1 test:
> >>
> >> Test Summary Report
> >> -------------------
> >> t/nqp/60-bigint.t (Wstat: 0 Tests: 34 Failed: 3)
> >> Failed tests: 28-29, 34
> >> Files=64, Tests=584, 773 wallclock secs ( 5.03 usr 0.61 sys + 751.26 cusr
> >> 11.36 csys = 768.26 CPU)
>
> This might very well be related to some bit fiddling in our own bigint
> ops, which were done by somebody with no experience whatsoever on
> bigendian platforms (me).
ARM by default is little endian. I think it's constrained by the board, so
running it big endian requires different hardware. I believe that there's
"armbe" at least in the Linux kernel, but I'm not sure if anyone has even
made a distro for it.
I'd guess the bit fiddling is something else. Does the code do left shifts of
32 bits (on platforms with 32 bit IVs) and expect the same answer as x86
gives?
Nicholas Clark
