i've been playing around with some arm boards for a while now and i managed to port some of our software fairly successfully. linking to our c libraries works well and it's amazing how much less fuss it was to cross compile the pascal sources.
i did find a couple of issues, though. i thought i'd put them up here before making bug reports. all of these are on a little endian arm with soft float, using latest svn.
1) writeln(-2/3) crashes with this:
Runtime error 205 at $00015498
$00015498 FLOAT_RAISE, line 111 of latest/rtl/inc/genmath.inc $0001002C float64_mul, line 4387 of latest/rtl/inc/softfpu.pp $000195B4 STR_REAL, line 361 of latest/rtl/inc/real2str.inc $000300A8 fpc_write_text_float, line 695 of latest/rtl/inc/text.inc $000081C4 main, line 19 of armtest.pas
$000080F4
this means that i had to check for a negative sign every time i wanted to do a float operation (luckily i don't have many) - quite annoying. writeln(2/3) works perfectly, though.
2) BoolToStr returns '0' for False and '-1' for True...
3) if func 0 then ...
where func is a function (of int) in a shared c lib. this didn't work
- no crashes, but just returned non zero all the time. when i changed this to ret := func; if ret 0 then... everything worked o.k. sorry this is vague, i don't really know how to look into this.
4) i also had a bit of a problem when i tried to link to libc from my pascal program:
/opt/slugosle/bin/arm-linux-ld: ERROR:
/usr/lib/fpc/2.3.1/units/arm-linux/rtl/prt0.o uses hardware FP, whereas armtest uses software FP
/opt/slugosle/bin/arm-linux-ld: Warning:
/usr/lib/fpc/2.3.1/units/arm-linux/rtl/prt0.o does not support interworking, whereas armtest does
/opt/slugosle/bin/arm-linux-ld: failed to merge target specific data of file /usr/lib/fpc/2.3.1/units/arm-linux/rtl/prt0.o
(list goes on like this for many of the .o files in the rtl).
so for some reason ld thinks that the rtl is compiled for hardware float (which is not the case). i also don't know how fpc handles the interworking business (i had to compile my c libs with -mthumb-interwork to make the warnings go away). ld does have a couple of compatibility options for interworking, but i didn't use any and it still seems to work o.k.
all in all, i'm impressed. especially at the ease of fpc cross compilation. maybe fpc should offer a softfloat crossarm binary that people can use to compile for the nslu2 and similar devices?
now onto the big endian board again...
thanks
henry