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
$81C4 main, line 19 of armtest.pas
$80F4
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
