[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

[peter green]

>
> 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.