[fpc-devel] about freepascal for mips

[Fuxin Zhang]

> [snip]
>> This is to fix various file not found errors. I am not sure whether it
>> is
>> 'right' fix.
>
> No, definitely it's definitely not right. It's strange that you need
> those changes, since the Linux RTL Makefile is used daily. Did you
> need those changes even to compile it for i386?
>
No, It is only needed for mipsel.
Without this,
/home/foxsen/fpc/compiler/ppcrossmipsel -Pmipsel -XPmipsel-linux- -Xr
-Fi../inc -Fi../mipsel -Fi../unix -Fimipsel -FE.
-FU../../rtl/units/mipsel-linux -g -Xs-  -dmipsel  ../objpas/math.pp
....
unix.pp(498,15) Warning: Symbol "SelectText" is deprecated
unix.pp(1070,32) Warning: Symbol "Domain" is not portable
Assembling unix
sysutils.pp(41,2) Fatal: Can't open include file "sysutilh.inc"
Fatal: Compilation aborted
make[3]: *** [math.ppu] 错误 1
make[3]:正在离开目录 `/home/foxsen/fpc/rtl/linux'
make[2]: *** [linux_all] 错误 2
make[2]:正在离开目录 `/home/foxsen/fpc/rtl'
make[1]: *** [rtl] 错误 2
make[1]:正在离开目录 `/home/foxsen/fpc/compiler'
make: *** [cycle] 错误 2

sysutilh.inc is in rtl/objpas/sysutils, the cross compiler cannot find it
out with the default command line. While for i386 version, when compiling
math.pp, needed ppu is already there, compiler won't goto compile
system.pp/sysutils.pp etc. thus no error. So it should be a real bug. But
where to add the necessary paths can be discussed.

>> commands:
>>   cd rtl/linux;
>>   patch Makefile.fpc; fpcmake -Ti386-linux,mipsel-linux
>
> It's better to use -Tall (since there are more Linux targets than just
> i386 and mipsel).
Yes, I just wanted to make the Makefile short to easy finding something:)
Now I am familiar enough to deal with -Tall:)

>>
>> I know it is related to mips branch offset overflow.
>
> A similar issue exists on PowerPC: conditional branches are limited to
> 16 bit offsets, while unconditional branches can reach up to 26 bits
> or so. As far as I can see, it's similar on MIPS (the B* opcodes
> versus the J opcode). If so, you may be able to create a MIPS version
> of the fixup_jmps procedure in compiler/ppcgen/aasmcpu.pas and add it
> to compiler/mips/aasmcpu.pas (it's called from psub.pas, you'll have
> to modify the ifdef there to also activate it for MIPS and MIPSEL).
Thanks. I've noticed the fixup_jmps. But it seems to deal with branch
offset overlow INSIDE a procedure? Chances of this is very few.
>
> The actual errors you get are strange though. We never insert
> conditional branches from one routine to another (in the above case:
> from SYSUTILS_$$_finalize, or more likely from interface wrappers
> following that symbol, to various other routines). Looking at the code
> for tcgcpu.g_intf_wrapper in compiler/mips/cgcpu.pas, the code for
> interface wrappers uses the "B" as opposed to the "J" instruction to
> branch to the interface wrappers. Maybe that's a copy/paste error from
> another platform. I'm not sure what "B" means though, I don't see it
> listed at http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html
B refers to various branch instructions which are limited to 16 bit
offset. There is mips instruction call 'B', only branches like bne/beq.
>
> Anyway, I guess this patch will solve the above error:
Yes, you're right! Now I've got a native version of fpc mipsel.
Thank you so much.

Now at least we have a very good start. I've a quick look over current
mips code, it seems not strong enough. For example, the inverse_cond seems
wrong, the setting of first_int_imreg/mavarregs/maxfpuvarregs etc. is hard
to understand...
I'll read more and come back later.
>
> Index: compiler/mips/cgcpu.pas
> ===================================================================
> --- compiler/mips/cgcpu.pas	(revision 21359)
> +++ compiler/mips/cgcpu.pas	(working copy)
> @@ -1722,7 +1722,7 @@
>       op_onr24methodaddr;
>     end
>     else
> -
> list.concat(taicpu.op_sym(A_B,current_asmdata.RefAsmSymbol(procdef.mangledname)));
> +
> list.concat(taicpu.op_sym(A_J,current_asmdata.RefAsmSymbol(procdef.mangledname)));
>     { Delay slot }
>     list.Concat(TAiCpu.Op_none(A_NOP));
>
>> After some
>> research,I've found that ppc code support -fPIC.
>
> PIC normally won't help with branch offset overflows.
>
>> But when I try to enable
>> it,the other issue appears:
>
> Yes, PIC requires cpu-specific support. It shouldn't be necessary to
> get an initial port up and running though.
>
>
> Jonas
>