PDA

View Full Version : Leveraging Vector Pascal for a PS2 port???



savage
02-10-2006, 12:28 PM
Hi Guys,
I can't remember if I pointed out that the guys over @ Glasgow Uni created an open Source compiler called Vector Pascal. Would it be possible leverage some of the work they have done to add a Vector back-end to FreePascal, because they ported VP to the PS2.

There is a 100+ page document about how they ported VP over to the PS2 and you can read it here....
http://www.dcs.gla.ac.uk/~wpc/reports/compilers/compilerindex/PS2.pdf

I hope someone from the FreePascal team reads this.

dmantione
02-10-2006, 01:30 PM
This sounds doable. The compiler already contains code to do vector operations using MMX, i.e. the code to multiply arrays is there. This can be reused for such a port.

The PS2 uses a MIPS processor, but the compiler has no MIPS code generator yet. It should be straightforward to implement one. The MIPS is a very regular processor so should generally be easy, the only obstacle might be the lack of flags.

Basically all that is needed is someone with plenty of spare time :)

WILL
02-10-2006, 10:55 PM
Do you think that Florian would be willing to push MIPS forward on the Development Roadmap at this point? It's been on the development tree for ages and there is still that request to add ARM7/9 THUMB instructions aswell.

But then again, if the FPC team had a game dev advocate in it's ranks (*ahem* Mr. Mantione *ahem*) they would be quite influential.

The two major benifits of course would be, first; attracting new game dev'ers into the Pascal 'fold', and second; cultivating new avenues of interest with this and similar communities already in existance.

But would Pascal coders using Vector Pascal together with FPC be able to get the same or 'close to' results as what we seem from professional quality games?

JernejL
03-10-2006, 07:44 AM
i have a older mips windows ce 2.0 handheld that i wanted to reprogramm, i talked to #fpc guys about mips support and they said they have no mips hardware..

dmantione
03-10-2006, 09:45 AM
Well, Florian has said in the past he has no interrest to work on MIPS support. Of course, if anyone is actively working on something, the team will support such an effort, which is one reason why Florian is interrested in Thumb support. The fact that it hasn't happened until now is mainly that Florian has tons of things to do on the compiler. I'd say it is a matter of communicating that you are really waiting for it.

For the PS2/MIPS, someone has to start the project, and the team will be happy to do some work to support such an effort.

WILL
03-10-2006, 10:34 PM
The same scenario with GBA targeting support about a year ago...

This is a bit different as it's an entire CPU architecture, but like the GBA stuff if someone wants to gain support for platforms such as PSOne, PS2 and so on, there will have to be an individual or a team created for such an endevour.


Though... it might be a more productive task to find out and write up how one can add things to the compiler rather than to simply just stick to adding the one thing.

I mean once there is a set of documentation that tells exactly how one would go about adding to FPC, then it might make it far less difficult for new individuals that want to add some other thing(s) to it. So instead of seeing on PGD once a year, a new platform that someone wants to have support for yet noone has any time for it, you instead have a place where you can direct them to get the nessissary information to learn how to do it. That is provided that they are dedicated enough to commit to such a task.

This might even further promote more and more the trend of FPC as major option for multi-platform compilers.

Legolas
03-10-2006, 11:10 PM
The same scenario with GBA targeting support about a year ago...

This is a bit different as it's an entire CPU architecture, but like the GBA stuff if someone wants to gain support for platforms such as PSOne, PS2 and so on, there will have to be an individual or a team created for such an endevour.

WILL, you always are been superoptimist :D
With the gba we had to adapt a complete compiler and rtl by cutting down here and there. With mips we have only a partial support... too much work to do...
Coming from the gba experience, I can tell that it is very hard (read impossible) to find someone's help. It's even hard to get some feedback or bug reporting. If we had some help with gba, we would have ended the porting six months ago. Sad, but it's the truth :?


Though... it might be a more productive task to find out and write up how one can add things to the compiler rather than to simply just stick to adding the one thing.

I mean once there is a set of documentation that tells exactly how one would go about adding to FPC, then it might make it far less difficult for new individuals that want to add some other thing(s) to it. So instead of seeing on PGD once a year, a new platform that someone wants to have support for yet noone has any time for it, you instead have a place where you can direct them to get the nessissary information to learn how to do it. That is provided that they are dedicated enough to commit to such a task.

This might even further promote more and more the trend of FPC as major option for multi-platform compilers.

Definitely I agree! :thumbup: :clap:

WILL
04-10-2006, 03:26 AM
dmantione: Do you know enough about the innerworkings of FPC to be able to start such a set of docs that detail how one would go about adding a CPU architecture from scratch?

There is of course lots of present and future use for such a series of articles; MIPS (is the big one), PIC (the microcontrollers), Z80, ARM9, Dual Core/Hyperthreaded Pentiums, VIA's C7 (which is starting to gain popularity in it's own rights), Sony/Intel/HP next gen processors in the future?, etc and so on...

So if it really came down to getting any other of the FPC team interested enough to find relivence in helping you, there is plenty of it. Especially if they wish the compiler to carry on after they have done all they can or care to do to it.


As far as the GBA support goes, it took roughly a year to get support into the compiler. I think it would take less time if lessons learned from the GBA port where taken to this new port.

However, the guts of FPC are far from well documented. So this provides a challenge to those newcomers. Maybe some work in this area might kill many birds with a single stone?

dmantione
04-10-2006, 10:55 AM
Yes, I do have a deep understanding of the code generator.

First read this:

ftp://ftp.freepascal.org/pub/fpc/docs-pdf/comparch.pdf

It is outdated, but still a good read. If someone wants to start a MIPS port, contact me and I'll help you step by step.

A estimate a MIPS port will be between 150 and 200kb of code, assuming an external assembler and linker is available.

Legolas
04-10-2006, 12:06 PM
[quote="dmantione"]Yes, I do have a deep understanding of the code generator.

First read this:

ftp://ftp.freepascal.org/pub/fpc/docs-pdf/comparch.pdf

It is outdated, but still a good read. If someone wants to start a MIPS port, contact me and I'll help you step by step.

A estimate a MIPS port will be between 150 and 200kb of code, assuming an external assembler and ]

Whooops! 200kb of code!!! :D
And what about arm9? Maybe could it be only matter of extending arm7?

dmantione
04-10-2006, 01:01 PM
Excluding all automatically generated files, the ARM directory contains 297 kb of code. That is including an assembler reader, assembler writer and a backend for the internal assembler.

ARM9 should be a matter of extending the current ARM.

WILL
04-10-2006, 08:38 PM
I think I'll make another thread for adding ports to FPC in general so that we can keep this thread more PS2 specific as it was intended.


EDIT: I've created the new thread Adding New Ports to FPC (http://www.pascalgamedevelopment.com/viewtopic.php?p=25754#25754) to continue our conversation about other possible new ports.

VectorPascal
12-10-2006, 07:27 AM
This sounds doable. The compiler already contains code to do vector operations using MMX, i.e. the code to multiply arrays is there. This can be reused for such a port.

The PS2 uses a MIPS processor, but the compiler has no MIPS code generator yet. It should be straightforward to implement one. The MIPS is a very regular processor so should generally be easy, the only obstacle might be the lack of flags.

Basically all that is needed is someone with plenty of spare time :)
The port we did includes a code generator for the MIPS including the multi media extensions of the mips. The code generator can get VPU0 to operate as an attached processor, but we did not extend it fully to allow VPU0 and 1 to run independently fetching instructions from their own memory.

We hope to produce a port to the Cell next.

Here we will not be able to avoid the fact that the vector units have to fetch their own instructions.

The intended approach is to parameterise pascal Units with the processor onto which they are to be mounted. Thus one will specify that a particular unit foo is to be loaded onto attached processors 1..3. One can then call the procedure bar in foo with the syntax
foo[2].bar(x,y,z)
denoting, run procedure bar on processor 2

If one specifies that calls to apu s must use call by value semantics then copying of the parameters to the adderess space of the apu by dma should be possible.

A procedure in an apu would run in parallel with the calling environment.
A function call to an apu would cause the calling environment to wait for the return value.

The parallelism model would then be based on calling procedures on several apus to initiate tasks and then doing function calls to get the results of the calculations back.