Re: [fpc-devel] mips-linux and mipsel-linux snapshots available

[Fuxin Zhang]

Dear Mark,

于 2012/11/21 1:38, Mark Morgan Lloyd 写道:


I'm just about moving again here, but with a decided limp: the system 
that blew was 2.8GHz and all my guest OSes are now plugged into a 1GHz 
box. I still find being able to use a significant number of different 
guests in sleds/caddies useful... Unfortunately I've still not got any 
real MIPS hardware running here, so I'm still stuck on Qemu.
If you want we can donate some MIPS machines to you. We have some 
netbooks with 800MHz Loongson2F (little endian mips, almost mips64 
compatible, running debian linux/mips) in the stock.


Regards


The good news is that I can still run/build trunk for mipsel on Debian 
Squeeze on Qemu without unanticipated issues (i.e. nobody reading 
this should assume that Lazarus will work yet).


The not-so-good news is that I built from trunk earlier but after 
having bus errors in Qemu's implementation of big-endian MIPS I'm now 
looking at the file above. Unfortunately I still get bus errors and I 
think the binaries have been stripped.


If I revert to a binary that I cross-built from trunk earlier, I get 
this:


217 1markMLl@pye-dev-07c:~$ gdb /usr/local/lib/fpc/2.7.1/ppcmips
GNU gdb (GDB) 7.0.1-debian
..
Reading symbols from /usr/local/lib/fpc/2.7.1/ppcmips...done.
(gdb) run
Starting program: /usr/local/lib/fpc/2.7.1/ppcmips

Program received signal SIGBUS, Bus error.
0x0043ba68 in SYSUTILS_$$_DATETIMETOFILEDATE$TDATETIME$$LONGINT ()
(gdb) bt
#0 0x0043ba68 in SYSUTILS_$$_DATETIMETOFILEDATE$TDATETIME$$LONGINT ()
#1 0x0043edb4 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT ()
#2 0x0043fc88 in 
SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN ()

#3 0x0043ffe0 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)



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

Re: [fpc-devel] MIPS target: progress report?

[Fuxin Zhang]

 Does anybody have an update on where the MIPS port has got to after the
 flurry of activity in June?
Since it cannot catch the time requirement of our project, I have
suspended the work temporary due to other affairs. The last time I checked
the code(about the end of July) it is able to run the testbench, people
are working on PIC code support etc.

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

[fpc-devel] question about parameter loading code

[Fuxin Zhang]

Dear sirs,

  When trying to generate code debuggable by GDB, I meet a problem:

* it seems mips C code will expect a frame pointer = sp after stack
adjustment
* but in cpupara.pas, when we create para info, we don't know yet the
whole stack size, thus the reference offset cannot be set correctly

In current code, I use
   move fp, sp
   addiu sp,sp,-LocalSize
   ...
and use the frame pointer fp as reference base, so the offset for callee
can be the same as the caller side.

In MIPS ABI, the parameter area for callee functions is at the bottom of
caller function's stack, so the offsets are decided only by parameters
when use fp(or the caller's sp, or the sp upon function entry) as the
base.

   C code is something like:

  addiu sp,sp,-LocalSize
  swfp, 4(sp)
  move  fp, sp

in this way, I don't know how to generate parameter references since no
usable base register to get fixed offset for parameters in
create_paraloc_info_intern.

Could you give some hints?

Best Regards

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

[fpc-devel] strange behavior of mips stabs

[Fuxin Zhang]

for a function like this:
   int i(int b)
{
int i1,i2,i3;
return i1 + i2;
}

in x86, compile with gcc -fno-pic -fomit-frame-pointer -gstabs -O0 -S
the output is:
Lscope1:
.stabs  i:F(0,1),36,0,0,i
.stabs  b:p(0,1),160,0,0,-20
.globl i
.type   i, @function
i:
.stabn  68,0,10,.LM5-.LFBB2
.LM5:
.LFBB2:
.LFB1:
.cfi_startproc
movl%edi, -20(%rsp)
.stabn  68,0,12,.LM6-.LFBB2
.LM6:
movl-8(%rsp), %eax
movl-4(%rsp), %edx
leal(%rdx,%rax), %eax
.stabn  68,0,13,.LM7-.LFBB2
.LM7:
ret
.cfi_endproc
.LFE1:
.size   i, .-i
.stabs  i1:(0,1),128,0,0,-4
.stabs  i2:(0,1),128,0,0,-8
.stabs  i3:(0,1),128,0,0,-12
.stabn  192,0,0,.LFBB2-.LFBB2
.stabn  224,0,0,.Lscope2-.LFBB2

Everything works as expect:
   the offsets for both parameters and locals are negative, no matter in
stabs directive or in the assembly code. And the offset value in stabs
equals to the one in the code.

But for mips, mipsel-linux-gcc -fno-pic -fomit-frame-pointer -gstabs -O0
-S output is:
scope1:
.align  2
.stabs  i:F(0,1),36,0,0,i
.stabs  b:p(0,1),160,0,0,24
.globl  i
.enti
.type   i, @function
i:
.stabn  68,0,10,$LM5
$LM5:
$LFBB2:
.setnomips16
.frame  $sp,24,$31  # vars= 16, regs= 0/0, args= 0, gp= 8
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro

addiu   $sp,$sp,-24
.cprestore  0
sw  $4,24($sp)
.stabn  68,0,12,$LM6
$LM6:
lw  $3,16($sp)
lw  $2,12($sp)
nop
addu$2,$3,$2
.stabn  68,0,13,$LM7
$LM7:
addiu   $sp,$sp,24
j   $31
nop

.setmacro
.setreorder
.endi
.stabs  i1:(0,1),128,0,0,-8
.stabs  i2:(0,1),128,0,0,-12

The local variable offsets in stabs are negative, but in the code they are
positive. For my understanding of fpc logic, they should both generated
from loc.reference.offset or something similiar, they cannot be different.
If I am not making mistake, we have to special case some code to make
debugging work.

Am I wrong?

Regards



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

Re: [fpc-devel] strange behavior of mips stabs

[Fuxin Zhang]

After looking into the gcc code, it is really so uncommon:( Lots of pain
to get full support.

gcc-4.4.6/gcc/config/mips/mips.c
  line 7484:
 /* The MIPS debug format wants all automatic variables and arguments
   to be in terms of the virtual frame pointer (stack pointer before
   any adjustment in the function), while the MIPS 3.0 linker wants
   the frame pointer to be the stack pointer after the initial
   adjustment.  So, we do the adjustment here.  The arg pointer (which
   is eliminated) points to the virtual frame pointer, while the frame
   pointer (which may be eliminated) points to the stack pointer after
   the initial adjustments.  */

HOST_WIDE_INT
mips_debugger_offset (rtx addr, HOST_WIDE_INT offset)
{
  rtx offset2 = const0_rtx;
  rtx reg = eliminate_constant_term (addr, offset2);

  if (offset == 0)
offset = INTVAL (offset2);

  if (reg == stack_pointer_rtx
  || reg == frame_pointer_rtx
  || reg == hard_frame_pointer_rtx)
{
  offset -= cfun-machine-frame.total_size; // here it is
  if (reg == hard_frame_pointer_rtx)
offset += cfun-machine-frame.hard_frame_pointer_offset;
}


 for a function like this:
int i(int b)
 {
 int i1,i2,i3;
 return i1 + i2;
 }

 in x86, compile with gcc -fno-pic -fomit-frame-pointer -gstabs -O0 -S
 the output is:
 Lscope1:
 .stabs  i:F(0,1),36,0,0,i
 .stabs  b:p(0,1),160,0,0,-20
 .globl i
 .type   i, @function
 i:
 .stabn  68,0,10,.LM5-.LFBB2
 .LM5:
 .LFBB2:
 .LFB1:
 .cfi_startproc
 movl%edi, -20(%rsp)
 .stabn  68,0,12,.LM6-.LFBB2
 .LM6:
 movl-8(%rsp), %eax
 movl-4(%rsp), %edx
 leal(%rdx,%rax), %eax
 .stabn  68,0,13,.LM7-.LFBB2
 .LM7:
 ret
 .cfi_endproc
 .LFE1:
 .size   i, .-i
 .stabs  i1:(0,1),128,0,0,-4
 .stabs  i2:(0,1),128,0,0,-8
 .stabs  i3:(0,1),128,0,0,-12
 .stabn  192,0,0,.LFBB2-.LFBB2
 .stabn  224,0,0,.Lscope2-.LFBB2

 Everything works as expect:
the offsets for both parameters and locals are negative, no matter in
 stabs directive or in the assembly code. And the offset value in stabs
 equals to the one in the code.

 But for mips, mipsel-linux-gcc -fno-pic -fomit-frame-pointer -gstabs -O0
 -S output is:
 scope1:
 .align  2
 .stabs  i:F(0,1),36,0,0,i
 .stabs  b:p(0,1),160,0,0,24
 .globl  i
 .enti
 .type   i, @function
 i:
 .stabn  68,0,10,$LM5
 $LM5:
 $LFBB2:
 .setnomips16
 .frame  $sp,24,$31  # vars= 16, regs= 0/0, args= 0,
 gp= 8
 .mask   0x,0
 .fmask  0x,0
 .setnoreorder
 .setnomacro

 addiu   $sp,$sp,-24
 .cprestore  0
 sw  $4,24($sp)
 .stabn  68,0,12,$LM6
 $LM6:
 lw  $3,16($sp)
 lw  $2,12($sp)
 nop
 addu$2,$3,$2
 .stabn  68,0,13,$LM7
 $LM7:
 addiu   $sp,$sp,24
 j   $31
 nop

 .setmacro
 .setreorder
 .endi
 .stabs  i1:(0,1),128,0,0,-8
 .stabs  i2:(0,1),128,0,0,-12

 The local variable offsets in stabs are negative, but in the code they are
 positive. For my understanding of fpc logic, they should both generated
 from loc.reference.offset or something similiar, they cannot be different.
 If I am not making mistake, we have to special case some code to make
 debugging work.

 Am I wrong?

 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] question about parameter loading code

[Fuxin Zhang]

 Dear sirs,


C code is something like:

   addiu sp,sp,-LocalSize
   swfp, 4(sp)
   move  fp, sp

 in this way, I don't know how to generate parameter references since no
 usable base register to get fixed offset for parameters in
 create_paraloc_info_intern.

Can we use a special virtual register as base here? Then after the stack
size is known, we could replace the base/offset with real fp and offset.

1, At what time can the stack size of a procedure be known/fix?
2, Is there any other access to the para array before gen_load_para_value?

Also for the debug stabs generation, we could mark the symbol need to get
special treating, and handle it when writing it out.

 Could you give some hints?

 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

[fpc-devel] fixes of the mips code

[Fuxin Zhang]

Hi,

  Based on trunk r21549, I have uploaded all my patches to my branch,
please help to review and merge if possible.

svn log --stop-on-copy
http://svn.freepascal.org/svn/fpc/branches/foxsen/mips ：


r21564 | foxsen | 2012-06-09 17:01:14 +0800 (六, 2012-06-09) | 2 行

mips C_alignment is incorrect, hack for now


r21563 | foxsen | 2012-06-09 16:52:24 +0800 (六, 2012-06-09) | 5 行

remove macros already by common code:
  FPC_HAS_TYPE_DOUBLE
  FPC_HAS_TYPE_SINGLE
  FPC_REQUIRES_PROPER_ALIGNMENT


r21562 | foxsen | 2012-06-09 16:50:04 +0800 (六, 2012-06-09) | 2 行

make the calling convention support MIPS O32 ABI


r21561 | foxsen | 2012-06-09 11:32:24 +0800 (六, 2012-06-09) | 3 行

fix short/smallint operations
without this test/cg/tcnvint6.pp failed at 31


r21560 | foxsen | 2012-06-09 11:23:50 +0800 (六, 2012-06-09) | 3 行

enable softfpu, default first_int_to_real depends on int64_to_float64/32 etc.
It is needed by the patch of r21558


r21559 | foxsen | 2012-06-09 11:12:30 +0800 (六, 2012-06-09) | 3 行

set default round mode to round nearest instead of round to zero
it fix test/cg/taddcurr.pp


r21558 | foxsen | 2012-06-09 11:01:56 +0800 (六, 2012-06-09) | 3 行

use inherited first_int_to_real to avoid mixing doubles and singles
it fixes the failure of test/cg/taddcurr.pp


r21557 | foxsen | 2012-06-09 10:59:32 +0800 (六, 2012-06-09) | 4 行

Make macro MIPS/CPUMIPS/MIPS32 common for big endian and little endian
mips processors
use MIPSEL* for little endian systems
use MIPSEB* for big endian systems


r21554 | foxsen | 2012-06-08 23:56:28 +0800 (五, 2012-06-08) | 2 行

correct constant for mipsel


r21553 | foxsen | 2012-06-08 23:50:04 +0800 (五, 2012-06-08) | 2 行

make clear what registers might need to be saved


r21552 | foxsen | 2012-06-08 23:45:24 +0800 (五, 2012-06-08) | 3 行

use NR_R1 instead of NR_R3 for big stack adjustment temp register(R1 is
$at, more suitable)
use A_JR for register operands, although the assembler can translate J to
JR when necessary, it is more clear


r21551 | foxsen | 2012-06-08 23:37:18 +0800 (五, 2012-06-08) | 3 行

use cpu64bitaddr instead of cpu64bit
fix wrong order of 64BIT return register(now for little endian mips)


r21550 | foxsen | 2012-06-08 23:04:03 +0800 (五, 2012-06-08) | 2 行

merge trunk r21549



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

Re: [fpc-devel] fixes of the mips code

[Fuxin Zhang]

 Hi,

   Based on trunk r21549, I have uploaded all my patches to my branch,
 please help to review and merge if possible.

 svn log --stop-on-copy
 http://svn.freepascal.org/svn/fpc/branches/foxsen/mips ：

 
 r21564 | foxsen | 2012-06-09 17:01:14 +0800 (六, 2012-06-09) | 2 行

 mips C_alignment is incorrect, hack for now
This one is wrong, correct fix should be:

r21565 | foxsen | 2012-06-09 17:28:32 +0800 (六, 2012-06-09) | 3 行

revert incorrect fix for C_alignment at revision 21564
set proper record alignments in i_linux.pas instead


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

Re: [fpc-devel] progress of freepascal for mips

[Fuxin Zhang]

 Please keep copyright in mind when adding new stuff!
I have removed the link in the wiki and the files from lemote web. Sorry
for the thinkless action.
Opening the ABI documents should be a good thing to help its eco-system,
if I have chance I will try to pasuade mips.

 Absolutely. However I think that a paraphrased description of e.g. the
 calling conventions used by a particular CPU isn't something that could
 be copyrighted: patented, perhaps, or viewed as a leaked trade secret,
 but not copyrighted.

 Yes, true, however, I was more aiming at uploading files.

 ___
 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] progress of freepascal for mips

[Fuxin Zhang]

 Hi Fuxin,

   I committed to trunk your changes together with
 a few changes to cpupara that allow me to generate
 a compiler (not yet operational, but its going forward).
 Florian asked be to commit it.
Thank you for your work, then I will start based on the trunk.

   It is not closely following a specific abi, but for parameters
 it works like this:
   Up to 6 parameters are passed in registers $r4 to $r9,
 others on the stack starting at offset 24 (=6*4).
 (I had to adapt the 6 parameter very of linux/mips/syscall.inc
 in order to get fpmmap to work).
Yes, I did the same work to make some tests work.

   The startup code of the function pushes these registers
 back to the 6 4 byte slots from 0 to 24.
   It sets $fp register ($r29 or $s8)
 to the previous value of the $sp stack register.
   This way, function parameters can be accessed by
 offsets to $fp register, while locals or parameters
 of function that will be called inside the function
 are accessed via $sp register.
Understand.

   The biggest problem now is that GDB is not
 pleased this, because it find that there is a frame register ($r29)
 so that it computes falsely the address of all locals and arguments...
We have to study how GDB analysis mips stack, up to now I use gdb only
with instruction level debugging: break *0x4001da, si, info registers
etc.:)
But I think it won't be hard. I have looked at lots of c compiler's
code,we are not very far away from it.

   I think that we should add a list of all mips known ABI and
 create a record that lists their specificities,
   This way, we should be able to convert some constants
 into ABI specific values.
In the real world the MIPS O32 abi is still a de facto ABI. N32/N64
support is still not very robust for linux/mips. So I think we should
first add the support of O32. My new code is almost O32 compatible and I
will upload it as soon as possible.

What do you mean by stating 'create a record that lists their
specificities'? Is it that we create a readme file for mips ABI and upload
it to the repository? There is an old ABI document for O32 called System
V APPLICATION BINARY INTERFACE MIPS RISC Processor supplement, you can
get it from http://www.lemote.com/upfiles/mipsabi32.pdf.

Regards



 Pierre







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

Re: [fpc-devel] progress of freepascal for mips

[Fuxin Zhang]

 I made a start at trying to get assembler and backend info into the
 Wiki, my intention was to at least have URLs for the various ABIs. I
 rather ground to a halt after getting examples of the assembler format
 together for most targets, if anybody could contribute ABI stuff it
 would be much appreciated.

 http://wiki.lazarus.freepascal.org/Assembler_and_ABI_Resources
I have added a link to mips O32 ABI file to the MIPS section.

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

[fpc-devel] about mips/mipsel chaos

[Fuxin Zhang]

hi buddys,

 Current trunk code use both CPUMIPS/CPUMIPS32/CPUMIPSEL etc. which make
it easy to be wrong. For example, now the rtl code use only CPUMIPS, so
for mipsel something will be wrong. It brings me some troubles while
trying to integrate patches already.

  Since mipsel/mips has most of the code equal(code is endian free or use
endian setting in target_info), I would like to propose make such
conventions:

   define mips, cpumips, mips32 for use of common mips related code
   define mipsel/mipsel32 for little endian cpus
   define mipseb/mipseb32 for big endian cpus

 to avoid code like if defined(mips) or defined(mipsel） ... everywhere.

What do you think? If ok, I will go on to make the patches.

Regards

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

Re: Re: [fpc-devel] progress of freepascal for mips

[Fuxin Zhang]

 Fuxin, is there a formal 64 bit ABI from MIPS Inc.? I think you said
 earlier the Linux 64 bit ABI is not exactly stable, but there are a few
 other OS running on 64 bit MIPS (OpenBSD and FreeBSD and NetBSD, as far as
 I know). If MIPS or some other standards body has documented the 64 bit
 MIPS ABI I'd like to get a copy of it. I found some old SGI doc but I
 don't
 know how universal it is.
I get a copy from my colleague for N32 ABI, no N64 found yet.See
http://www.lemote.com/upfiles/mips-abi-n32.pdf. I put it here because no
confidential sign in the document. But I am not sure whether it comes from
MIPS as a material to licensee. Will check later.

 Thanks.



 ___
 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 mips/mipsel chaos

[Fuxin Zhang]

define mips, cpumips, mips32 for use of common mips related code
define mipsel/mipsel32 for little endian cpus
define mipseb/mipseb32 for big endian cpus

  to avoid code like if defined(mips) or defined(mipsel) ...
 everywhere.

 What do you think? If ok, I will go on to make the patches.

 That definitely needs comment from Jonas, Florian, or another core
 developer. It's an issue I struggled with last Summer when I was trying
 to work through David Zhang's code.

Yes, I agree. Some long term constants are involved. But anyway current
situation needs a clean up. 64 bit MIPS processors become more popular, we
might have need to support mips64 soon. el/eb * 32/64 will be a
headache...

 --
 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: Re: [fpc-devel] progress of freepascal for mips

[Fuxin Zhang]

 Fuxin, is there a formal 64 bit ABI from MIPS Inc.? I think you said
 earlier the Linux 64 bit ABI is not exactly stable, but there are a few
 other OS running on 64 bit MIPS (OpenBSD and FreeBSD and NetBSD, as far
 as
 I know). If MIPS or some other standards body has documented the 64 bit
 MIPS ABI I'd like to get a copy of it. I found some old SGI doc but I
 don't
 know how universal it is.
 I get a copy from my colleague for N32 ABI, no N64 found yet.See
 http://www.lemote.com/upfiles/mips-abi-n32.pdf. I put it here because no
 confidential sign in the document. But I am not sure whether it comes from
 MIPS as a material to licensee. Will check later.
The same document also describe about N64, since it is very close to N32.

 Thanks.



 ___
 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] progress of freepascal for mips

[Fuxin Zhang]

 Fuxin Zhang wrote on Sat, 02 Jun 2012:

   With the attached patch (against revision 21440), most of the tests
 can
 now pass, for example, the test directory has only the following
 failinglist:

 When committing/submitting patches in the future, please split them up
 into smaller independent patches. That makes it much easier to review
 them.

OK, I will take some time to clean up things and split them into
independent trunks. Florian has open a branch for me, I will try to do it
in the branch with clear log.
These days I am fight with the parameter passing. It is almost mips O32
compatible, only five of the test/cg/ still fail.
foxsen@ubuntu-zfx:/software/data/fpc/tests$ cat
output/mipsel-linux/faillist.testlog
test/cg/tdivz2
test/cg/tprintf
test/cg/tprintf2
test/cg/treadwrt
test/cg/tumin
...


 Jonas



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

Re: [fpc-devel] Question about Currency support

[Fuxin Zhang]

 Fuxin Zhang wrote on Tue, 05 Jun 2012:

 Is it the test program taddcurr.pp cannot work for non-x86 systems?

 It works on SPARC at least:
 http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=3run1id=113194testfileid=99

 It doesn't work on ppc32 currently, but that's due to a bug in the
 ppc32 code generator somewhere (the ppc compiler halts with an
 internalerror; I haven't had the time yet to properly debug it).

I have found the cause of failure:

  double div 99900/1.0 = 9.99 in round to nearest mode, =9.899.. in
round to zero mode.

After correcting the related fpc_setfsr, taddcurr.pp now pass.



 Jonas



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

[fpc-devel] Question about Currency support

[Fuxin Zhang]

hi,

  The tests/test/cg/taddcurr.pp fails for mips now, after some tracing,
I've reduced the error to a simpler one:
program t;

var
  i,j : currency;
begin
  j := -1.001;
  i := j / 10.0;

  writeln(i,' ',j);

end.
The generated code is:
  ...
.stabn 68,0,6,.Ll2 - main
.Ll2:
addiu   $3,$0,-10010  //load -10010 to a int64 store
lui $2,%hi(U_$P$T_$$_J)
sw  $3,%lo(U_$P$T_$$_J)($2)
addiu   $2,$0,-1
lui $3,%hi(U_$P$T_$$_J+4)
addiu   $3,$3,%lo(U_$P$T_$$_J+4)
sw  $2,($3)
.stabn 68,0,7,.Ll3 - main
.Ll3:
lui $2,%hi(U_$P$T_$$_J)
lw  $4,%lo(U_$P$T_$$_J)($2)
lui $2,%hi(U_$P$T_$$_J+4)
addiu   $2,$2,%lo(U_$P$T_$$_J+4)
lw  $5,($2)
jal fpc_int64_to_double//convert it to double
nop
lui $2,%hi(_$T$_Ld1)
addiu   $2,$2,%lo(_$T$_Ld1)
lwc1$f2,($2)
div.s   $f0,$f0,$f2   // div 1.0, but problem is that
f0 contains a double value, here div.s is used
lui $2,%hi(_$T$_Ld2)
addiu   $2,$2,%lo(_$T$_Ld2)
lwc1$f2,($2)
div.s   $f0,$f0,$f2  // should be div 10.0
lui $2,%hi(_$T$_Ld1)
addiu   $2,$2,%lo(_$T$_Ld1)
lwc1$f2,($2)
mul.s   $f0,$f0,$f2  // mul 1.0
cvt.d.s $f0,$f0
swc1$f0,84($29)
swc1$f1,88($29)
lw  $4,84($29)
lw  $5,88($29)
jal fpc_round_real
nop

I guess it is related to mips/ncpucvn.pas:
   tmipseltypeconvnode.first_int_to_real
when compared to ncnv.pas, it seems ignore the floatype of resultdef. But
using the inherited first_int_to_real is impossible since
int64_to_float64/float32 etc. are not implemented(how can the sparc
version work if so, it call the inherited one?)

BTW,
  for the statement i := j / 10.0, is that in the div node, resultdef
refers to i, left refers to j, and right refers to 10.0?
  But for the typeconvnode, what is the result/left/right node?
In general, is there a way for me to learn about the node generating
process? E.g. add print somewhere to show it? Add in each node seems too
much...

Thanks in advance.

Regards
Fuxin Zhang





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

Re: [fpc-devel] Question about Currency support

[Fuxin Zhang]

 In general, the type using which Pascal expressions are evaluated is
 completely independently from how the result is used afterwards.

 Currency is a special case because of all the scaling going on though.
 In addition to the resultdef, there's also the nf_is_currency node
 flag to determine whether or not the value still has to be scaled.

   But for the typeconvnode, what is the result/left/right node?

 There is no right node in a typeconvnode, only a left node
 (ttypeconvnode inherits from tunarynode, not from binary node). Left
 is whatever you are converting from, and resultdef (once it has been
 set from ttypeconvnode.totypedef) is what you are converting to.

I see now.

another question, after switch to int64_to_floatxx, the code should be
correct, but there is another issue that can be reduced to:
  i : currency;
  i := 9.99;
  frac(i)  frac(9.99)

frac(i) will be 9.88E-001

tests/test/cg/taddcurr.pp still fail with this.

in gdb,
  (gdb) p 9.99 * 1.0 / 1.0
$1 = 9.9867

Is it the test program taddcurr.pp cannot work for non-x86 systems?

 Jonas



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

Re: [fpc-devel] progress of freepascal for mips

[Fuxin Zhang]

Yes, both under AIX and under Linux (either the ppc32 or the ppc64
 version of FPC).

 #160;
 That means that there is a native version of FPC or an emulated x86
 version?
Judging from the source, it should be a native version.


 Leonardo M. Ram�
 http://leonardorame.blogspot.com

 ___
 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]

 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

[Fuxin Zhang]

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

[Fuxin Zhang]

 := 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

___
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]

 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

[Fuxin Zhang]

 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

[Fuxin Zhang]

 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

[fpc-devel] about freepascal for mips

[Fuxin Zhang]

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

Re: [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



___
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]

 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

[Fuxin Zhang]

 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