Hello,

I've been working on the PPC64-port for the Linux on Power contest for some time now, and finally have some questions I'd like to ask for here:

Some introduction: I am trying to use the PPC64-ELF ABI for all generated methods, first because of compatibility issues (I believe it's needed anyway) and it imo does not really matter which to choose initially. There are two problems with that though; I didn't fix them yet because I'm hesitating to change stuff in the compiler-directory (all ppc64 specific things are in a subdirectory at the moment), and that's why I'm asking:

*) functions are not simple adresses anymore, but references to a so called function descriptor (if I remember the name correctly). Problem is that the assembly generator seems to hardcode the method specification prologue to:

.globl <mangledmethodname>
.type <mangledmethodname>, @function
<mangledmethodname>:
... method assembly ...

Problem is that this does not seem to work on PPC64 (tried on some hand-made assembly code); the GNU linker assumes that <mangledmethodname> is a function pointer, mangles it, and the resulting programs always crash on calling a method... ;-)

I found that in aggas.pas this behaviour seems to be hardcoded. Is there another way to change the function specification prologue? (Btw, there's a similar problem with the epilogue)

There is a way to specify "local" methods without those function pointers, but... this works for local methods only. :(

*) as far as I understand PPC64 ELF ABI assumes that at if there's a stack, the area which holds the register contents R3-R10 is always available (e.g. the 8x8 bytes for saving register contents). Is there a way to specify a minimum size for the stack without changing something in the method which calculates stack layout?
(I thought of something like dummy local variables if needed)

*) How do I add a symbol/constant to the TOC? I'd like to avoid certain really time consuming operations on constants...

*) one really minor thing: what should the platform be called? PPC64? POWERPC64? POWERPC_64 (like x86_64)? =)

Finally I've got some more general question on the challenge:

What does "must be optimized for 64-bit platforms" in the challenge details mean?
In the same sense I'd like to ask if you could specify some sort of minimum requirements for the port in a little more detail? (E.g. must cycle using the makefiles, must integrate into fpc distro, must compile + run IDE, must successfully run x tests, etc..., whatever)

Regards,
Thomas

Check the output of 'gcc -S' with a simple example. The code to write the function prologue/epilogue can be moved to a virtual function and be overriden for ppc64 if needed.

See sparc

What the Linux kernel returns with 'uname -m'

Usage of 64 bit address space.

In the same sense I'd like to ask if you could specify some sort of minimum requirements for the port in a little more detail? (E.g. must cycle using the makefiles, must integrate into fpc distro, must compile + run IDE, must successfully run x tests, etc..., whatever)

I think it depends if other people are working on it as well.

I would consider the following levels of porting:
- good test results (20-30 failures is a good results for non i386)
- make cycle
- makepack.sh
- run the ide
- run lazarus

Of course, another thing is how good the quality of the implementation is i.e. how good does it integrate into the existing compiler and powerpc sources.

I think before going into any more detail, we should contact the organisers of the contest and ask them what they mean exactly with

"DO NOT CONTACT THE JUDGES DIRECTLY. ANY ENTRANT WHO CONTACTS THE JUDGES DIRECTLY FOR ANY REASON WILL BE IMMEDIATELY DISQUALIFIED."

We are the judges for this port. I assume "posting on a mailing list" does not constitute "contacting judges directly", but better be safe than sorry.

Jonas

have they deliberately put a bomb in there to make in near impossible for them to actually win anything.

how are you supposed to do something as complex as a compiler port and get the results accepted without cooperating with the compilers developers.

ROTFL, that's how things go when "money" becomes an issue.

Regards,
Matthias.

peter green wrote

have they deliberately put a bomb in there to make in near impossible for them to actually win anything.

Several tier 2 prizes have already been won (you can see that if you register for an account, log in and go to the page to submit a port).

how are you supposed to do something as complex as a compiler port and get the results accepted without cooperating with the compilers developers.

It's indeed hard. I submitted a port for the Open Cobol compiler, but it was rejected. I got no feedback whatsoever as to why.

Jonas

I'd recommend adding a few stages:

I would consider the following levels of porting: - good test results (20-30 failures is a good results for non i386) - make cycle

- create minimal program that links to C (I used the ncurses tests typically)
- fix important testsuite tests (texception tests, make sure threading works)

- makepack.sh - run the ide - run lazarus

Florian Klaempfl wrote

I think it depends if other people are working on it as well.

How many people are working on it?

Nikolay Nikolov wrote

> I think it depends if other people are working on it as well. How many people are working on it?

We don't and can't know that. At least 2 people have asked questions until now, at least.

Jonas