Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk.

Before I start trying to build it, could anybody comment on how complete an implementation it is?

Apart from that I can confirm that David's code on Sourceforge is good enough for trivial programs that run on a recent Linux hosted by Qemu.

Mark Morgan Lloyd wrote

Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk.

Great !

Will this allow for producing code for PIC 32 Chips ?

Thanks,
-Michael

Michael Schnell wrote

Will this allow for producing code for PIC 32 Chips ?

Are you saying that PIC 32 is MIPS? Little Endian?

But even if it is, a RTL for PIC would be missing then. The currently made work is for linux-mipsel, so that means a new code generator and the existing linux RTL.

pic-mipsel would require a new PIC32 RTL

In our previous episode, Felipe Monteiro de Carvalho said:

Are you saying that PIC 32 is MIPS? Little Endian?

The site lists "32-bit MIPS M4K� Core"

I have a PIC32MX795, though I don't use it (it is an alternate chip for the 16-bit dspic development board that i have.

But even if it is, a RTL for PIC would be missing then. The currently made work is for linux-mipsel, so that means a new code generator and the existing linux RTL.

I think full Object Pascal HLL will quickly exhaust the 128kb memory. (and in practical cases less, since then some of it will be allocated as DMA buffers by e.g. the ethernet engine)

So one would really need a cut down RTL for this.

Felipe Monteiro de Carvalho wrote

Are you saying that PIC 32 is MIPS? Little Endian?

http://ww1.microchip.com/downloads/en/DeviceDoc/DS-39904j.pdf

"PIC32 Microcontroller Families With USB, CAN and Ethernet"

says:

"80 MHz, 1.56 DMIPS/MHz MIPS M4K Core
512K Flash with pre-fetch cache
128K RAM for data and program execution
Fast interrupts and context switch"

I don't know about endianess with MIPS.

pic-mipsel would require a new PIC32 RT

It seems to be viable to do a PIC32 RTL, as the 32 PIC seems to offer a great price/performance relation many nice chips with appropriate I/O and good support by Microchip.

The said document also states:

Free USB, TCP/IP graphics and file system source code

" Broad Third Party ecosystem
$49.99 starter kit with free C compiler
Hardware trace for less than $80"

See www.microchip.com/PIC32 as well.

-Michael

Marco van de Voort wrote

I have a PIC32MX795, though I don't use it (it is an alternate chip for the 16-bit dspic development board that i have.

same here :)

-Michael

There even is a Linux for PIC32

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2519&param=en546018

No idea if this is really useful ?

-Michael

Marco van de Voort wrote

So one would really need a cut down RTL for this.

That's why we have the feature switches. Though I admit that it hard to use for the "outer" rtl and packages because it would require a lot of ifdef'ing thus polluting the sources.

Although despite my enthusiasm for Linux, for hardware like that I find myself asking /why/. I think there's a fairly clear demarcation between projects/products which really do need a multitasking OS with networking etc., and those that quite simply need to fiddle a few inputs and outputs.

The real problem is memory size: I remember a development job a few years ago that was basically well-specified and well-planned, but by the time the multitude of UI screens had been roughed out it was painfully obvious that it wouldn't fit in the targeted board's address space. Then it turned out that the compiler supported paging but that the linker offset the tables by one entry: I managed to fix the binaries but we /still/ ran out of space.

That experience is, in part, why these days I am more interested in native than cross compilation. If you can get the basic functionality of a project running on a "real" computer to the point where you can gauge its performance and requirements, you're then in a far stronger position to specify the target hardware.

This is where I think we're at.

* The compiler compiles to one that runs on x86 and generates mipsel.

* In the rtl, prt0.as assembles after a couple of fixes.

* In the rtl, dllprt0.as is missing but I notice that on SPARC and several others it is empty. I've tentatively created an empty file.

* In the rtl, cprt0.as is missing and I notice that on other targets it is not empty. Same applies to gprt0.as.

Ongoing notes at
http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Mainline_MIPS_Port

Mark Morgan Lloyd wrote

* In the rtl, dllprt0.as is missing but I notice that on SPARC and several others it is empty. I've tentatively created an empty file.

The contents of this file have to be implemented to compile dynamic libraries.

* In the rtl, cprt0.as is missing and I notice that on other targets it is not empty.

This one is required to compile programs that link to the C library.

Same applies to gprt0.as.

And this one is required to compile programs with -pg (gprof support)

Jonas

Thanks, so for the moment they can be dummies? I think I could fill them in if necessary by referring to other platforms, but I'd rather get the hang of the calling conventions etc. first.

Current situation is that after ensuring the existence of dummy files I've stepped back from the RTL code and am looking at a problem that appears to be caused by floating point initialisation in the cross compiler.

http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Stall_point

As usual, all hints appreciated :-)

A define incorrectly suggested that MIPS was using MM registers. Now back following missing files/symlinks in the RTL.

http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Stall_point

I hope to have an SGI machine in a few days, provided that it works (it's been stored in a garage) I might be able to look at mips as well as mipsel.

In our previous episode, Mark Morgan Lloyd said:

wrt the missing of STAT.inc, IIRC the stat record definition on linux was found to be slightly architecture dependant (x86 being a bit different due to legacy reasons, of both FPC and Linux).

Probably the wisest is to take the PPC one and check it quickly against the header.

Thanks, I'm already using ppc for comparison purposes which is why I had a hard time finding the MM issue :-)

Question if I may: should I be avoiding symlinks as non-portable?

I'm gradually hacking through with a mixture of command-line compilation and using Lazarus to step through. I considered looking at FPP to see if I could log all procedure calls, I thought I was looking for something that hadn't been initialised properly.

I had a MIS related question:

using fullcycle I got a warinng about
defdynlinker not being initialized fro mips in systems/t_linux.pas unit.

Is this a correct fix,
Index: t_linux.pas
=================================================================== --- t_linux.pas (révision 17859)
+++ t_linux.pas (copie de travail)
@@ -192,6 +192,9 @@
{$endif FPC_ARMEL}
{$endif arm}

+{$ifdef mips}
+ defdynlinker:='/lib/ld-linux.so';
+{$endif mips}
{
Search order:
glibc 2.1+

or can somoeone tell us what the default linker is for a mips linux machine?

Pierre Muller

was

> found to be slightly architecture dependant (x86 being a bit different

due

colleagues]

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

In our previous episode, Mark Morgan Lloyd said:

For anything that should go back into SVN: no symlinks (*).

(and in general, even without SVN concerns, I don't think heavy symlinking is a good concept in sources. This would cause only problems because sb might modify it for ppc, and not notice mips also linked to the file)

(*)http://subversion.apache.org/faq.html#symlinks

Mark Morgan Lloyd wrote

Question if I may: should I be avoiding symlinks as non-portable?

NTFS can do symlinks even though the normal M$ tools are not able to manage them.

-Michael

I can't say at this point. I'm working through step-by-step starting with a cross compiler, i.e. I'm a long way from having a full build.

/If/ I get to the point of a full build then hopefully somebody will review my work and consider merging it with trunk. Until then I'm working with a local copy, but the issues I find are noted on the wiki page.

Thanks, noted. Obviously while I've just got a local copy on my system I can easily locate symlinks, SVN is very much in the future since I've got limited confidence in my work so far.

To answer his question you only need to issue the following command in your MIPS emulator running Linux:

which ld

This should tell you where the linker is

I think his is a loader issue- the binary needs to know what .so to pull in that later allows it to work out paths etc.

+{$ifdef mips} + defdynlinker:='/lib/ld-linux.so'; +{$endif mips}

Mark Morgan Lloyd wrote

I think his is a loader issue- the binary needs to know what .so to pull in that later allows it to work out paths etc.

ops, it seams that you are right =O

In our previous episode, Mark Morgan Lloyd said:

I think his is a loader issue- the binary needs to know what .so to pull in that later allows it to work out paths etc.

Indeed. "ldd ./gccbinary" name might be more revealing.

I only spotted it when I started wondering whether 'which' was going to be any use in a cross-development environment such as I think one has to start with in this case.

I presume the answer to the original question is "use the one on the system you're working on". In other words, if building a cross compiler to run on i386 assume /lib/ld-linux.so.2; the {$ifdef mips} will only come into play when building to run natively.

On Debian "Squeeze" mipsel (using Marco's suggestion):

$ ldd `which gcc`
libc.so.6 => /lib/libc.so.6 (0x2aab0000)
/lib/ld.so.1 (0x55550000)

$ ls -l /lib/ld.so.1
lrwxrwxrwx 1 root root 12 May 13 11:32 /lib/ld.so.1 -> ld-2.11.2.so

I don't know whether the symlink is resolved during linkage or at load time. I've certainly found a case on Solaris where the former applied for system libraries.

So I added /lib/ld.so.1 as default dynamic linker for now to trunk.

Pierre

You are wrong. The define "mips" is set when you are compiling a FPC that supports "mips" no matter what platform you run on. The CPU defines that are defined when crosscompiling are prefixed with "CPU". So the define for checking whether you are running on MIPS is "CPUMIPS".

My personal assumption regarding the linker: it might be ok to use the normal Linux ones.

Regards,
Sven

:-)

It turned out to be a radio ham's garage, rather than the garden variety. FPC for IRIX, anybody? :-)

I hope everybody appreciates that that was a poor attempt at a joke. MIPS (or rather, I think, mipsel) seems to be getting a bit of attention due to Tilera's efforts, SGI appears to be involved but I think that they're using the chips as coprocessors rather than reconstituting their classic MIPS-based supercomputers as "systems on a chip".

Mark Morgan Lloyd wrote

MIPS (or rather, I think, mipsel) seems to be getting a bit of attention

+1

The 32 bit PIC is a MIPS.

The NIOS CPU (that can be programmed into an Altera FPGA) is very similar to a MIPS.

I suppose a basic MIPS is the straight-forward (=32 bit instruction word, tenths of General purpose registers) 32 Bit CPU that uses the lowest hardware resources, so the chip and FPGA designers love it.

OTHO there is this very interesting "ZPU" architecture (8 bit instruction set only two (PC and SP) registers) the needs even less hardware.

-Michael

I'm trying to put some more time into this. I've got to the point where building the RTL complains with 'Selected assembler reader not supported' which I suspect is because there isn't an racpugas.pas unit in the compiler. Could somebody please kick me ASAP if this isn't the case.

As a general question (or possibly this is a feature request), should fpc -i report the available assembler formats? How about also the svn revision number if available?