OpenEuphoria

1. OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 11, 2013
• 3271 views

I finally made some time this weekend to mess around with OpenEuphoria on the raspberry pi. Thanks to Ira's hardfloat binaries I was able to build my own newer dev version, although i'm getting a lot of cast & incompatable types warnings in newer changesets & i have to modify line 66 so the grep is for arm rather than ARM and iirc I had to remove a -m32 as well but I think that was one of the earlier changesets before I ended up with one from 28th of November that works, the few changesets i tried from 2013 seemed to bomb out building so i'm going through all of the changesets until i find where the change that stops it from building occured. For some reason my self-built version is taking 10seconds longer than Ira's binaries to complete the sieve8k benchmark

Prime Sieve Benchmark 
Count: 1028, Largest: 8191 
time: 33.07 

compared to

Prime Sieve Benchmark 
Count: 1028, Largest: 8191 
time: 23.6 

I've ported another interesting benchmark program from a BASIClike interpreter called RTB which is for the raspberry pi and quite slow but usable and I thought others might like to try it on different ARM devices and x86 computers, the code is rubbish but it works as it should, i use the diff() function so it's only got a second granularity but it's good enough.

without type_check 
include std/datetime.e 
 
atom z 
sequence start 
 
function ackermann(atom m, atom n) 
	if m = 0 then  
		return n + 1  
	end if 
	if n = 0 then  
		return ackermann( m -1, 1)  
	end if 
	return ackermann(m - 1, ackermann(m, n - 1)) 
end function 
 
puts(1, "The Ackermann Test\n") 
puts(1, "Start\n") 
 
start = now() 
 
for y = 0 to 3 do 
	for x = 0 to 9 do 
	    printf(1, "%d ",ackermann(y, x)) 
	end for 
	puts(1,"\n") 
end for 
 
printf(1, "Done in %d seconds\n", diff( start, now())) 

on my 1000MHz on-demand overclocked raspberry pi running raspbian the results are

eui ackermann.ex 
The Ackermann Test 
Start 
1 2 3 4 5 6 7 8 9 10  
2 3 4 5 6 7 8 9 10 11  
3 5 7 9 11 13 15 17 19 21  
5 13 29 61 125 253 509 1021 2045 4093  
Done in 30 seconds 

and

eub ackermann.il 
The Ackermann Test 
Start 
1 2 3 4 5 6 7 8 9 10  
2 3 4 5 6 7 8 9 10 11  
3 5 7 9 11 13 15 17 19 21  
5 13 29 61 125 253 509 1021 2045 4093  
Done in 29 seconds 

bst rgrds Russell

3. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 11, 2013
• 3247 views

will do, i know squat about mercurial as i use fossil so i'll read up on bisect.

the warnings about unused variables i'm not too bothered about but getting a few like the following that i'm a tad "worried" about

be_alloc.c: In function ‘new_dbl_block’: 
be_alloc.c:994:2: warning: passing argument 1 of ‘ERealloc’ from incompatible pointer type [enabled by default] 
be_alloc.h:164:14: note: expected ‘char *’ but argument is of type ‘struct free_block **’ 
be_alloc.c:994:16: warning: assignment from incompatible pointer type [enabled by default] 
 

you get similar when building on x86?

5. Re: OpenEuphoria on the raspberry pi

• Posted by useless_ Feb 11, 2013
• 3181 views

I just ran the code on a 10 yr old P4 2.6Ghz desktop box running winxp (and it was doing other things), and the code ran in 8 seconds, repeatedly. I expected the Pi to execute this much faster than the times you report. It makes sense only if i consider that the speed of *nix OS you are running scales with the cpu clock speed, being your times are 3x and the clock speed is 1/3 of my desktop box.

Maybe i was expecting one could run Eu on the Pi with no preemptive OS, in the same way one can run C (or etc) on the avr in the arduino with no OS. Is that possible on the Pi? Is an OS required? My understanding (and my experience) is if one made no D/OS calls 20 years ago, one didn't need the D/OS to be present.

useless

7. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 11, 2013
• 3203 views

With the hard-float version I posted, I had used more aggressive optimization to get better performance! Also, I updated my eui with the lastest version from the default branch. What branch of the code was giving you those errors?

pi@raspberrypi ~/Code/Euphoria $ eui -v 
Euphoria Interpreter v4.1.0 development 
   32-bit Linux, Using System Memory 
   Revision Date: 2013-02-10 21:47:07, Id: 5978:8d834d1a940f 

My PI is overclocked to 950 MHz and I get the folliowing with your program:

pi@raspberrypi ~/Code/Euphoria $ eui ackerman.ex 
The Ackermann Test 
Start 
1 2 3 4 5 6 7 8 9 10 
2 3 4 5 6 7 8 9 10 11 
3 5 7 9 11 13 15 17 19 21 
5 13 29 61 125 253 509 1021 2045 4093 
Done in 18 seconds 

Not too bad!
Thanks,
Ira

9. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 12, 2013
• 3137 views

Ah, ok! I have the recommended compiler from the raspberry pi foundation setup in my scratchbox:

sb2 -t raspbianhf gcc -v 
Using built-in specs. 
Target: arm-linux-gnueabihf 
.... 
Thread model: posix 
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)  

For reference, the gcc version on my pi is:

pi@raspberrypi ~/Code/Euphoria $ gcc -v 
Using built-in specs. 
Target: arm-linux-gnueabihf 
.... 
Thread model: posix 
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)  

While I can compile the latest revision in the default branch in scratchbox, that version seems to not work properly on my pi. Some of the example programs just stall out... I haven't discovered what the issue is yet, but this version seems to be stable on my pi:

sb2 -t raspbianhf ./eui -v 
Euphoria Interpreter v4.1.0 development 
   32-bit Linux, Using System Memory 
   Revision Date: 2013-01-18 15:52:45, Id: 5957:e9e11b19737a 

I'm curious to know what kind of performance you get after switching to -O3 and which revision you get working!

Thanks,
Ira

11. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 12, 2013
• 3084 views

You might try adding trace(3) to see where things are getting stuck.

Matt

13. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 3077 views

i would except it never even gets that far, i put a with trace trace(1) in when i first spotted this and it just sits there blinking it's cursor at me

15. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 3034 views

actually just tried again and this time it worked (go figure) but it freezes as soon as i press F2 if i follow it manually then it gets further but as soon as i press f2 it freezes, the only consistant thing seems to be after it prints Prime Sieve benchmark & always at an end for line, if not tracing the output line never appears, could be something in the console output? my ackermann.ex doesn't use teh console include and it runs ok

17. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 12, 2013
• 3032 views

Interesting. I think trace(3) is the next thing to try.

Matt

19. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 3024 views

ok now i'm really confused

without type_check 
with trace 
include std/machine.e 
include std/math.e 
include std/console.e 
include std/error.e 

works

without type_check 
--with trace 
include std/machine.e 
include std/math.e 
include std/console.e 
include std/error.e 

doesn't. i don't need to to use trace(1) just add or remove with trace

commenting out console.e also allows it to run

i'm ssh'ed in to the raspberry pi if that would make a difference but i wouldn't think so

21. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 12, 2013
• 3031 views

ctrace.out has a fixed number of lines (which is configurable in 4.1), so it wraps around. This is by design to prevent the file from getting too big. There should be a line that says "THE END" shhortly after the last line that was written.

Matt

23. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 3088 views

http://pastebin.com/Wd7RBSb9

25. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 3029 views

yeah although i've been on 3.6 & 3.7 kernel for yonks via rpi-update. i was actually going to downgrade back to a older sd card image with 3.2 kernel & older gcc to see if that made a difference

27. Re: OpenEuphoria on the raspberry pi

• Posted by EUWX Feb 12, 2013
• 3034 views

Tthere is also a Fedora 18 version which was released yesterday and a Bodhi version released a few days ago. Both these specifically address the ARM processor.

http://scotland.proximity.on.ca/raspberrypi/raspberrypi-fedora-remix/18/images/

http://jeffhoogland.blogspot.nl/2012/12/bodhi-linux-armhf-rootfs.html

29. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 2993 views

i'm up to 5892:6a40c057e911 as a changeset that will build and run consistantly & works correctly (no freezing) with both gcc 4.6 & 4.7 although still not found all the places to add -O3 so not the fastest versin there is yet

31. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 12, 2013
• 3002 views

Ok, hopefully I can shed some light on the situation! I found that my cross-compiled Euphoria stopped working with revision 5964:ff33ded2f059. According to the changeset, we have:

--- a/include/std/map.e	Tue Jan 22 14:26:47 2013 -0500 
+++ b/include/std/map.e	Tue Jan 22 21:02:33 2013 -0500 
@@ -264,7 +264,11 @@ 
  function lookup( object key, integer hashval = hash( key ), sequence slots ) 
  	integer mask = length( slots ) - 1 
  	integer index = and_bits( hashval, mask ) + 1 
 -	integer index_hash = index 
 +	ifdef BITS64 then 
 +		integer index_hash = index 
 +	elsedef 
 +		atom index_hash = index 
 +	end ifdef 
   	sequence slot 

Based on this, I changed "ifdef BITS64 then" to "ifdef BITS64 or ARM then" and everything works again; the demo programs no longer freeze! Maybe one of the devs can comment on the signifigance here...

To change the optimization levels, I open Makefile.gnu in the source directory with vim. Then you can do a find and replace like so:

:%s/-O2/-O3/g 

Also, if you really want optimization appended to all compilation options, you can change the CC reference in Makefile,gnu:

CC=$(CC_PREFIX)$(CC_SUFFIX) 
to 
CC=$(CC_PREFIX)$(CC_SUFFIX) -O3 

I'm a fan of Arch Linux and use it as my primary distro on my x86 system, but the Rapsbian image is based on the 3.6 kernel after the update/upgrade. On my Pi, I get the following:

pi@raspberrypi /tmp $ uname -a 
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux 

I've read the 3.7 kernel has some excellent enhancements, but I do think hard float euphoria should work on the older kernels as well.

Thanks,
Ira

33. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 12, 2013
• 2931 views

that is really not really relevant for userspace s/w such as euphoria. i have binaries built on various arm versions and hardware that run fine on others. i've bulit stuff on the raspberry pi that runs on the zipit z2 and vice versa as on the whole (not completely true as iirc some of the newer arm chips break backwards compatability) an armv6 cpu can run armv5/4 binaries, armv7 can run armv6/5/4 and so on all other things being equal e.g. endian, floating point abi, ... and you are not doing stuff to registers and peripherals directly e.g. gpio

35. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 12, 2013
• 2998 views

Ok, thanks for the snippet! I was able to recreate the error you are seeing; essentially your compilation isn't translating the Eu source code which causes the several undefined references. Try this in your source directory:

which eui                 % Quick check that a working eui is in your path (the original hard float eubins should work) 
hg revert -a 
hg update -r 5964 
make distclean 
vi Makefile.gnu           % Change optimization switches 
vi ../include/std/map.e   % Add ARM fix 
./configure 
vi config.gnu             % Make sure 'EUPHORIA=1' and not 0 
make interpreter          % Build eui only to save some time  

Hope this helps,
Ira

37. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 13, 2013
• 2982 views

the map.e change when building on the raspberry pi seems to cause a problem. (but it's a "cleaner" error than before :) )

Translating eui.ex to create 
rm -f /home/ukscone/euphoria/source/build/intobj/{*.c,*.o} 
(cd /home/ukscone/euphoria/source/build/intobj;eui -i /home/ukscone/euphoria/include  -d E32 /home/ukscone/euphoria/source/euc.ex  -nobuild -i /home/ukscone/euphoria/include -gcc    \ 
		-arch ARM \ 
		-c /home/ukscone/euphoria/source/eu.cfg /home/ukscone/euphoria/source/eui.ex ) 
 
/home/ukscone/euphoria/include/std/map.e:278 in function lookup()  
type_check failure, index_hash is 3633619608  
 
... called from /home/ukscone/euphoria/include/std/map.e:568 in procedure put()   
 
... called from /home/ukscone/euphoria/include/std/flags.e:19  
 
--> See ex.err  
make[1]: *** [/home/ukscone/euphoria/source/build/intobj/main-.c] Error 1 
make[1]: Leaving directory `/home/ukscone/euphoria/source' 
make: *** [interpreter] Error 2 

ex.err http://pastebin.com/rQJ9pF9v

39. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 13, 2013
• 2897 views

Ahh, the danger in making changes without understanding them! So I cross-compile Euphoria for the Pi on my x86-64 system, which means I use 64bit Eu to do the initial translation. I think this explains why I did not get this error, and my compiled binaries do run on the Pi. But does this mean I avoided the bug or just created a more complex one that will crop up later? Also, what does Eu use the lookup routine for? It seems to be called a lot on startup on some of the demo programs.

I'll also try out the gdb debugging today.

Thanks,
Ira

41. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 13, 2013
• 2887 views

just woken up (it's 8am here) and not had coffee yet but i'll build a debug version of the one where map.e starts to cause a problem in a few. overnight i got up to

Euphoria Interpreter v4.1.0 development 
   32-bit Linux, Using System Memory 
   Revision Date: 2013-01-16 13:27:32, Id: 5942:fc67d38623d0 

and so far so good

[i've been build a version & if t builds using it to build the next one i choose by moving down the children for a few steps & if i run out of children moving to the next one above]

43. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 13, 2013
• 2898 views

upto 5958:3b39b88f0ef5 now which is just before some changes to Makefile.gnu that caused it to try to use x86 assembler in parts of the build and the -O3 optimizations changes not to work as the strings don't exist to change :)

45. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 13, 2013
• 2854 views

thanks, i've just been following children from the last working build, that might explain some of the problems i had on a few builds. i told you i know squat about mercurial, i'm a fossil user (for my own stuff) and git user for gthub although only for cloning stuff i want to have not for sending revisions back

47. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 13, 2013
• 2878 views

took a look an hour ago and it looks like it is just automating the switch to the next changeset and keeping a list of the ones marked bad (and the instructions i found were for an earlier version to what i have installed as half the stuff doesn't work or has changed.

i'll have another look after lunch and when i finish the next bit of soldering i want to do

49. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 13, 2013
• 2881 views

Yes, that's pretty much what it does. Eventually, it will tell you which was the last good revision. And you don't have to worry about accidentally straying into a different branch or keep track of a list of revisions.

Matt

51. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 13, 2013
• 2861 views

Yes, that was the original check in of the updated map stuff. The next changeset fixed the integer / atom declaration.

Matt

53. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 13, 2013
• 2830 views

Yes. It sounds like somewhere in lookup() something is going wrong. Either the arithmetic or the bitwise operations isn't working correctly.

Matt

55. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 14, 2013
• 2789 views

This sounds like a translator bug. If you use an interpreter from before the map change, does t_map.e work with the new map.e? Translated?

Matt

57. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 14, 2013
• 2761 views

Assuming that the version of euc on your path is earlier than that, I would expect it to work.

Matt

59. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 14, 2013
• 2747 views

doesn't really tell us anything but i thought i'd try it just on the off chance as a way to bypass the bug/failure

use 5957 euc to build 5964 eui -- builds use the resultant 5964 eui to build 5964 eui -- fails (although it does run allsorts.ex, sieve8k.ex, ackermann.ex ok)

looks like i'm stuck on 5957 for a while :)

Ira: which lines did you change in lookup() to get it to work? my euphoria is very rusty esp. as i didn't do much with it after 2.2ish

61. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 14, 2013
• 2727 views

eui t_map.e ???

63. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 14, 2013
• 2728 views

Yes. We know that the translated version of the new map implementation is broken under ARM. I'm curious if the interpreted version is, too. This might tell us if it's something the translator is doing, or part of the common back end that implements bitwise and double arithmetic.

Here's the issue: There's something broken somewhere with doing things with atoms when they are stored as doubles (i.e., not euphoria 31-bit integers). The map algorithm may produce 32 (33?) bit integers, which cannot be stored in a euphoria integer when you're using a 32-bit version of euphoria (which is all we have for ARM right now). You'll either get the current infinite loop or a type check error if you switch the variable to be an integer.

Thinking about it, the commenting out of some includes (and having things work) suggests that the problem isn't with the translator, and perhaps some additional tests should be run. Ideally, all of them, of course. But highest priority right now, to figure out what's wrong with maps are:

• t_map.e
• t_math.e
• t_hash.e

Just go into the tests directory, and execute those with a working version of eui that you've built. Hopefully, something in there will fail and direct us towards an answer. If not, then we should probably try to devise a test based on the lookup() function to see what's going wrong. I know that ARM requires specific alignment of floating point numbers, and I suspect that something there may be amiss, though I would have expected it to crash and burn in that case.

Matt

65. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 14, 2013
• 2747 views

It's probably gotten into an infinite loop. You can add -all to the command line:

$ eui t_map.e -all 

...and it will print out when a test succeeds or fails. But I wouldn't worry about it in this case, since maps seem pretty broken. Hopefully the problem is covered by something in t_math.e or t_hash.e. More likely, t_math.e, I suspect.

Matt

67. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 14, 2013
• 2731 views

5957 eui t_map.e -all kills itself

eui t_map.e -all 
  passed: map new #1 
  passed: map m1 get -5 
  passed: map m1 get 0 
  passed: map m1 get 5 
  passed: map m1 get 6 
  passed: map m1 get 8 
  passed: map m1 get -199999999999 
  passed: map m1 get "XXXXXXXXXX" 
  passed: map m1 size#1 
  passed: map m1 keys 
  passed: map m1 has #1 
  passed: map m1 has #2 
  passed: map m1 has #3 
  passed: map m1 has #4 
  passed: map m1 size#2 
  passed: map m1 get 5#2 
  passed: map m1 get 1000 
Killed 

69. Re: OpenEuphoria on the raspberry pi

• Posted by mattlewis (admin) Feb 14, 2013
• 2699 views

Thanks! It looks like we have a problem with bitwise operations. Looking at t_math.e, I notice that we have no and_bits tests, though it is used in all of the tests that failed.

Matt

71. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 14, 2013
• 2714 views

Thanks guys for hunting this down! I'm on camping trip this weekend and won't be able to help debug, but I appreciate the effort!

Thanks,
Ira

73. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 15, 2013
• 2652 views

 
? and_bits( 0xffff_ffff, 1233.5 + 0.5 ) 
? and_bits( 0xffff_ffff, 1234 ) 
? and_bits( 0xffff, 1234 ) 
 

yup 5957 does

eui -v 
Euphoria Interpreter v4.1.0 development 
   32-bit Linux, Using System Memory 
   Revision Date: 2013-01-18 15:52:45, Id: 5957:e9e11b19737a 
ukscone@welham ~/euphoria/source $ cat test.ex 
? and_bits( 0xffff_ffff, 1233.5 + 0.5 )  
? and_bits( 0xffff_ffff, 1234 )  
? and_bits( 0xffff, 1234 )  
ukscone@welham ~/euphoria/source $ eui test.ex 
1234 
1234 
1234 

75. Re: OpenEuphoria on the raspberry pi

• Posted by jimcbrown (admin) Feb 15, 2013
• 2672 views

elif echo "$UNAME_MACHINE" | grep ARM > /dev/null; then 

elif echo "$UNAME_MACHINE" | grep arm > /dev/null; then 

Done.

77. Re: OpenEuphoria on the raspberry pi

• Posted by Jerome Feb 15, 2013
• 2639 views

Does this explain it? I have this test code:

-- andbits.ex 
atom index_hash = 0xffff_ffff 
index_hash *= 4 
? index_hash 
index_hash += 10 
? index_hash 
? and_bits( 0xffff_ffff, index_hash ) 

On x86 I get:

[ /tmp]$ eui -v 
Euphoria Interpreter v4.1.0 development 
   32-bit Linux, Using System Memory 
   Revision Date: 2013-01-24 14:49:03, Id: 5965:ef579d0f2018 
[ /tmp]$ eui andbits.ex 
1.717986918e+10 
1.717986919e+10 
6 

On Raspberry Pi:

[ /tmp]$ eui -v 
Euphoria Interpreter v4.1.0 development 
   32-bit Linux, Using System Memory 
   Revision Date: 2013-01-24 14:49:03, Id: 5965:ef579d0f2018 
[ /tmp]$ eui andbits.ex  
1.717986918e+10 
1.717986919e+10 
4294967295 

Thanks,
Ira

79. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 16, 2013
• 2528 views

can someone running on x86 check that this change to Dand_bits() in be_runtime.c still works as expected?

object Dand_bits(d_ptr a, d_ptr b) 
/* double a AND b */ 
{ 
        double maxplus1 = ((double)UINTPTR_MAX) + 1; 
        return and_bits( (uintptr_t)fmod(a->dbl,maxplus1), (uintptr_t)fmod(b->dbl,maxplus1)); 
} 

it seems so far to be working as expected ont eh raspberry pi but i'd like to make sure it isn't mucking up x86

cat and_bits.ex 
-- andbits.ex  
atom index_hash = 0xffff_ffff  
index_hash *= 4  
? index_hash  
index_hash += 10  
? index_hash 
? and_bits( 0xffff_ffff, index_hash ) 
ukscone@welham ~/euphoria/source $ build/eui and_bits.ex 
1.717986918e+10 
1.717986919e+10 
6 

81. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 16, 2013
• 2457 views

yes, that was just a quick check to make sure it didn't mess anything up. i'm in the process of putting it inside an #ifdef. i suspect that or_bits, xor_bits, shift_bits etc will need to be changed too.

unfortunaetly the thread where i got help with this is in the raspberry pi mod only forum but as i think it might be interesting to the devs here i'll pastey the relevant posts.

http://openeuphoria.org/pastey/199.wc

83. Re: OpenEuphoria on the raspberry pi

• Posted by jimcbrown (admin) Feb 17, 2013
• 2457 views

You should be able to do this by installing a 32bit cross compiler on your x86_64 box and then installing multi-arch packages or a 32bit chroot environment to run the binary.

The results for 32bit x86:

17179869180.000000 
17179869190.000000 
400000006 
6 

85. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 17, 2013
• 2410 views

quick & dirty patch to fix and_bits() on ARM, not the best way to do it but it seems to work and fixes 6 of the 11 failures of t_math.c on ARM

http://openeuphoria.org/pastey/202.wc

87. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 18, 2013
• 2323 views

yes i thanks to a friend have a new FIXED & WORKING version, the problem with that patch is it doesn't handle negative numbers correctly.

i'm working up a patch and have only fixed and_bits so far but i'm at 0 failures now

89. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 18, 2013
• 2438 views

Try this patch

http://openeuphoria.org/pastey/204.wc

seems to be fine on my Raspberry Pi but YMMV on other ARM devices.

however it's been suggested to me that the current *_bits() might not follow what is in the docs. i'm seeing spots in front of my eyes at the moment after spending the morning reading ietf rfc's for something else so anyone want to check?

91. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 18, 2013
• 2234 views

A lot of discussion has occurred between the people who have been helping me & myself about whether the changes are matching what the docs currently say. My opinion was work to what the 32bit x86 version does rather than what the docs say as i'd prefer at the moment to have a working version rather than a "correct according to the docs" version and let everything work itself out in the wash eventually if it is decided by the powers that be that the ARM version is worth spending time on.

93. Re: OpenEuphoria on the raspberry pi

• Posted by jimcbrown (admin) Feb 19, 2013
• 2218 views

I think this is a good idea, as the more similiar the ARM version behaves like th x86 32bit version, the fewer differences Euphoria code needs to be aware of, and the more programs that will just work without change on ARM.

Once this effort is finished, I guarantee that these patches will be pushed into 4.1.0

95. Re: OpenEuphoria on the raspberry pi

• Posted by rkdavis Feb 19, 2013
• 2206 views

it's been a while since I used a os image for the raspberry pi with qemu, there's some twiddiling required to get it to boot. when i didn't have a raspberry pi and needed to build/test something on arm i'd just grab aboriginal linux and one of the prebuilt images from it as if you don't need to mess with graphics or gpio then it'll do for just testing the arm code and it's a lot less hassle than messing with getting the official raspberry pi images working.