Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2012-03

Patch: Add support for armhf

5 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

peter green

I attatch a patch which adds support for armhf to freepascal.

Armhf reffers to arm with the VFP hardfloat variant of EABI. The defaults are setup to
be suitable for debian armhf (armv7 vfpv3_d16).

The changes in the patch are documented below.

rtl/arm/setjump.inc, rtl/arm/math.inc, rtl/arm/mathu.inc rtl/arm/arm.inc, rtl/arm/setjumph.inc. compiler/arm/narminl.pas, compiler/arm/cgcpu.pas, compiler/arm/narmcnv.pas, compiler/arm/narmcal.pas, compiler/arm/narmmat.pas,
compiler/arm/cpuinfo.pas, compiler/arm/narmadd.pas, compiler/arm/cpupara.pas:

Add support for the vfpv3_d16 variant of vfp. Currently I Don't think freepascal
actually uses any vfp version specific instructions so the code generated probablly
won't be any different from when vfpv2 is selected. Still I think we should recognise
this FPU version as it's what debian uses and we want to pass the correct FPU
option to the assembler for inline asm users.

While writing this part of the patch I came to wonder if we should introduce a FPUVFP
define that is defined when any variant of VFP is selected. It would simplify a lot of
conditionals in the RTL and would make it a lot less work to add a new VFP variant
in future.

compiler/ninl.pas:

Fix an internal error number that was used twice in two different places.

compiler/systems.inc compiler/systems.pas

Add new abi target "EABIHF"

compiler/fpcdefs.inc, compiler/systems/i_linux.pas, compiler/pp.pas, compiler/systems/t_linux.pas:

add and document FPC_ARMHF define to create an armhf compiler.

compiler/ncgutil.pas, compiler/arm/narmcal.pas:

check that the parameter/result is actually in an integer register before taking special
codepath to handle that case

compiler/arm/armreg.dat compiler/arm/rarmnum.inc, compiler/arm/rarmsup.inc, compiler/arm/rarmrni.inc, compiler/arm/rarmstd.inc, compiler/arm/rarmsri.inc,
compiler/arm/rarmcon.inc:

Give odd numbered single registers their own numbers so we can use them as locations
for parameters.

Fix a typo in the stdname for S30

compiler/arm/cpubase.pas:

Raise the minimum imaginary multimeter number to make room for the aformentioned odd
numbered single registers.

Mark appropriate odd numbered single registers as volatile.

compiler/arm/agarmgas.pas:

Tell the assembler that we are using VFP and what version we are using.

Pass some armhf specific options (copied from what gcc does) when we are building
for the eabihf abi target.

compiler/arm/cpupara.pas:

Actually implement the new ABI

compiler/options.pas:

Define FPC_ABI_EABI in addition to FPC_ABI_EABIHF on EABI VFP hardfloat systems since
most code needs to behave the same on both

Set default CPU and FPU types to appropriate values when the EABIHF abi target is selected.

Error out if the user tries to select EABIHF target with a non vfp FPU.

compiler/msg/errore.msg, compiler/msgtxt.inc, compiler/msgidx.inc:

Add new message for error mentioned in previous section and run make messages (note: make messages seems to have added a lot of noise in the patch)

Please review this patch and consider it for inclusion.

Reply by email

Jonas Maebe
to peter green
peter green wrote
I attatch a patch which adds support for armhf to freepascal.

Thanks!

Armhf reffers to arm with the VFP hardfloat variant of EABI. The defaults are setup to be suitable for debian armhf (armv7 vfpv3_d16).

Are they Debian-specific? Adding distribution-specific settings to the compiler is something that should be very much avoided.

Some other remarks:
* please split unrelated parts into separate patches (such as making the internalerror in ninl.pas unique)
* please create bug reports for those individual patches and attach them there, it makes them easier to track than on a mailing list
* some stylistic remarks (there may be more, I just quickly glanced over the patch):

+ if ((target_info.abi=abi_eabi) or (target_info.abi=abi_eabihf)) and

-> change into an in-statement (and as mentioned before, please do not put multiple if-conditions on the same line except if they are really short like two boolean variables)

+  if target_info.abi = abi_eabihf then
def_system_macro('FPC_ABI_EABI');

-> Put the then-part on a separate line

+ end else begin

-> this should be

   end
else
   begin

Jonas

Reply by email

peter green
to Jonas Maebe
Jonas Maebe wrote 6 lines
On 20 Mar 2012, at 23:43, peter green wrote: > I attatch a patch which adds support for armhf to freepascal. Thanks!

Unfortunately just after I sent the mail what I thought was a minor problem in the build system turned out to be more serious than I thought, namely cthreads is crashing at initalisation time. I really need to figure out why before merging this patch is considered.

I'll keep you posted on my progress and i'll try and split things up and file bug reports soon.

Reply by email

peter green
to peter green
Unfortunately just after I sent the mail what I thought was a minor problem in the build system turned out to be more serious than I thought, namely cthreads is crashing at initalisation time. I really need to figure out why before merging this patch is considered.

Ok solved that issue, it seems if the compiler can find crti.o but not crtn.o it links cthreads using apps successfully but they crash on startup :(, if it can find both crti.o and crtn.o cthreads works ok :).

Reply by email

peter green
to Jonas Maebe: Thanks! Are they Debian-specific? Adding distribution-specific settings to the compiler…
Jonas Maebe wrote 13 lines
On 20 Mar 2012, at 23:43, peter green wrote: > I attatch a patch which adds support for armhf to freepascal. Thanks! > Armhf reffers to arm with the VFP hardfloat variant of EABI. The > defaults are setup to > be suitable for debian armhf (armv7 vfpv3_d16). Are they Debian-specific? Adding distribution-specific settings to the compiler is something that should be very much avoided.

One has to chose some set of defaults, the ones i've picked match what debian/ubuntu are doing. If you want to reduce them to armv6 and vfpv2 that's fine by me too. I don't think any lower is sane (the lowst VFP variant that freepascal supports is VFPV2 and afaict VFPV2 came in with armv6).

Some other remarks: * please split unrelated parts into separate patches (such as making the internalerror in ninl.pas unique)

I split out the internal error change, most if not all of the other stuff in the patch is at least somewhat related to each other.

If you want me to split out other stuff please tell me where you would like the lines drawing (for example if you want the VFPV3_D16 in a seperate patch please tell me, it may be a bit of a pain to split it though as in at least one place it is in the same chunk as another armhf related change)

* please create bug reports for those individual patches and attach them there, it makes them easier to track than on a mailing list

I've filed bug reports for the main patch and the internalerror patch. If you want things splitting further please tell me and i'll do so and file more bugreports.

http://bugs.freepascal.org/view.php?id=21545
http://bugs.freepascal.org/view.php?id=21554

Show quoted text 8 lines
* some stylistic remarks (there may be more, I just quickly glanced over the patch): + if ((target_info.abi=abi_eabi) or (target_info.abi=abi_eabihf)) and -> change into an in-statement (and as mentioned before, please do not put multiple if-conditions on the same line except if they are really short like two boolean variables)

Done

+ if target_info.abi = abi_eabihf then def_system_macro('FPC_ABI_EABI'); -> Put the then-part on a separate line

Done

Show quoted text 9 lines
+ end else begin -> this should be end else begin

Done

Reply by email