[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Florian Klämpfl
florian at freepascal.org
Sun Mar 11 21:02:56 CET 2012
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_S0<>NR_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.
More information about the fpc-devel
mailing list