Re: [fpc-devel] about freepascal for mips
On 05/29/2012 01:20 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
On 05/25/2012 11:27 AM, microc...@zoho.com wrote: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
On 05/25/2012 11:27 AM, microc...@zoho.com wrote: 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. 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). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Dear Florian, 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. 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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
On 27.05.2012 21:34, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Am 25.05.2012 21:04, schrieb Jeppe Græsdal Johansen: 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
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.
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.pasg_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 :=
Re: [fpc-devel] about freepascal for mips
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
On Sat, 26 May 2012 21:00:23 +0800 (CST) zhan...@lemote.com wrote: microcode wrote 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 ;-) 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? 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 be...@lemote.com 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
On 25 May 2012, at 15:48, 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_SSH=login@mips-box 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
On 27 May 2012, at 21:34, Jonas Maebe wrote: make TEST_FPC=/full/path/to/ppcrossmipsel TEST_SSH=login@mips-box 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_SSH=login@mips-box TEST_REMOTEPATH=/tmp/tests OPT=-O2 -ap TEST_OPT=-O2 -ap QUICKTEST=1 clean all digest Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
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 zha...@lemote.com, not be...@lemote.com. You can contact be...@lemote.com 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. Thanks, people here are really nice. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Thank you. -Original Message- From: Fuxin Zhang zhan...@lemote.com Sender: fpc-devel-boun...@lists.freepascal.org Date: Mon, 28 May 2012 07:49:43 To: FPC developers' listfpc-devel@lists.freepascal.org Reply-To: zhan...@lemote.com, FPC developers' list fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] about freepascal for mips 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 zha...@lemote.com, not be...@lemote.com. You can contact be...@lemote.com 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. Thanks, people here are really nice. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Fuxin Zhang zhan...@lemote.com 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 ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Fuxin Zhang zhan...@lemote.com 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 ;-) 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 be...@lemote.com to buy. And I've declared that we can donate some for developers. Best Regards ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
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 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/loop0p120483145921015728581+ 83 Linux /dev/loop0p23145921133554303 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) 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Fuxin Zhang wrote on Fri, 25 May 2012:
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(工作副本)
[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).
/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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Fuxin Zhang wrote: 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: 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
[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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
There is mips instruction call 'B', only branches like bne/beq. Sorry I meant to say There is no mips instruction call 'B':( Yes, PIC requires cpu-specific support. It shouldn't be necessary to get an initial port up and running though. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Den 25-05-2012 13:54, Jonas Maebe skrev:
Fuxin Zhang wrote on Fri, 25 May 2012:
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(工作副本)
[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).
/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.
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
I wonder how you people managed to build anything at all.
When 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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Hi, 25.05.2012 23:04, Jeppe Græsdal Johansen: [...] When 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. 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 Regards, Jeppe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Am 25.05.2012 21:04, schrieb Jeppe Græsdal Johansen: Den 25-05-2012 13:54, Jonas Maebe skrev: Fuxin Zhang wrote on Fri, 25 May 2012: 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(工作副本) [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? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
Jonas I wonder how you people managed to build anything at all. When 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. 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/ foxsen@ubuntu-zfx:~/fpc/compiler$ 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) 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. What issues you have met? Regards, Jeppe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
