[fpc-devel] "embedded" again

[Thomas Schatzl]

Hi,

On Mon, 2013-01-21 at 15:42 +0100, Michael Schnell wrote:
> On 01/21/2013 03:32 PM, Marco van de Voort wrote:
> > I do not understand. There is no such thing as an universal arm package. So
> > there is no "the" lazarus debian package for arm.
> Of course you are right, but to the user it looks like. I suppose 
> apt-get and friends is installed with the distribution that of course 
> does know the system is it meant to run on.
> 
> Now the user just does "apt-get install fpc" or similar and after that 
> fpc should be usable.
> 
> So the apt-get installation seems to select the correct package for the 
> flavor.
> 
> What I meant is: the fpc package(es) seem to be provided by the fpc 
> team. To they provide multiple of them (I only found a single one) here:
> 
> http://packages.debian.org/squeeze/armel/fp-compiler/download -> 
> http://ftp.de.debian.org/debian/pool/main/f/fpc/fp-compiler_2.4.0-2_armel.deb 
>
> so I supposed it would contain the necessary stuff for all supported 
> flavors. But maybe I did not look hard enough.

Armel means armv5te softfp for fpc as the name of the package indicates.
On newer processors you might use vfpv2, but this requires recompilation
of the rtl. Only fpc trunk supports armhf. Any precompiled package on
the internet is likely to be armel/softfp.


There is a separate package for arm-linux-armhf on the ftp at the moment
(ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armhf vs.
ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armel).

Note that if you use default installation paths, one will overwrite
files from the other.

Short story: make sure to install and use the correct compiler.

Long story: The armel/armhf distinction is made by linux user space. The
kernel is oblivious to that, i.e. armel statically linked binaries run
on armhf user space too.

You can use an *armel fpc* trunk compiler on armhf systems to generate
*armhf* binaries *if* you make sure that the correct ppu's are used. And
you pass the correct options to generate armhf code.
You can bootstrap an armhf compiler with the armel compiler.

There may be issues with the kernel regarding emulation of some obsolete
instructions though. armhf mandates armv7 processors, but for fpc, armel
is compiled for the armv5te processors with softfp support.
This means that an armel binary compiled with fpc will e.g. use the
obsolete "swp" instruction that is emulated by the kernel. However if
you don't compile the kernel with emulation for the swp instruction
turned on, any (fpc) executable that uses it will crash.

Additionally, what may confuse the situation further, at least on debian
you can install both armel and armhf libraries side-by-side in a
multiarch (like x86/amd64 on intel) configuration. I do not know how
other distros handle this. I assume most of them only support armhf - so
when compiling for them on them, the armhf trunk compiler may be
preferable.

I do not know what is used/installed on raspbian - since it is debian it
will likely use the multiarch solution and its binaries are armel.

Another side note: armel and armhf indicate how floating point values
are passed. Armel means that all floating point values are passed in
integer registers always, armhf means that fp values are generally
passed in floating point registers. The softfp/vfpv2 distinction for
armel  indicates how the fp operations are performed. Softfp means that
all fp  operations are performed by software, vfpv2 means that fp
operations are performed by the hardware. Although fp values are still
passed in integer registers, they're copied to fp registers before
performing the operation. From an ABI point of view softfp and vfpv2 are
compatible. However, vfpv2 executables will crash if run on a processor
not having vfpv2 hardware. You're on your own selecting the correct code
path.

There is no 2.6.x armhf compiler. There are no plans to backport these
changes afaik.

Thomas