forums.ps2dev.org

ooPo wrote:Don't let their unofficial status fool you, though. Compared to other unofficial ports the PS2 patches are very top notch and full of good work.

J.F. wrote:The EE runs "normal" 64bit MIPS little-endian code

/* An array describing how BFD machines relate to one another.  The entries
   are ordered topologically with MIPS I extensions listed last.  */

static const struct mips_mach_extension mips_mach_extensions[] = {
[...]
  { bfd_mach_mips5900, bfd_mach_mips4000 },

• You (the developer) write source code in your favorite high-level language. This can be C, C++, Prolog, whatever. High level languages are nice because it's easy to say something like "x = r * cos(theta)" -- which usually turns into a lot of machine code -- in a machine-independent fashion. The same *source* code will work on a i386, mips5900, whatever.
• The compiler takes your high-level source code, and generates a machine-specific object file. So the compiler is by definition, specific to a specific language (C) and architecture (mips5900). (Some compilers emit assembly language as a separate step, then feed that through an assembler.) In any event, the result is a relocatable object file, in the PS2 world, these are .o files. It is not an executable file, as there are unresolved symbols: the startup code, all of the standard library functions (e.g., printf), etc.
• The linker takes your object files, combines them together with any needed library files (libraries are really just collections of object files), and generates an executable object file, sometimes called a binary file. In PS2DEV vernacular, this is an "ELF file" for the EE (this is a misnomer, since the .o files are also ELF files, just not executables); the executable for the IOP is an "IRX file." Note that on some platforms (e.g., Win32 and Linux), there can still be unresolved symbols here that get resolved at run-time by shared object libraries or DLLs, but we don't have that wrinkle on the PS2.
• Somehow, your binary gets loaded into the computer's memory via a loader -- this is ps2link, naplink, etc. on the PS2; it's a shell or similar on most other OSs. The loader passes control off to the whatever location in memory your binary says is the start location, and away it goes.

• your program calls printf()
• printf() is in the standard C library, which does a bunch of things, but eventually calls the write() system call. (A system call is the interface between a user-mode program and the OS kernel).
• The OS kernel gets the write() system call, and determines what kind of device you're writing to. It passes the data you're writing to the appropriate device driver, which may be built into the kernel, or a loadable module
• The device driver does whatever it needs to do for the underlying hardware. For example, the console device driver displays output on the screen.

pixel wrote:Hum, I won't argue really more on this, since the documentation and the sources are not agreeing together. On the code point of view, r4k series is mips64 (that is, is on the mips3 abi), but all the other mips docs says it sits on the mips2 abi, and thus, is mips32. I was confused by seeing that, on the code point of view, the r5900 is considered as a r4k, which is (in the official docs) a mips32.

Something's wrong here :) Does r4k processors really support 64-bits operations ? Or is binutils plain wrong putting r4k processors on level 3 abis, since the official mips docs says r4k is on level 2 ? Anyway, binutils says r4k is level 3, and we are placing r5900 on the same level as r4k.

Well, anyway, for me, this is getting commercial-talk-bullshit :)

soks wrote:And a question on firmware-ish stuff, I was told parts of processors are programmable just like those programmable-IC's, any clerification as to whether this is normal and why it's used?

Hell while I'm at it, on a PC the OS uses the BIOS to get stuff going correct? Is the PS2-hardware-kernel thingy comparable to a BIOS?

gorim wrote:For the IOP, should it really be correct behavior that the linking stage produces an IRX file by default rather than a normal ELF ?

I fully understand that in most ps2dev situations what we want is IRX, but if this can be done as a separate independant action performed after linking, then this oddity can be separated out and make the toolchain more generic, and removes an implicit assumption. Someone might want to run a normal elf rather than IRX on the iop. :)

I just think IRX is too (iop kernel) OS specific to be a default part of the gnu portion of the toolchain. The more that stuff is separated out, if it can be easily done so, the more the whole gnu toolchain can be in a state that it isn't considered "hacked up" and could potentially be a candidate for inclusion into the main GCC/binutils distribution.

And within a makefile, its not difficult to run elf2irx after a build.

....