Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 23:23, peter green wrote: Umm, my copy of narmcon.pas contains the following. NR_S0 = tregister($0406); NR_S1 = tregister($0406); NR_D0 = tregister($0407); I can see how the compiler can tell whether i'm assigning S0 or D0 but I don't see how it can tell whether I am assigning S0 or S1 when the constants I would use to make the assignment are defined to have the exact same value. You can give S1, S3, S5 etc different super register numbers ( $1F, so they don't conflict with the super register numbers for D0..D31). As long as you don't change the code in tarmcgarm/ Tthumb2cgarm.init_register_allocators() to explicitly tell the register allocator that it can use these extra registers, it will won't try to allocate them. Make sure to adjust first_mm_imreg in arm/ cpubase.pas afterwards (add $10 to it, since the numbers $20..$3F will now be used by S1, S3 etc). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Jonas Maebe wrote: You can give S1, S3, S5 etc different super register numbers ( $1F, so they don't conflict with the super register numbers for D0..D31). As long as you don't change the code in tarmcgarm/Tthumb2cgarm.init_register_allocators() to explicitly tell the register allocator that it can use these extra registers, it will won't try to allocate them. So I change S1,$04,$06,$00,s1,0,0 to S1,$04,$06,$20,s1,0,0 and so-on in compiler/arm/armreg.dat right? After doing that do I need to do anything to update the generated files or will they be updated automatically? Make sure to adjust first_mm_imreg in arm/cpubase.pas afterwards (add $10 to it, since the numbers $20..$3F will now be used by S1, S3 etc). Ok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 12:01, schrieb peter green: It appears to me (i'm not an expert on arm assembler and I can't seem to find any documentation on FPA) that FPC is generating FPA instructions even though the FPU is set to a VFP type. What i'm really struggling to work out is why the heck that is happening. From telling freepascal to include source lines as comments in the assembler it doesn't look like inline assembler is responsible. Can you please post the full assembler listing of a procedure containing such code? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 12:01, peter green wrote: When I try to build my patched compiler (using make compiler_cycle 'OPT=-dFPC_ARMHF' ) the starting compiler builds the RTL and compiler successfully (as would be expected) but when ppc1 tries to build the RTL things fail with assembler errors. The errors below are a sample of the types of error seen (there are a HUGE number of each) /fpc/rtl/units/arm-linux/system.s:19075: Error: selected processor does not support ARM mode `mvfd d0,f0' /fpc/rtl/units/arm-linux/system.s:19077: Error: selected processor does not support ARM mode `ldfd f0,[r13]' /fpc/rtl/units/arm-linux/system.s:41169: Error: selected processor does not support ARM mode `ldfs f0,[r13]' It appears to me (i'm not an expert on arm assembler and I can't seem to find any documentation on FPA) that FPC is generating FPA instructions even though the FPU is set to a VFP type. Where is the FPU set to a VFP type? You have to add -Cfvfpv2 or so to OPT to select a VFP FPU. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Florian Klaempfl wrote:
Am 11.03.2012 12:01, schrieb peter green:
It appears to me (i'm not an expert on arm assembler and I can't seem
to find any documentation on FPA) that FPC is generating FPA
instructions even though the FPU is set to a VFP type. What i'm really
struggling to work out is why the heck that is happening. From telling
freepascal to include source lines as comments in the assembler it
doesn't look like inline assembler is responsible.
Can you please post the full assembler listing of a procedure containing
such code?
.section .text.n_system_$$_assign$real48$$double
.balign 4
.globlSYSTEM_$$_assign$REAL48$$DOUBLE
.typeSYSTEM_$$_assign$REAL48$$DOUBLE,#function
SYSTEM_$$_assign$REAL48$$DOUBLE:
# Temps allocated between r13+4 and r13+12
# [346] begin
stmfdr13!,{r14}
subr13,r13,#12
# Var $result located in register d0
# Var b located at r13+0
strr0,[r13]
addr2,r13,#4
movr1,#6
.Lj10088:
ldrbr3,[r0], #1
subsr1,r1,#1
strbr3,[r2], #1
bne.Lj10088
# [347] D:=real2double(b);
addr0,r13,#4
blxSYSTEM_$$_REAL2DOUBLE$REAL48$$DOUBLE
mvfdd0,f0
# Var $result located in register d0
# [348] end;
fstdd0,[r13]
ldfdf0,[r13]
addr13,r13,#12
ldmfdr13!,{r15}
.Le332:
.sizeSYSTEM_$$_assign$REAL48$$DOUBLE, .Le332 -
SYSTEM_$$_assign$REAL48$$DOUBLE
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Where is the FPU set to a VFP type? I set it in code. Defining FPC_ARMHF selects a new version of system_arm_linux_info which sets the ABI to abi_eabivfp. That in turn triggers a block of code that I added to options.pas which sets the default fpu to fpu_vfpv3_d16 and errors out if the user manually specifies a FPU that is not a VFP variant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 13:00, peter green wrote: That in turn triggers a block of code that I added to options.pas which sets the default fpu to fpu_vfpv3_d16 and errors out if the user manually specifies a FPU that is not a VFP variant. Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, continue and see what goes wrong. Some other comments about your patch: * please do not write code like this: if (target_info.abi abi_eabivfp) AND((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Use this instead: if (target_info.abi abi_eabivfp) and ((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then * is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP. * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines. You can always select the appropriate default ABI via the global configuration file. * eabivfp as a name for the ABI is confusing. The existing VFP support also uses the eabi. Something like eabihardfp would be better. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. I'm pretty sure it is getting set because I use it in generating the assembler command line and i'm using an assembler wrapper that tells me what the assembler command line is. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, I'll try but I'm having great trouble understanding how the code generator works. I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. continue and see what goes wrong. Some other comments about your patch: * please do not write code like this: if (target_info.abi abi_eabivfp) AND((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Use this instead: if (target_info.abi abi_eabivfp) and ((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Ok i'll try and remember that. * is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP. I belive it is in principle possible to use the hard float ABI with ARMv6. Not sure if any distro is doing so though. If there are it may make sense to make ARMv6 the default for an armhf compiler. * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines. Currently the only FPC_ARMHF defines are selecting different defaults. You should still be able to select either ABI manually with either compiler binary if you wish. You can always select the appropriate default ABI via the global configuration file. You can but IMO it's neater to have a compiler built to use appropriate defaults for the system it's running on than to mess with generating and updating architecture specific configuration files. * eabivfp as a name for the ABI is confusing. The existing VFP support also uses the eabi. But it doesn't use the vfp variant of eabi. Something like eabihardfp would be better. mmm, I mused a bit over that name. It is at least in principle possible to have EABI variants for FPUs other than vfp. I don't think any currently exist though and if they do I guess one could always select on the FPU type. So maybe eabihf or eabihardfloat is indeed a better choice. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 13:22, schrieb Jonas Maebe: * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. But isn't this caused by the fact that we have the same executable name while it generates different code? I currently think that having even arm/armeb/armel/armhf as cpu types is the way to go. This allows also to have units for all four flavours on one system. Currently we simply don't support the same target cpu but different abi in any way in the build system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 14:55, peter green wrote: Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. I'm pretty sure it is getting set because I use it in generating the assembler command line and i'm using an assembler wrapper that tells me what the assembler command line is. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, I'll try but I'm having great trouble understanding how the code generator works. Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg). Once you figure out from where that routine gets called, then you do need some compiler knowledge: on ARM, the a_*fpu* routines are (should be) only be used in case of FPA. In case of VFP, the a_*mm* routines must be used instead. So there's probably a missing check for the new VFP FPU type you added (which you can easily figure out via a backtrace once the breakpoint is hit). I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. Unless you want to step through the entire compiler or code generator until you find where it goes wrong, that shouldn't matter. You can always select the appropriate default ABI via the global configuration file. You can but IMO it's neater to have a compiler built to use appropriate defaults for the system it's running on than to mess with generating and updating architecture specific configuration files. It's neat until something goes wrong and you have to start figuring out how they compiled the compiler, or the person they downloaded it from. Experience tells us that if the compiler binaries have the same name, they should have the same behaviour. Otherwise support becomes hell (and it becomes equally difficult for users to know what to expect). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 15:14, Florian Klaempfl wrote: Am 11.03.2012 13:22, schrieb Jonas Maebe: * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. But isn't this caused by the fact that we have the same executable name while it generates different code? Yes. I currently think that having even arm/armeb/armel/armhf as cpu types is the way to go. This allows also to have units for all four flavours on one system. Currently we simply don't support the same target cpu but different abi in any way in the build system. We also don't support an RTL compiled with -Cp386, -Cppentium, -Cppentium2, -Cppentium2, -Cppentiumm, -Cfx86, -Cfsse2 and/or -Cfsse3 on the same system. For ARM hard float, you will also need different sets of units depending on the exact kind of VFP cpu you have (unless you always target the lowest common denominator -- if something like that even exists for all VFP variants, since ARM is not that big on backward compatibility and they have their own standard of encoding the entire ABI, target cpu and all other details into attributes inside every generated object file so that the linker can verify the compatibility). Whether it's ABI or minimally required target cpu, the part that causes the trouble is that you need a different set of units. I don't think that renaming the compiler binary just for this particular case is the right approach. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg). Hmm, when I grepped for the first and most prolific problem instruction (mvfd) I didn't find anything useful. Maybe I should have tried some of the other problem intstructions. Once you figure out from where that routine gets called, then you do need some compiler knowledge: on ARM, the a_*fpu* routines are (should be) only be used in case of FPA. In case of VFP, the a_*mm* routines must be used instead. So there's probably a missing check for the new VFP FPU type you added (which you can easily figure out via a backtrace once the breakpoint is hit). Hmm, I think you may have identified my problem. Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. Unless you want to step through the entire compiler or code generator until you find where it goes wrong, that shouldn't matter. Ok It's neat until something goes wrong and you have to start figuring out how they compiled the compiler, or the person they downloaded it from. Experience tells us that if the compiler binaries have the same name, they should have the same behaviour. Otherwise support becomes hell (and it becomes equally difficult for users to know what to expect). Well the arm variants (arm, armeb, armel and my new armhf) DO announce themselves in the target OS line in the output so there is a fairly easy way to tell them apart. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 15:40, peter green wrote: Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg). Hmm, when I grepped for the first and most prolific problem instruction (mvfd) I didn't find anything useful. Maybe I should have tried some of the other problem intstructions. The instruction is MVF. The D is a size suffix (like movl or movb is not an instruction x86, but mov is) Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? Yes. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 15:37, schrieb Jonas Maebe: On 11 Mar 2012, at 15:14, Florian Klaempfl wrote: Am 11.03.2012 13:22, schrieb Jonas Maebe: * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. But isn't this caused by the fact that we have the same executable name while it generates different code? Yes. I currently think that having even arm/armeb/armel/armhf as cpu types is the way to go. This allows also to have units for all four flavours on one system. Currently we simply don't support the same target cpu but different abi in any way in the build system. We also don't support an RTL compiled with -Cp386, -Cppentium, -Cppentium2, -Cppentium2, -Cppentiumm, -Cfx86, -Cfsse2 and/or -Cfsse3 on the same system. True, but they are not different abis, debian does not treat them different either. For ARM hard float, you will also need different sets of units depending on the exact kind of VFP cpu you have (unless you always target the lowest common denominator -- if something like that even exists for all VFP variants, since ARM is not that big on backward compatibility and they have their own standard of encoding the entire ABI, target cpu and all other details into attributes inside every generated object file so that the linker can verify the compatibility). But the abi stays on all hard float platforms the same? Indenpendent of the instruction set. Whether it's ABI or minimally required target cpu, the part that causes the trouble is that you need a different set of units. I don't think that renaming the compiler binary just for this particular case is the right approach. Since the same compiler executable cannot run on the other platforms, I think naming them differently is reasonable. In general, I'd take the debian architecture scheme as measure. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? Yes. Thank you for your help so-far, i'm gradually making progress though there is still some way to go. While i'm currently working on doubles (since double is the dominant floating point type in my experiance and is also easier) at some point I will need to support singles correctly as well and I just ran into an issue that could pose a problem for making singles work correctly. It seems freepascal identifies registers using a series of constants defined in rarmcon.inc which is generated from armreg.dat however to workarround a deficiency in the register allocator the same register number was allocated to both of the single precision registers that overlap with any given double precision register. So it seems there is no way to identify the two seperately within the compiler. This is a problem because to correctly implement the EABI VFP calling convention I need to use those registers. Any thoughts on how to get arround this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 18:28, schrieb peter green: Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? Yes. Thank you for your help so-far, i'm gradually making progress though there is still some way to go. While i'm currently working on doubles (since double is the dominant floating point type in my experiance and is also easier) at some point I will need to support singles correctly as well and I just ran into an issue that could pose a problem for making singles work correctly. It seems freepascal identifies registers using a series of constants defined in rarmcon.inc which is generated from armreg.dat however to workarround a deficiency in the register allocator the same register number was allocated to both of the single precision registers that overlap with any given double precision register. So it seems there is no way to identify the two seperately within the compiler. This is a problem because to correctly implement the EABI VFP calling convention I need to use those registers. NR_S0NR_D0: they can be identified by the sub type. Further, one can perfectly assign NR_S1 to any location explicitly. Only the register allocator cannot use the odd single registers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
NR_S0NR_D0: they can be identified by the sub type. Further, one can perfectly assign NR_S1 to any location explicitly. Umm, my copy of narmcon.pas contains the following. NR_S0 = tregister($0406); NR_S1 = tregister($0406); NR_D0 = tregister($0407); I can see how the compiler can tell whether i'm assigning S0 or D0 but I don't see how it can tell whether I am assigning S0 or S1 when the constants I would use to make the assignment are defined to have the exact same value. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
