Hi,

questions...
Is -CfSOFT supported on arm 2.0.5?
Do I need to add/define something when I build the crosscompiler to get softfloat support?
Is changing system_arm_linux_info.endian to endian_big in fpc/compiler/systems/i_linux.pas enough? I see in
references to {$if defined(CPUARM) and defined(FPUFPA)} and {$ifdef FPC_LITTLE_ENDIAN} but no FPUSOFT or FPC_BIG_ENDIAN.

I have successfully made a crosscompiler for big endian arm and it (ppcarm) compiles without problems and the resultant elf executes on the arm.

But if I use any floating point it crashes out with...

$ ppcarm -XParm-linux- -Xs -XX -CpARMV5 -CfSOFT -n -B -vewhli \ -Fu~/arm-linux-fpc.i386-linux/lib/fpc/2.0.5/units/arm-linux/rtl \ floattest
Target OS: Linux for ARM
Compiling floattest.pp
2 67/864 Kb Used
floattest.pp(8,9) Fatal: Internal error 200308252
floattest.pp(8,9) Fatal: Compilation aborted

This is with...
program floattest;
Var
 a, b, c: single;
begin
 a := 1.5;
 b := 2.5;
 c := a * b;
 writeln(c);
end.
$ ppcarm -i
Free Pascal Compiler version 2.0.5

Compiler Date : 2006/10/24
Compiler CPU Target: arm

Supported targets:
Linux for ARM

Supported CPU instruction sets:
ARMV3
ARMV4
ARMV5

Supported FPU instruction sets:
SOFT
LIBGCC
FPA
FPA10
FPA11
VFP

Thanks for any help here.
Terry

Hi, questions... Is -CfSOFT supported on arm 2.0.5?

Unlikely. 2.1.1 has softfloat support for at least wince and gba.

Do I need to add/define something when I build the crosscompiler to get softfloat support? Is changing system_arm_linux_info.endian to endian_big in fpc/compiler/systems/i_linux.pas enough?

In theory yes, in practice probably not.

In the ARM-Linux developers list I have been told that ARM always is used in little endian mode. I have no idea why.

-Michael

Michael Schnell wrote

> In theory yes, in practice probably not. In the ARM-Linux developers list I have been told that ARM always is used in little endian mode. I have no idea why.

Intel XScale (at least) is used as big-endian arm.

Micha

That's also the reason why there is no tested arm be support. I've never seen a decent arm system unsing be.

Op Wed, 13 Dec 2006, schreef Micha Nelissen:

Hola, most modern ARM cpu's support big endian, that is not the point. Question is how many an big endian platforms exists, and this is not so popular, because even if you switch the cpu to big endian, the underlying hardware remains little endian (with the cpu doing the conversion). This means that driver code etc. suddenly needs to care about endian conversions.

An Intel Xscale system running Linux or Windows CE is always running in little endian mode, which propably covers an already important part of the ARM cpu's in use.

Daniël

Daniël Mantione wrote

An Intel Xscale system running Linux or Windows CE is always running in little endian mode, which propably covers an already important part of the ARM cpu's in use.

I'm using an XScale armeb (big-endian) debian distribution

Micha Nelissen wrote

I'm using an XScale armeb (big-endian) debian distribution here at work.

The DigiConnect ME and WI-ME modules run ARM7 big endian as well. Not sure about the other Digi modules. There is a linux implementation for these as well as their native Net+OS.

Jeff.

Digest mode... forgive the de-threading.

I am using a Linksys NSLU2. The NSLU2 is based on an Intel XScale IXP420 processor, device has 32MB of SDRAM, 8MB of NOR
Flash, built-in 10/100 (not yet supported in litte-endian mode), and dual USB 2.0 ports. The Linksys firmware, bootloader, kernel, proprietary ethernet drivers are big endian. There is a debian LE OS but I will lose the ethernet port.

I will try with fpc 2.1.x - but I have had no problems to date with the 2.0.4 or 2.0.5 armeb fpc other than the current issue with floating point. I am at 2440 lines of code - with the application talking to remote I/O and VFD screen via USB serial for machine control.

If I compile with {E+} the code compiles but running it on the NSLU2 it just sits there. Running under qemu-armeb works either way.

I am thinking that maybe I need to compile ppcarm with the gcc from the Optware crosstool toolchain...

$ls ~/optware/toolchain/armv5b-softfloat-linux/gcc-3.3.5-glibc-2.2.5/bin armv5b-softfloat-linux-addr2line armv5b-softfloat-linux-cpp armv5b-softfloat-linux-gcov armv5b-softfloat-linux-ranlib fix-embedded-paths
armv5b-softfloat-linux-ar armv5b-softfloat-linux-g++ armv5b-softfloat-linux-ld armv5b-softfloat-linux-readelf armv5b-softfloat-linux-as armv5b-softfloat-linux-gcc armv5b-softfloat-linux-nm armv5b-softfloat-linux-size armv5b-softfloat-linux-c++ armv5b-softfloat-linux-gcc-3.3.5 armv5b-softfloat-linux-objcopy armv5b-softfloat-linux-strings armv5b-softfloat-linux-c++filt armv5b-softfloat-linux-gccbug armv5b-softfloat-linux-objdump armv5b-softfloat-linux-strip

How would I do this if this is indeed my problem?

Just an idea: is it possible for your code to use fixed point arithmetic, thereby avoiding the need for floating point entirely ?

I'm not sure if it's possible to use an external softfloat library from within fpc (this seems to be your question).

Micha

Enabling the softfpu unit for linux shouldn't be that hard. But it needs somebody who has access to such a system :)

however some hardware is wired up for big endian (the linksys NSLU2 springs to mind) and hence is a pain to get little endian linux running on (i belive the network now works in little endian mode but the front panel lights are still broken)

however some hardware is wired up for big endian (the linksys NSLU2 springs to mind) and hence is a pain to get little endian linux running on (i belive the network now works in little endian mode but the front panel lights are still broken)

AFAIK, the SLUG Linux is running since a log time (I don't know with what shortcomings, but the Network works, otherwise it would not be useful at all.) I seem to remember that a new greatly enhanced version has been released a shout time ago.
- Michael

Indeed

(I don't know with what shortcomings, but the Network works,

The slug as shipped by linksys runs armeb linux and most of the earlier unofficial attempts were also armeb based.

Later they got little endian arm linux to work on the thing but for a long time the built in network adaptor didn't work with little endian linux (thats now fixed i belive) and last i checked front panel lights still weren't working in little endian linux.

For TCP/IP hardware big endian just plain makes sense as network byte order is big endian. I dunno how much difference this and the byteswapping drivers make to practical performance though.

finally some of us would quite like to have a big endian system arround for testing on and as big endian systems go the slug is cheap!

I might be interested for creating Lazarus and fpc snapshots (see http://wiki.lazarus.freepascal.org/Lazarus_Snapshots_Downloads), if there is actual demand for such snapshots. No need in creating files and maintaining build scripts, if nobody downloads them.

How people are using or testing fpc on sparc-linux?

Vincent

finally some of us would quite like to have a big endian system arround for testing on and as big endian systems go the slug is cheap!

Well, for FPC developers (as well as others) I make accounts available to those interested via SSH. I run PPC under Debian/Sparc on a Sun Ultra 5.

Well considering it looks like I'm the unofficial maintainer of the Sparc-Linux port :) I use it and Lazarus on my Ultra 5. But as I said in my FPC blog (http://www.net261.com:81/wordpress/ in the FPC category) I build new binaries whenever new code is downloaded from SVN.

Well as far as Lazarus snapshots go, well, I already started compiling Sparc Linux snapshots of that as well -- will be doing Win32 ones as well and making them available from my site if anyone would be interested.

BTW.

On the long run I am interested in making (embedded) FPC programs run on (our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming that there is no special problem using a displayless ARM9 device (like a slug) for FPC programs ?

-Michael

BTW.

On the long run I am interested in making (embedded) FPC programs run on (our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming that there is no special problem using a displayless ARM9 device (like a slug but low endian) for FPC programs ?

-Michael

BTW.

On the long run I am interested in making (embedded) FPC programs run on (our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming that there is no special problem using a displayless ARM9 device (like a slug but little endian) for FPC programs ?

-Michael

I'am currently preparing the rtl for embedded purposes. Of course, using FPC on an embedded device isn't install and play like on common OSes simply because embedded devices differ and there is no real standard regarding output format. But it should be doable.

afaict the slug is quite high end as embedded stuff goes and should be able to handle the full rtl with no problems.

just a matter of sorting out the softfloat issues and if you decide to run in big endian mode changing the endian setting and fixing anything that change breaks.

Great !

Thanks. Please keep me posted on this issue.

Of course the inter thread communication we were talking about is to be used in that project, too.

-Michael

Thanks. Please keep me posted on this issue.

http://svn.freepascal.org/svn/logs/fpc-trunk.log
;)