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 usefu
> 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
> 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 spec
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 i
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
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
>>>
>>> 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. Ho
> 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
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-0
>
> On 08 Jun 2012, at 17:57, Fuxin Zhang wrote:
>
>> 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
>
>>
>> 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 th
>>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 o
>
> 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
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
> 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 muc
> 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 it"s 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
>
> 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 futu
>
> 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=3&run1id=113194&testfileid=99
>
> It doesn
>>Yes, both under AIX and under Linux (either the ppc32 or the ppc64
>> version of FPC).
>>
>
> 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
>
> __
> 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 determi
> Am 04.06.2012 10:22 schrieb "Sven Barth" :
>> > 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...
>>
>> AFAIK FPC has an option for this. Call the compiler using -h and check
> the -v
neral, 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.free
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
> 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
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
> 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 c
> 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
> "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
>
>> 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 s
> 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
>>
>
>
>
> [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?
>
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
32 matches
Mail list logo
