On Sun, 11 Mar 2012, Martin wrote:
On 08/03/2012 13:34, Martin wrote:
On 08/03/2012 13:08, michael.vancann...@wisa.be wrote:
On Thu, 8 Mar 2012, Martin wrote:
Further more:
the program below, does not crash in delphi (turbo delphi)
I also noticed. I suspect the problem is the owner;
I've made some progress on armhf porting, i've added the nessacery
frameworks (vfpv3_d16 FPU target, EABIVFP ABI target, FPC_ARMHF define)
and made a start on actually implementing the new ABI. I decided to
start with function results.
However i've now reached a problem which has me stumped.
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
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.
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
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
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:
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
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
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
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
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
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
On Sun, Mar 11, 2012 at 04:29, Michael Van Canneyt
mich...@freepascal.org wrote:
We'd like people to try it and comment on the design and speed of the
engine,
and if you have suggestions for improvements, they're more than welcome.
A good use/test would be to speed up Find in Files in
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
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
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
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
18 matches
Mail list logo
