Hello everybody,

I am Fuxin Zhang from lemote, now we are working on mips support of fpc. Hope you guys can help us to accelerate the process, a lots of users are waiting for this(see at the end of copied mail between me and Florian if interested).
Lemote can donate developer machines to who want to help.

And my progress and problems:
I've got the source from subversion and tried to build it in ubuntu 11.10 x86-64 machine. With the following patch and commands, I can get a partly working ppcrossmipsel(it can at least build a helloworld and runnable):
patch:
Index: Makefile.fpc
=================================================================== --- Makefile.fpc (版本 21354)
+++ Makefile.fpc (工作副本)
@@ -35,8 +35,8 @@
target=linux

[compiler]
-includedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH)
-sourcedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH) $(COMMON) +includedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH) ../objpas ../objpas/sysutils +sourcedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH) $(COMMON) targetdir=.

[shared]
@@ -89,6 +89,7 @@

# Paths
OBJPASDIR=$(RTL)/objpas
+UNITDIR=../unix:../objpas:../inc

[rules]
.NOTPARALLEL:

This is to fix various file not found errors. I am not sure whether it is 'right' fix.

commands:

  cd rtl/linux;
  patch Makefile.fpc; fpcmake -Ti386-linux,mipsel-linux
  make cycle CPU_TARGET=mipsel

But when I tried to build native mipsel ppc, I met some issues that seem not easy to fix:

  cpugas.pas(271,7) Note: Local variable "as_MIPS_as_info" not used

Assembling cpugas
Compiling dbgstabs.pas
Assembling dbgstabs
Assembling cputarg
Assembling compiler
Assembling pp
Linking ./pp
/opt/mips-4.4.6/bin/mipsel-linux-ld: warning: ./link.res contains output sections; did you forget -T?
/home/foxsen/fpc/rtl/units/mipsel-linux/sysutils.o: In function `SYSUTILS_$$_finalize':
/home/foxsen/fpc/rtl/unix/sysutils.pp:1414: relocation truncated to fit: R_MIPS_PC16 against
`SYSTEM$_$TINTERFACEDOBJECT_$__$$_QUERYINTERFACE$TGUID$formal$$LONGINT' /home/foxsen/fpc/rtl/unix/sysutils.pp:1414: relocation truncated to fit: R_MIPS_PC16 against `SYSTEM$_$TINTERFACEDOBJECT_$__$$__ADDREF$$LONGINT' /home/foxsen/fpc/rtl/unix/sysutils.pp:1414: relocation truncated to fit: R_MIPS_PC16 against `SYSTEM$_$TINTERFACEDOBJECT_$__$$__RELEASE$$LONGINT' pp.pas(224,36) Error: Error while linking
pp.pas(224,36) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
make[1]: *** [ppcmipsel] 错误 1
make[1]:正在离开目录 `/home/foxsen/fpc/compiler' make: *** [cycle] 错误 2

I know it is related to mips branch offset overflow. After some research,I've found that ppc code support -fPIC. But when I try to enable it,the other issue appears:
make[3]: 正在进入目录 `/home/foxsen/fpc/rtl/linux' mipsel-linux-as -EL -o ../../rtl/units/mipsel-linux/prt0.o mipsel/prt0.as mipsel-linux-as -EL -o ../../rtl/units/mipsel-linux/dllprt0.o mipsel/dllprt0.as
mipsel-linux-as -EL -o ../../rtl/units/mipsel-linux/cprt0.o mipsel/cprt0.as mipsel-linux-as -EL -o ../../rtl/units/mipsel-linux/gprt0.o mipsel/gprt0.as /home/foxsen/fpc/compiler/ppcrossmipsel -Pmipsel -XPmipsel-linux- -Xr -Fu../unix:../objpas:../inc -Fi../inc -Fi../mipsel -Fi../unix -Fimipsel -Fi../objpas -Fi../objpas/sysutils -FE. -FU../../rtl/units/mipsel-linux -g -Xs- -fPIC -dmipsel -Us -Sg system.pp
Free Pascal Compiler version 2.7.1 [2012/05/23] for mipsel Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for MIPSEL
Compiling system.pp
syscall.inc(42,9) Fatal: Internal error 200502052
Fatal: Compilation aborted
make[3]: *** [system.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

gdb debug trace of this:

Breakpoint 3, TCGMIPS__MAKE_SIMPLE_REF (LIST=0xf7ff0360, REF=..., this=<error reading variable>) at ./mips/cgcpu.pas:318 318 if not (pi_needs_got in current_procinfo.flags) then (gdb) where
#0 TCGMIPS__MAKE_SIMPLE_REF (LIST=0xf7ff0360, REF=..., this=<error reading variable>) at ./mips/cgcpu.pas:318
#1 0x0817364f in TCGMIPS__HANDLE_LOAD_STORE (LIST=0xf7ff0360, ISSTORE=false, OP=A_LW, REG=17039392, REF=..., this=<error reading variable>)
at ./mips/cgcpu.pas:469
#2 0x081744cb in TCGMIPS__A_LOAD_REF_REG (LIST=0xf7ff0360, FROMSIZE=OS_32, TOSIZE=OS_32, REF=..., REG=17039392, this=<error reading variable>) at ./mips/cgcpu.pas:772 #3 0x08209613 in TCGLOADNODE__PASS_GENERATE_CODE (this=<error reading variable>) at ncgld.pas:368
#4 0x0815a890 in SECONDPASS (P=0xf7f55220) at pass_2.pas:197 #5 0x0820a2a9 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=<error reading variable>) at ncgld.pas:604
#6 0x0815a890 in SECONDPASS (P=0xf7f79000) at pass_2.pas:197 #7 0x08208246 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=<error reading variable>) at ncgbas.pas:366
#8 0x0815a890 in SECONDPASS (P=0xf7f78f20) at pass_2.pas:197 #9 0x08208246 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=<error reading variable>) at ncgbas.pas:366
#10 0x0815a890 in SECONDPASS (P=0xf7f79540) at pass_2.pas:197 #11 0x0815a96d in DO_SECONDPASS (P=0xf7f79540) at pass_2.pas:229 #12 0x0817ae4a in TCGPROCINFO__GENERATE_CODE (this=<error reading variable>) at psub.pas:1236
#13 0x0817a59f in TCGPROCINFO__GENERATE_CODE_TREE (this=<error reading variable>) at psub.pas:974
#14 0x0817c11b in READ_PROC_BODY (OLD_CURRENT_PROCINFO=0xf7ca11f0, PD=0xf7c902c0) at psub.pas:1787
#15 0x0817c5bf in READ_PROC (ISCLASSMETHOD=false, USEFWPD=0x0) at psub.pas:1923
#16 0x0817ca41 in READ_DECLARATIONS (ISLIBRARY=false) at psub.pas:2047 #17 0x08178902 in BLOCK (ISLIBRARY=false) at psub.pas:275 #18 0x0817bb59 in TCGPROCINFO__PARSE_BODY (this=<error reading variable>) at psub.pas:1615
#19 0x081d4f5c in PROC_UNIT () at pmodules.pas:960 #20 0x081bcf63 in COMPILE (FILENAME=...) at parser.pas:395 #21 0x0806e878 in COMPILE (CMD=0x0) at compiler.pas:255 #22 0x080482a1 in main () at pp.pas:235

It seems that the PIC support for mipsel is somehow broken,to fix this I have to learn more about the ppc logic. Could you please fix it or give me some hints? I have some experiences on general compiler materials and quite familiar with low level things like as/ld etc.

To fix the linking issue, I've also tried to use -xgot option of as which can make use of an 32 bit got table, but it doesn't work. I think probably it works only with -fPIC.

Best Regards

"Fuxin Zhang" wrote

Hello everybody, I am Fuxin Zhang from lemote, now we are working on mips support of fpc

Hello and may I say

EXCELLENT!

Now all we need to know is where to get a good price on your MIPS boxes so we can all run them ;-)

Fuxin Zhang wrote on Fri, 25 May 2012:

[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?

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

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

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

Anyway, I guess this patch will solve the above error:

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

Welcome to the list, it's nice to have you in here. I've still got a (non-MIPS) development system set up with this, so I'll at least try to build the current version.

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.

Yes, I just wanted to make the Makefile short to easy finding something:) Now I am familiar enough to deal with -Tall:)

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.

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.

There is mips instruction call 'B', only branches like bne/beq.

Sorry I meant to say "There is no mips instruction call 'B'":(

I wonder how you people managed to build I tried to build from SVN trunk there would be an endless steam of internalerrors related to fpu registers, no matter if compiled with MIPS FPU or softfloat.

I managed to remove the errors with the following patch, such that everything compiled, but I haven't been able to test it: http://j-software.dk/fpc-mipsel.patch

Does anyone know if there's an easy way to set up an emulator for testing? Been fighting with qemu for the last half hour without results.

Regards,
Jeppe

Jeppe Græsdal Johansen wrote

Does anyone know if there's an easy way to set up an emulator for testing? Been fighting with qemu for the last half hour without results.

http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators

An important point is that in most cases, whoever "rolls" a distro for a guest system will assume that the user is running directly on the host, i.e. that the guest's console can open in an xterm. At least until you know what's going on, if you do have to access the host system over a network (i.e. rather than having a directly-connected screen and keyboard) start off with a graphical login using e.g. VNC.

Hi,
25.05.2012 23:04, Jeppe Græsdal Johansen:
[...]

If you wish, I can create an account for you on my debian MIPS box (which was configured for Florian and other developers and is accessible via ssh almost 24/7) There is enough disk space for all anyway.

Also, I have debain MIPSEL box essentially ready. Developers have not requested it yet, so it is not running at the moment, but I can make it accessible very quickly if necessary.

Nikolai

The reason is that mipsel uses the mips include files by includes. So when compiling other units, the compiler finds include files with wrong dates. The easiest solution to overcome this for now is to compile with -Ur

Which mips toolchain are you using? Here I don't meet any such problem. Mine is from mips
website:http://developer.mips.com/tools/compilers/open-source-toolchain-linux/ mipsel-linux-gcc -v
Using built-in specs.
Target: mips-linux-gnu
Configured with: /tmp/xxx/dev/gcc44/gcc/configure --target=mips-linux-gnu --prefix=/tmp/xxx/dev/gcc44/build-linux-20110223/tools --with-sysroot=/tmp/xxx/dev/gcc44/build-linux-20110223/sysroot --enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ --with-mpfr=/tmp/xxx/newbin --with-gmp=/tmp/xxx/newbin --with-llsc --disable-decimal-float --disable-fixed-point --with-mips-plt --with-arch=mips32r2 Thread model: posix
gcc version 4.4.6 20110223 (prerelease) [gcc-4_4-branch revision 170444] (GCC)

What issues you have met?

Well, we decide to sell some machines at very low price to help promote the mips world. How about Yeeloong netbooks with $100-$150(for various configurations and amounts + shipment）?

You can contact to buy. And I've declared that we can donate some for developers.

Best Regards

When I tried to follow the instructions in given link, I met a problem: formatting of the file system took ages. Finally I give up and instead go to my Yeeloong and install a fresh new squeez system. The installed root file system is shared here:
http://www.kuaipan.com.cn/file/id_46718218999435672.htm (~150MB) You can download it, generate a virtual disk by yourself and then copy the content to get a working qemu image. Details:
1, use raw disk image format in order to operate it without qemu dd if=/dev/zero of=imgfilename bs=4096 count=xxx(size/4096) 2, losetup /dev/loop0 imgfilename
3, fdisk /dev/loop0, make at least one ext3 partition 4, losetup -d /dev/loop0
5, losetup -o offset_of_the_partition /dev/loop0 imgfilename 6, mkfs.ext3 /dev/loop0
7, mount /dev/loop0 /mnt
8, cp -a (extracted root file system contents) /mnt 9, umount /mnt
10, boot qemu with:
qemu-system-mipsel -m 256 -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda mipsel_hda.img --nographic --append "root=/dev/sda1" 11, done
the root password is 'fpc'. offset_of_the_partition can be calculated with fdisk info:
fdisk -l /dev/loop0
Disk /dev/loop0: 17.2 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders, total 33554432 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00066a04

Device Boot Start End Blocks Id System /dev/loop0p1 2048 31459210 15728581+ 83 Linux /dev/loop0p2 31459211 33554303 1047546+ 82 Linux swap / Solaris

offset = start_sector * sector size = 2048 * 512 = 1048576

if you're not confident to do the above, you can download my ready make image from:
http://www.lemote.com/upfiles/mipsel-qemu-img.tar.gz (~600MB, kernel/initrd/image/run_mips script)

Hi, I was more interested in the single box version. I forget what you call it. I will email Betty, thanks for the connection. I'm looking for a MIPS box for my own study.

You can contact to buy. And I've declared that we can donate some for developers.

If I could help I would be glad to, but unfortunately I am not an fpc developer. So I can't ask for a donation. I can ask for a good price though ;-)

Thanks and good luck with fpc. Seems like a great group of guys to me.

Fuxin Zhang wrote

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

first_int_imreg looks correct. It has to be set to the number of integer registers, and since MIPS presumably has 32 integer registers, $20 (= 32 in hex) is ok.

maxvarregs/maxfpuvarregs is from the old register variables code and is no longer used. That code still has to be largely removed, and possibly partially updated and reintegrated in the current compiler.

Directly starting with compiling a native compiler binary and debugging it, is however probably not the easiest approach. It's better to start with cross-compiling tests and debugging those if they fail. To execute all tests, after you've done the "make cycle CPU_TARGET=mipsel", go into fpc/tests, and execute a command like this (make sure to first create the TEST_REMOTEPATH directory on the remote system):

make TEST_FPC=/full/path/to/ppcrossmipsel TEST_REMOTEPATH=/tmp/tests OPT="-O2 -ap" TEST_OPT="-O2 -ap" QUICKTEST=1 clean all digest

Add any additional parameters you need for cross-compilation (-FD, -XR, ...) to TEST_OPT. The QUICKTEST=1 means that tests that depend on units under fpc/packages won't be checked (there's not that many of them anyway).

At the end, the list of failing tests will be in output/mipself-linux/faillist, and in the longlog file in that same directory you'll find the complete compilation/execution logs of the failed tests. When starting to fix things, it's best to first focus on tests from test/cg and test/units/system (apart from the tres* tests, which are for Windows-style resource support), and then everything else under "test".

Jonas

Jonas Maebe wrote

make TEST_FPC=/full/path/to/ppcrossmipsel TEST_REMOTEPATH=/tmp/tests OPT="-O2 -ap" TEST_OPT="-O2 -ap" QUICKTEST=1 clean all digest Add any additional parameters you need for cross-compilation (-FD, -XR, ...) to TEST_OPT. The QUICKTEST=1 means that tests that depend on units under fpc/packages won't be checked (there's not that many of them anyway).

Sorry, you need one more parameter due to a bug in the current building infrastructure when dealing with cross-compiled testsuite runs:

make FPMAKEFPC=/full/path/to/native-compiler-built-from-same-source-tree-as-cross-compiler TEST_FPC=/full/path/to/ppcrossmipsel TEST_REMOTEPATH=/tmp/tests OPT="-O2 -ap" TEST_OPT="-O2 -ap" QUICKTEST=1 clean all digest

Jonas

Hi, I was more interested in the single box version. I forget what you call it. I will email Betty, thanks for the connection. I'm looking for a MIPS box for my own study.

It is called Fuloong, and I find I made a mistake, betty's mail is , not

Thanks, people here are really nice.

Thank you.

Jonas Maebe wrote

The QUICKTEST=1 means that tests that depend on units under fpc/packages won't be checked (there's not that many of them anyway).

I need to keep that option in mind when I'll try to run the tests for NativeNT :D

Regards,
Sven

though.

I am struggling with cpupara.pas. The use of framepoint register ($30) is not right. Printing of floating point number will fail(segmentation fault or deadloop), e.g. writeln(0.3). After some tracing, I've found that it dies in fpc_shortstr_copy,
the code is somewhat like this:

caller:
addiu $2,$29,88
sw $2,($29)
lui $4,%hi(U_$P$PROGRAM_$$_S)
addiu $4,$4,%lo(U_$P$PROGRAM_$$_S)
addiu $6,$0,2
addiu $5,$0,1
addiu $29,$29,-4
jal my_fpc_shortstr_copy
nop
addiu $29,$29,4
callee:
addiu $29,$29,-104
sw $31,44($29)
addiu $2,$30,8
addiu $3,$29,96
lw $2,($2) //this is wrong
sw $2,($3)

$30 is not initialized properly, the use of $30 register will fail. When looking at the code,
cgcpu.pas g_proc_entry (here we probably should initialize $30 like powerpc code, if needs_framepoint_ ...)
cpupara.pas I don't fully understand the code yet. The generated code with $30 is not from g_proc_entry, instead they are inserted later. Could you help show me the logic:
1, where is the frame pointer code generated and inserted? 2, when will it start to use frame pointer? I have tried that, if the function return a string, $30 will be used; if return an integer, not used. Is it depending on the return type?
3, how is the return value related to parameter handling? It seems that return value is handled as a special parameter?

And the whole code seems totally incompatible with standard mips abi, it use 6 registers to pass parameters, while o32 has 4.

BTW:
  I have fixed the boolean64 support use the following patch:
--- ncpucnv.pas	(版本 21420)
+++ ncpucnv.pas	(工作副本)
@@ -214,6 +214,8 @@
   hreg1, hreg2: tregister;
   opsize: tcgsize;
   hlabel, oldtruelabel, oldfalselabel: tasmlabel;
+  newsize  : tcgsize;
+  href: treference;
 begin
   oldtruelabel  := current_procinfo.CurrTrueLabel;
   oldfalselabel := current_procinfo.CurrFalseLabel;
@@ -223,17 +225,24 @@
   if codegenerror then
     exit;

- { byte(boolean) or word(wordbool) or longint(longbool) must }
- { be accepted for var parameters }
- if (nf_explicit in flags) and
- (left.resultdef.size = resultdef.size) and
- (left.location.loc in [LOC_REFERENCE, LOC_CREFERENCE, LOC_CREGISTER]) then
- begin
- location_copy(location, left.location);
- current_procinfo.CurrTrueLabel := oldtruelabel;
- current_procinfo.CurrFalseLabel := oldfalselabel;
- exit;
- end;
+ { Explicit typecasts from any ordinal type to a boolean type }
+ { must not change the ordinal value }
+ if (nf_explicit in flags) and
+ not(left.location.loc in [LOC_FLAGS,LOC_JUMP]) then
+ begin
+ location_copy(location,left.location);
+ newsize:=def_cgsize(resultdef);
+ { change of size? change sign only if location is LOC_(C)REGISTER? Then we have to sign/zero-extend }
+ if
(tcgsize2size[newsize]tcgsize2size[left.location.size]) or
+ ((newsizeleft.location.size) and (location.loc in [LOC_REGISTER,LOC_CREGISTER])) then
+
hlcg.location_force_reg(current_asmdata.CurrAsmList,location,left.resultdef,resultdef,true)
+ else
+ location.size:=newsize;
+ current_procinfo.CurrTrueLabel:=oldTrueLabel;
+ current_procinfo.CurrFalseLabel:=oldFalseLabel;
+ exit;
+ end;
+

   location_reset(location, LOC_REGISTER, def_cgsize(resultdef));
   opsize := def_cgsize(left.resultdef);
   case left.location.loc of

@@ -242,21 +251,35 @@

       if left.location.loc in [LOC_CREFERENCE, LOC_REFERENCE] then
       begin
         hreg2 := cg.getintregister(current_asmdata.CurrAsmList, opsize);

- cg.a_load_ref_reg(current_asmdata.CurrAsmList, opsize, opsize, left.location.reference, hreg2);
+{$ifndef cpu64bitalu}
+ if left.location.size in [OS_64,OS_S64] then
+ begin
+
cg.a_load_ref_reg(current_asmdata.CurrAsmList,OS_INT,OS_INT,left.location.reference,hreg2);
+ hreg1:=cg.getintregister(current_asmdata.CurrAsmList,OS_INT);
+ href:=left.location.reference;
+ inc(href.offset,4);
+
cg.a_load_ref_reg(current_asmdata.CurrAsmList,OS_INT,OS_INT,href,hreg1); +
cg.a_op_reg_reg_reg(current_asmdata.CurrAsmList,OP_OR,OS_32,hreg1,hreg2,hreg2);
+ end
+ else
+{$endif not cpu64bitalu}
+ cg.a_load_ref_reg(current_asmdata.CurrAsmList, opsize, opsize, left.location.reference, hreg2);

       end
       else

- hreg2 := left.location.Register;
-{$ifndef cpu64bit}
- if left.location.size in [OS_64, OS_S64] then
- begin
- hreg1 := cg.getintregister(current_asmdata.CurrAsmList, OS_32);
- cg.a_op_reg_reg_reg(current_asmdata.CurrAsmList, OP_OR, OS_32, hreg2, tregister(succ(longint(hreg2))), hreg1);
- hreg2 := hreg1;
- opsize := OS_32;
- end;
-{$endif cpu64bit}
- hreg1 := cg.getintregister(current_asmdata.CurrAsmList, opsize);
- current_asmdata.CurrAsmList.concat(taicpu.op_reg_reg_reg(A_SNE, hreg1, hreg2, NR_R0));
+ begin
+ hreg2:=cg.getintregister(current_asmdata.CurrAsmList,OS_INT); +{$ifndef cpu64bitalu}
+ if left.location.size in [OS_64,OS_S64] then
+ begin
+ hreg2:=cg.getintregister(current_asmdata.CurrAsmList,OS_32); +
cg.a_op_reg_reg_reg(current_asmdata.CurrAsmList,OP_OR,OS_32,left.location.register64.reghi,left.location.register64.reglo,hreg2);
+ end
+ else
+{$endif not cpu64bitalu}
+
cg.a_load_reg_reg(current_asmdata.CurrAsmList,opsize,opsize,left.location.register,hreg2);
+ end;
+ hreg1 := cg.getintregister(current_asmdata.CurrAsmList, opsize);
+ current_asmdata.CurrAsmList.concat(taicpu.op_reg_reg_reg(A_SNE, hreg1, hreg2, NR_R0));

     end;
     LOC_JUMP:
     begin

@@ -272,10 +295,26 @@
else

       internalerror(10062);
   end;

- location.Register := hreg1;
+{$ifndef cpu64bitalu}
+ if (location.size in [OS_64,OS_S64]) then
+ begin
+ location.register64.reglo:=hreg1;
+
location.register64.reghi:=cg.getintregister(current_asmdata.CurrAsmList,OS_32);
+ if (is_cbool(resultdef)) then
+ { reglo is either 0 or -1 -> reghi has to become the same } +
cg.a_load_reg_reg(current_asmdata.CurrAsmList,OS_32,OS_32,location.register64.reglo,location.register64.reghi)
+ else
+ { unsigned }
+
cg.a_load_const_reg(current_asmdata.CurrAsmList,OS_32,0,location.register64.reghi);
+ end
+ else
+{$endif not cpu64bitalu}
+ location.Register := hreg1;

+{zfx
   if location.size in [OS_64, OS_S64] then
     internalerror(200408241);
+}
   current_procinfo.CurrTrueLabel  := oldtruelabel;
   current_procinfo.CurrFalseLabel := oldfalselabel;

Best Regards
Fuxin Zhang

Jeppe Græsdal Johansen wrote

I managed to remove the errors with the following patch, such that everything compiled, but I haven't been able to test it: http://j-software.dk/fpc-mipsel.patch

All fixes of the patch are committed, I solved some things differently though.

And the whole code seems totally incompatible with standard mips abi, it use 6 registers to pass parameters, while o32 has 4.

cpupara needs a major overhaul. This is one of the next things I planned to do.

EXCELLENT!

+1 !

Now all we need to know is where to get a good price on your MIPS boxes so we can all run them ;-)

Ok They don't have an MMU and don't do Linux, but the PIC32 processors from Microcip have a MIPS CPU and are very cheap (up from some $2.-). And they also have very cheap development boards.

This should be perfect to test the compiler and some parts of the RTL.

-Michael

By the way, I find that qemu is really very handy for test. These days I'am using qemu-mipsel to run mipsel user land directly(like the tests, just qemu-mipsel taddcurr), without the need to start up system level emulator. It works very well(at least for now, when tests fail a lot).

Dear Florian,

Do you have any detailed estimated time plan for this? a few days? a few weeks? a few months? Our users want a usable mips compiler at this July.

If you have no time to fix it in the coming month, we will try. We will probably have lots questions to ask, hope you guys won't block my mails:) Understanding the whole logic in a few days is really not a reasonable task so I need your kind help.

BTW,I have a few fixes and may have more later, it is not very conventional to post them all in the mail, could you open a branch for me?

the fixes include:
MAP_ANON define for linux/mips
syscall.inc fixes to discard the use of a second stack. don't allocate odd FP registers since many mips processors supports only even registers operation for single values.
64bit load const fix.
Now I have got 75 ‘Successfully run' and 100 compiled in tests/cg.

Regards

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Fuxin Zhang wrote

By the way, I find that qemu is really very handy for test.

Great !

In fact I might be going to o projects with PIC32 some day soon. I'd be happy to use FPC for that.

-Michael