Hello,

Looking at: http://www.freepascal.org/down/arm/linux-austria.var

There is no download for 2.4.2

Was the page not updated or is something needed to get this working?

thanks,

There is no release for arm-linux.

Florian Klaempfl wrote

There is no release for arm-linux.

Maybe I could create one, or maybe even a simple zip file with a snapshot of FPC 2.5.1 for linux-arm

Is there a list of which files are created when running

make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/home/felipe/Programas/fpctrunk/binutils OPT=-dFPC_ARMEL INSTALL_PREFIX=/usr/

?

Is everything inside /usr/lib/fpc/2.5.1/ ?

So I supposed that I need /usr/lib/fpc/2.5.1/ + .fpc.cfg + ppcarm link to /usr/local/bin/ + binutils

Even if only I use it, I think that a Linux-arm pre-compiled cross-compiler + pre-compiled binutils will already save me some time when I need to change my development computer.

thanks,

Hi,

official snapshots for 2.4.3/2.5.1 ARMv5 eabi with softfloat are on the ftp.

ftp://ftp.freepascal.org/fpc/snapshot/v24/arm-linux/fpc-2.4.3.arm-linux.tar.gz ftp://ftp.freepascal.org/fpc/snapshot/v25/arm-linux/fpc-2.5.1.arm-linux.tar.gz

They are updated only now and then manually, but they provide a starting point.

The problem with a 2.4.2 release was, that just before release we found that one critical patch had not been applied. Since arm-linux is not a tier-1 target, we did not want to delay the release any further (e.g. go another round). So at the moment, there is no 2.4.2 for arm-linux.

Anyway, I have a 2.4.2 arm-linux with that patch applied at

http://members.yline.com/~tom_at_work/fpc-2.4.2.UNOFFICIAL.arm-linux.tar . Again ARMv5 eabi with softfloat.

This is not an official 2.4.2 release build, just something that anybody could produce using the release_2.4.2 tag with that patch mentioned above applied. This is not an official build, report bugs against 2.4.3.

Thomas

[...]

Even if only I use it, I think that a Linux-arm pre-compiled cross-compiler + pre-compiled binutils will already save me some time when I need to change my development computer.

But if you're considering making it public wouldn't it be better to use the "official" 2.4.2 release, at least until somebody really had to have a recent fix or extension? I had to go briefly onto 2.5.1 for ARM and found that it refused to compile Lazarus- if I recall correctly there was a conditional in the source where anything that wasn't 2.4 was assumed to be 2.2 or older.

Mark Morgan Lloyd wrote

But if you're considering making it public wouldn't it be better to use the "official" 2.4.2 release, at least until somebody really had to have a recent fix or extension?

I think too that it should be made official. It will also be better when people can use 2.4.2 + this particular patch then if people need to test snapshots which change all the time.

I had to go briefly onto 2.5.1 for ARM and found that it refused to compile Lazarus- if I recall correctly there was a conditional in the source where anything that wasn't 2.4 was assumed to be 2.2 or older.

You should try again, the latest Lazarus source code should compile with fpc 2.5.1

I will, but since I'm running natively on a system with very limited memory running a complete build takes a week.

Lazbuild using 2.4.2 on armel generates working programs.

In our previous episode, Mark Morgan Lloyd said:

Yesterday I've made a crosscompiling 2.5.1 snapshot that is able to crosscompile binaries with shared libs support to Sheeva (eabi=4) from Windows.

I suppose it would work with any armel -Cfsoft -Cparmv5 device. I have not enabled thumb, but I seem to have it (see cpuinfo below)

Unfortunately, my sheeva doesn't have X (yet); it's root is on flash.

I also uploaded armel cross-binutils windows->arm-linux. (see msg yesterday)

Processor : ARM926EJ-S rev 1 (v5l)
BogoMIPS : 1192.75
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 16384
I assoc : 4
I line length : 32
I sets : 128
D size : 16384
D assoc : 4
D line length : 32
D sets : 128

Hardware : Feroceon-KW
Revision : 0000
Serial : 0000000000000000

In our previous episode, marcov said:

> Lazbuild using 2.4.2 on armel generates working programs.

aw, blew up the message, forgot to ask the real question:

To experiment with thumb, should I enable interworking in binutils?

I saw that but figured that everybody else would be saying "well done" and I didn't need to comment :-)

One thing I would say though is that if you do load X onto a tight system use FluxBox rather than Gnome or KDE, and keep screen size (whether via XDMCP or VNC) small.

I've got a problem running lazarus (i.e. as distinct from lazbuild) on SPARC and ARM, if I can pin it down I'll raise it elsewhere.

I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised? I've got a board here- basically an ARM-based PC- that I could fire up and use for testing.

Mark Morgan Lloyd wrote

I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised?

What do you mean by "native CE"?

Running the compiler etc. on CE, rather than cross-compiling.

Just interested, how would you do this? Does win ce have an ssh server?

Henry

Unless I'm badly missing the point: these boards have full video etc. so can run programs in exactly the way that "real" computers do.

Mark Morgan Lloyd wrote

I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised? I've got a board here- basically an ARM-based PC- that I could fire up and use for testing.

Any exercising for ARM and Windows CE would be good. Specially if you can run the compiler tests.

Oh, right. The devices I've used in the past had no keyboard and a small screen, so this would've been hard.

Henry

In our previous episode, Mark Morgan Lloyd said:

Afaik yes. Sb occasionally reported about more desktop like setups and usage with i386-wince in the past, but afaik I haven't seen similar ones for arm-wince.

(and not that much about the practicalities on arm-linux too for that matter, I still have to install X on my sheeva to start with that)

I'll get onto it, but it will be fairly slow work- I'm interleaving a lot of stuff here.

I notice somebody's done a SPARC/Solaris binary, I already want to get Solaris v8 running to evaluate a Sun board that's only supported by that OS, and I might get v10 going as well- I've got hardware.

I don't have x64 but I assume that it's already getting quite a lot of attention, and I don't have MIPS. I noticed mention of IBM's zSeries in the wiki so I've fleshed out the ZSeries page with some info I had to hand, I reckon that just leaves Itanic as far as "computers" (i.e. as distinct from embedded targets) go.

I've got 4x boards here that are basically ARM-based PCs, even booting from an fdisked CompactFlash. Trouble is that they've only got CE on them, and the manufacturer quoted something outrageous to "upgrade them to Linux firmware"- which in practice I suspect only means replacing the CF. One of my forthcoming activities is to disassemble the CF boot sector and try to boot something like OpenFirmware, i.e. make the board look very much like the Sun and Mac systems I've got.

Hello Marco,

Where have you hosted your cross-compiler windows --> arm-linux ?

Plus, I would like to mention again that it would be very good to convert the unofficial linux --> arm-linux cross-compiler into a release.

I am writing articles about Android programming and without suitable FPC releases targetting arm-linux things will get confuse for beginners.

My current B plan in case we really lack official cross-compilers targetting arm-linux is hosting myself these cross-compilers in one of my source forge projects and link these from my articles (in order to have a stable position from which new users can download them).

thanks,

Felipe Monteiro de Carvalho

Schatzl Thomas wrote

Anyway, I have a 2.4.2 arm-linux with that patch applied at http://members.yline.com/~tom_at_work/fpc-2.4.2.UNOFFICIAL.arm-linux.tar . Again ARMv5 eabi with softfloat.

Hello,

Is that arm-linux --> arm-linux ?

I thought that it was a x86-linux -> arm-linux cross-compiler ...

Schatzl Thomas wrote

 official snapshots for 2.4.3/2.5.1 ARMv5 eabi with softfloat are on the ftp. ftp://ftp.freepascal.org/fpc/snapshot/v24/arm-linux/fpc-2.4.3.arm-linux.tar.gz ftp://ftp.freepascal.org/fpc/snapshot/v25/arm-linux/fpc-2.5.1.arm-linux.tar.gz

I suppose that these are also arm-linux -> arm-linux, correct?

So, any idea how to create a package for x86-linux -> arm-linux?

For building the cross-compiler I use:

make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/home/felipe/Programas/fpctrunk/binutils OPT=-dFPC_ARMEL INSTALL_PREFIX=/usr/

In our previous episode, Felipe Monteiro de Carvalho said:

Where have you hosted your cross-compiler windows --> arm-linux ?

Nowhere. It was made for a bounty. It was EABI4 btw (for sheeva). iirc I commented on the main sheeva thread in the lazarus forum about it.

The binutils are on FTP though, and the wrapper I used is in the fpcbuild repository (it is a wrapper around AS.exe that sets eabi version, since the binutils on FTP are eabi 0)

many variables to support. A more logical solution would be to make an installer for windows that allows to configure some variables and generates an install.

Maybe something like that for linux too. (but distributing a binary instlaler is harder on Linux)

I am writing articles about Android programming and without suitable FPC releases targetting arm-linux things will get confuse for beginners.

I've ordered an OpenRD that hopefully arrives in the coming weeks, and then I'll pick this up again. I hopefully also can unbrick the device that I'm current targeting (Seagate GoFlex NET)

My current B plan in case we really lack official cross-compilers targetting arm-linux is hosting myself these cross-compilers in one of my source forge projects and link these from my articles (in order to have a stable position from which new users can download them).

I don't mind having some installs for certain installs on FTP (and more importantly I don't think Michael/Karoly won't mind either, since they are the owners).

But that is something different from commiting to maintaining a *release*.

Marco van de Voort wrote

Nowhere. It was made for a bounty. It was EABI4 btw (for sheeva).  iirc I commented on the main sheeva thread in the lazarus forum about it.

I don't know what sheeva is (except for the mortal kombat character =D ), but to me it looks like as if this installer would work for Android too. Android expects eabi and soft-float.

Is the installer to remain private according to your agreement or could it be made public?

from x86-linux to arm-linux (eabi, softfloat). That should work for Android.

Try using crosszipinstall.

Henry

In our previous episode, Felipe Monteiro de Carvalho said:

Well, primarily it is a nonstandard transliteration of a major Hindu deity Shiva I guess :-)

Seriously, Sheeva(plug) is development kit for the Kirkwood class of ARM processors by Marvell.

http://en.wikipedia.org/wiki/SheevaPlug

Lazarus threads (among others:)

http://forum.lazarus.freepascal.org/index.php/topic,8057.15.html http://forum.lazarus.freepascal.org/index.php/topic,8084.0.html

Is the installer to remain private according to your agreement or could it be made public?

There is no installer, it is just a 2.4.2 win32 install with the relevant binutils and a snapshot installed over it, and then zipped.

But as said, it is EABI 4, and that is in every .o file. So if Android is EABI 5, it is useless, since afaik they are linking incompatible.

And no, the results of the bounty were not private. It is simply crafted for a specific device. Since it was all a bit messy, and I did all this on a device that has already been experimented on a lot, I simply wanted to wait till I have my new device, and redo everything for EABI 5 (since most newer distros use that), and move on.

Devices
- the above Sheeva 512MB ram. Can bootstrap and run testsuite on USB2 HDD OS is on SD flash card
- the Seagate WD flex which is an "release" 128MB version of the sheeva. Currently bricked
- OpenRD Ultimate, which is a Kirkwood device with all I/O equiped (including ESATA and PCIex x1), currently in transit from US/China.

I use either FreeBSD or Windows, and only use linux x86 for bounty cases (since it requires me to startup a different machine). I also have no Android devices.

My interest (and the bounty providers) is lowpowered servers, not mobile.

hummm,

I installed the installer from Schatzl Thomas to test it and after that I reinstalled my build from svn trunk and it no longer finishes building:

Hint: Start of reading config file /home/felipe/.fpc.cfg Hint: Start of reading config file /etc/fpc.cfg
Hint: End of reading config file /etc/fpc.cfg
Hint: End of reading config file /home/felipe/.fpc.cfg Free Pascal Compiler version 2.5.1 [2011/01/18] for arm Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling turbochessclock4android.pas
Compiling androidpipescomm.pas
Compiling androidactivity.pas
Compiling androidui.pas
Compiling javalang.pas
Assembling javalang
javalang.pas(46) Error: Assembler
/home/felipe/Programas/fpctrunk/binutils/as not found, switching to external assembling
javalang.pas(46) Fatal: There were 1 errors compiling module, stopping

The strange thing is that /home/felipe/Programas/fpctrunk/binutils/as works normally (it is a copy of arm-linux-as), I just checked o.O

any ideas?

thanks,

Have you checked with the -vt option to see what the compiler is trying to load?

I had the same problem and disabled linking (-sh) the ran ppas.sh and it linked no problem.

I don't know why this is the case.

Andrew

Mark Morgan Lloyd wrote

Have you checked with the -vt option to see what the compiler is trying to load?

Thanks, indeed, it seams that something changed in the code to search for the binutils and I had to update my .fpc.cfg, thanks. Previously I had used:

#IFDEF CPUARM
-XP/home/felipe/Programas/fpctrunk/binutils/
-Xr/usr/lib/fpc/2.5.1/units/arm-linux/rtl/
# -Xr/home/felipe/Programas/fpctrunk/libcross
# -XR/home/felipe/Programas/fpctrunk/binutils/
-darm
-Tlinux
#ENDIF

Which is somewhat wrong, but it worked previously. Now that I updated my fpc I had to disable the line
-XP/home/felipe/Programas/fpctrunk/binutils/

And I then used binutils in /usr/local/bin

Felipe Monteiro de Carvalho wrote

Which is somewhat wrong, but it worked previously. Now that I updated my fpc I had to disable the line -XP/home/felipe/Programas/fpctrunk/binutils/

The correct parameter would be -FD/home/felipe/Programas/fpctrunk/ binutils/

Jonas

Henry Vermaak wrote

Try using crosszipinstall.

I tryed:

make crosszipinstall CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=/home/felipe/Programas/fpctrunk/binutils OPT=-dFPC_ARMEL INSTALL_PREFIX=/usr/

and

make crosszipinstall CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=/home/felipe/Programas/fpctrunk/binutils OPT="-dFPC_ARMEL -FD/home/felipe/Programas/fpctrunk/binutils" INSTALL_PREFIX=/usr/

but:

make -C gtk2 install
make[5]: Entering directory `/home/felipe/Programas/fpctrunk/packages/gtk2' /home/felipe/Programas/fpctrunk/compiler/ppcrossarm -Parm -Ur -Xs -O2 -n -Fusrc -Fusrc/glib -Fusrc/atk -Fusrc/pango -Fusrc/pangocairo -Fusrc/gtk+/gdk-pixbuf -Fusrc/gtk+/gdk -Fusrc/gtk+/gtk -Fusrc/libglade -Fusrc/gtkglext -Fusrc/gtkext -Fusrc/gtk2x11
-Fu/home/felipe/Programas/fpctrunk/rtl/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/pasjpeg/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/hash/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/paszlib/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/fcl-base/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/fcl-image/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/x11/units/arm-linux -Fu/home/felipe/Programas/fpctrunk/packages/cairo/units/arm-linux -Fisrc/gtk2x11/include -FD/home/felipe/Programas/fpctrunk/binutils -FE. -FUunits/arm-linux -Fl/usr/lib/gcc/i586-manbo-linux-gnu/4.4.3 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -Fl/usr/X11R6/lib -dFPC_ARMEL -darm -dRELEASE src/buildgtk2.pp
/usr/bin/as: unrecognized option '-mfpu=softvfp'
buildgtk2.pp(37) Error: Error while assembling exitcode 1 buildgtk2.pp(37) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted

No idea why it is using /usr/bin/as when it should use a cross-binutil

For what it's worth, I now use -vt as standard and it turned out to be particularly useful last week when I was fiddling with Solaris since in some cases there are /three/ copies of some utilities: Sun, Berkeley and GNU.

However I usually filter the output through a Perl script, this discards excessive "noise" and ends up saving the compilation command plus a full cross-reference of what was found where.

Try to replace "crosszipinstall" with "info" in your command. This will tell you what tools it's trying to use.

What I do, is add the directory where I've installed my binutils to the path, like this:

export PATH=/opt/arm-linux/bin/:$PATH

This directory contains the cross binutils with the prefix "arm-linux-".

Then I can build it like this:

make -s clean crossall crosszipinstall FPC="/path/to/bootstrap/ppc" CPU_TARGET=arm NOWPOCYCLE=1 OPT="-dFPC_ARMEL" CROSSOPT="-CfSOFT" BINUTILSPREFIX=arm-linux-

Then you know the compiler will look for arm-linux-as and arm-linux-ld, which will save you some confusion. You can also use CROSSBINDIR instead of changing the path.

Henry

Felipe Monteiro de Carvalho wrote

Android expects soft-float.

Really ?

I feel that This does not make sense, as, AFAIK, the new ARMs do provide floating point in hardware.

-Michael

Michael Schnell wrote

Really ? I feel that This does not make sense, as, AFAIK, the new ARMs do provide floating point in hardware.

Some phones have hardware floating point, the majority not.

I suppose that FPC can't currently auto-detect, can it? If not, then
the only safe choice is soft-float

Felipe Monteiro de Carvalho wrote

Some phones have hardware floating point, the majority not. I suppose that FPC can't currently auto-detect, can it?

That's not a matter for the compiler or RTL to auto-detect. You need a completely different binary if you want to use hardware floating point support. At best, you should be able to build a "fat" binary like on Mac OS X and the OS will launch the version that's most appropriate for the current hardware platform.

Jonas

Felipe Monteiro de Carvalho wrote

Some phones have hardware floating point, the majority not.

I'm not in a position to estimate the counts of Android devices that have an FPU vs those that don't, or suggest that all relevant of them have.

But AFAIK, when building the Linux Kernel for AR; chips without FPU, you can include an FPU simulation. With that the user software (other than slower execution) does not notice that there is no FPU. As this only costs some hundred bytes of memory, I do suppose that the Kernel for Android devices might be done in that ways.

-Michael

No. It doesn't.

Then the manufacturers are not using this linux kernel option, because software which uses the FPU will crash at startup in the devices without a FPU. And I am 100% sure because I tested several devices and several source technologies (FPC apps and also JITed Javascript).

It might, but afaik, it's not. Probably because it's really expensive to trap the illegal instructions and emulate them.

There is another consideration, though: float abi. You can build a toolchain that enables use of an fpu, but still passes floats in int registers or on the stack (-mfloat-abi=softfp). This is how the android toolchain is configured. I don't think fpc can do this, though.

Henry

How did it crash? Your crashes may be due to the fact that fpc passes floats incorrectly in function calls, too.

Henry

Just to elaborate, if it crashes with SIGILL, then the device really has no fpu.

Henry

Henry

Henry Vermaak wrote

There is another consideration, though: float abi. You can build a toolchain that enables use of an fpu, but still passes floats in int registers or on the stack (-mfloat-abi=softfp). This is how the android toolchain is configured. I don't think fpc can do this, though.

Actually, the softfp abi is the only abi that FPC supports when using VFP: http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_VFPv2_and_VFPv3

Jonas

Excellent, thanks!

Henry

I have a few questions for the ARM team. I am not working on the ARM port but basing mine on it to start with.
I am porting FPC to the AVR32. I am starting with the AT32UC3C0512C, AT32UC3C1512C, AT32UC3B0256ES and AT32UC3B064
and will eventually support the rest. This port will not support an OS at all, it is for embedded projects like we usually do in C or assembler. I will have units for digital filters, convolution, waveform generation, CAN, LIN, USB, LCD, etc ...

The UC3C series has a single precision hardware float and dsp. The UC3B series has context environment, meaning has shadow registers kind of like the NEC devices. When you get into an interrupt the interrupts has its own set of registers so you do not need to push any registers on the stack.
The UC3A have some similarity to the UC3C series except that the UC3C series is automotive and can run at +5V. The UC3C devices are fully ppap qualified.
On the UC3C devices the hardware floats uses the regular registers (16 of them) and not its own as the ix86 or ARM.

My questions are at the end of the list that follows.

AT32UC3A0128,
AT32UC3A0256,
AT32UC3A0512,
AT32UC3A1128,
AT32UC3A1256,
AT32UC3A1512,
AT32UC3B064,
AT32UC3B0128,
AT32UC3B0256,
AT32UC3B0512,
AT32UC3B164,
AT32UC3B1128,
AT32UC3B1256,
AT32UC3B1512,
AT32UC3B064ES,
AT32UC3B01128ES,
AT32UC3B0256ES,
AT32UC3B0512ES,
AT32UC3B164ES,
AT32UC3B1128ES,
AT32UC3B1256ES,
AT32UC3B1512ES,
AT32UC3C064,
AT32UC3C0256C,
AT32UC3C0512C,
AT32UC3C164C,
AT32UC3C1256C,
AT32UC3C1512C,
AT32UC3C264C,
AT32UC3C2256C,
AT32UC3C2512C,
AT32UC3C0512REVC,
AT32UC3C1512REVC,
AT32UC3L016,
AT32UC3L032,
AT32UC3L064

In the Makefile I see these after I do a fpcmake -Tall. I looked all over the project and cannot find where I would put the information so fpcmake would generate a Makefile with : ifeq
($(FULL_TARGET),avr32-embedded)

Makefile:ifeq ($(FULL_TARGET),i386-embedded)
Makefile:ifeq ($(FULL_TARGET),m68k-embedded)
Makefile:ifeq ($(FULL_TARGET),powerpc-embedded)
Makefile:ifeq ($(FULL_TARGET),sparc-embedded)
Makefile:ifeq ($(FULL_TARGET),x86_64-embedded)
Makefile:ifeq ($(FULL_TARGET),arm-embedded)
Makefile:ifeq ($(FULL_TARGET),powerpc64-embedded)
Makefile:ifeq ($(FULL_TARGET),avr-embedded)
Makefile:ifeq ($(FULL_TARGET),armeb-embedded)
Makefile:ifeq ($(FULL_TARGET),i386-embedded)
Makefile:ifeq ($(FULL_TARGET),m68k-embedded)
Makefile:ifeq ($(FULL_TARGET),powerpc-embedded)
Makefile:ifeq ($(FULL_TARGET),sparc-embedded)
Makefile:ifeq ($(FULL_TARGET),x86_64-embedded)
Makefile:ifeq ($(FULL_TARGET),arm-embedded)
Makefile:ifeq ($(FULL_TARGET),powerpc64-embedded)
Makefile:ifeq ($(FULL_TARGET),avr-embedded)
Makefile:ifeq ($(FULL_TARGET),armeb-embedded)

Can anyone explain where I can find information on what is needed to do the port? On the embedded site there is almost nothing. I know about the units and compiler directory but there is a lot of important information missing. It looks like the information has been written for someone who has allready done several ports. Part of that would be where I would get the information on the file where I put the assembler information so FPC can generate the correct assembler?

Thank you very much

Michel Catudal

Henry Vermaak wrote

it's really expensive to trap the illegal instructions and emulate them.

AFAIK, the trapping is done by the ARM CPU, anyway, providing the emulation functions just costs some memory, but of course it's even slower and more intrusive than directly calling an FPU emulation function in user space.

-Michael

No, the cpu generates an exception for every illegal fpu operation, which gets trapped by the kernel. The kernel then has to catch this instruction and perform it by emulating the _whole_ fpu. This, together with the exception handling causes the bad performance. Look at the code in arch/arm/nwfpe if you're interested.

Henry

Henry Vermaak wrote

How did it crash?  Your crashes may be due to the fact that fpc passes floats incorrectly in function calls, too.

I just rechecked, and for FPC-based apps, it simply refuses installing:

W/PackageManager( 89): Native ABI mismatch from package file

Henry Vermaak wrote

...

This is exactly what I wanted to say, as well. The trap itself is done by the hardware, the handling of same (if the user land software in fact does FPU instructions) is very slow and intrusive. -Michael

three years ago, I compared an OABI kernel with double precision Netwinder FPE emulation against softfloat and the softfloat variant was about 2 until 10 times faster, depending on the floating point instructions.

The trapping is done in hardware but it still takes a lot of time, it's a context switch after all.

Extend fpc\utils\fpcm\fpcmmain for avr32 so fpcmake -Tall will cover avr32-embedded as well.

Can anyone explain where I can find information on what is needed to do the port?

First, you need a compiler generating avr32 code.

On the embedded site there is almost nothing.

It's only about the embedded rtl, not about the porting the compiler.

Look at fpc/compiler/arm to see what the arm port needs. Then you need to create similiar files for avr32.

Thank you, that works.

I got that. I saw that the ARM code uses a converting program that I think would generate opcodes.
I could do something similar once I figure out the syntax for the opcodes in the dat file
My question was more or less, where do I put the opcodes and what program does the generation of assembler.

Michel

This file is only used by an internal assembler but has nothing to do with the assembler code generation. An internal assembler is something optional.

My question was more or less, where do I put the opcodes and what program does the generation of assembler.