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
