NR_S0<>NR_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 ca
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?
>>>
>>
>> Ye
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 progr
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
On Sun, Mar 11, 2012 at 04:29, Michael Van Canneyt
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 Lazarus.
--
Alexander S
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
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: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
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
>
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 ge
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
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 co
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 t
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 i
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 erro
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
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.
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
18 matches
Mail list logo
