MIPS Assembler Syntax

General Programming help in C, C++ or ASM, Compiling / Debugging, and R3000A Central Processing Unit (CPU) information
Post Reply
User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

MIPS Assembler Syntax

Post by nocash » February 6th, 2014, 1:15 pm

I am just adding support for the native/official MIPS assembler syntax in no$psx (the built-in assembler allows to change single opcodes in the debugger, and does also allow to build normal source code). To make it user-friendly, I need to know some details about the offical syntax and/or about common dialects.

Hex numbers are currently prefixed by a "$" symbol (eg. "addiu r2,r3,$123"). I am quite sure that I've seen that notation in offical MIPS datasheets (or at least in some source code). But a while ago, somebody told me that there would be something wrong with using "$" for PSX hex numbers. Is that true? If yes, what other notation is used? Something like "0x"? Or even "#0x"?

Memory addressing for load/store commands should be officially done as "$123(r4)". With round brackets, and without "+" or comma between immediate and register. I could implement it that way. But it's a bit hard to believe that that syntax is used in practice, or is it really used as so?

Pseudo instructions. I know only few: NOP, LA, LI, LW, SUBI, SUBIU. Are there more such pseudo instructions?

Ah, and, I have heard about something called "SW Rd,imm". Ie. unlike normal SW only with "imm" instead of "imm(Rn)", and with imm being allowed to be 32bit wide. It's done by using LUI R1, followed by the actual store opcode. The problem is that is is destroying R1 behind your back. But if that widely accepted (is it?) then I could implement it.

Abbreviations. Are there any abbreviations? Like "(Rn)" instead of "$000(Rn)"? Or like omitting some parameters (eg. if source and destination registers are same, as in "add r4,r4,$123")?

Directives. What's commonly used here? I assume there's some sort of "org" and "end" keywords? Something to define 8bit/16bit/32bit data (like "db" or "defb" or whatever for 8bit values)? And any more?
EDIT: Nope, there seems to be no "end" directive (at least spasm doesn't need/use such a thing at end of file).

The way how I've currently implemented the assembler syntax is same as shown in no$psx disassembler (when selecting "native" syntax in the Debug setup page). You can download the debugger at http://nocash.emubase.de/psx.htm and see for yourself. Please let me know if some other syntax would be more common or more preferred!
Last edited by nocash on February 9th, 2014, 4:40 pm, edited 2 times in total.

AmiDog
Active PSXDEV User
Active PSXDEV User
Posts: 53
Joined: Sep 07, 2012

Post by AmiDog » February 6th, 2014, 9:15 pm

Well, I don't know what the official MIPS assembler syntax is supposed to look like, but since I've been using GCC (and thus GNU AS) since like forever, for both PPC, M68K, x86 and MIPS coding, I've gotten used to its syntax:

0xdeadbeef for a hex value
registers has prefix $
lw $4,0x0000($3) for a hex offset
lw $4,0($3) for a decimal offset

Since $at ($r1) is reserved as "assembler temp", the assembler will usually not allow directly using it, so that's not really an issue most of the time. With the gnu assembler you need to use the ".set noat" keyword to prevent the assembler from using $at for itself and thus allow you to use it.

As for pseudoinstructions, MOVE and BRA (branch always) would be usefull.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 7th, 2014, 3:09 am

AmiDog wrote:0xdeadbeef for a hex value
Okay, no problem. Just for curiosity: Does/did anybody else ever use $deadbeaf instead of 0xdeadbeef?
AmiDog wrote:registers has prefix $
lw $4,0x0000($3) for a hex offset
lw $4,0($3) for a decimal offset
Since $at ($r1) is...
Whoops, $ as register prefix? That comes completely unexpected, but should be easy to implement.
Except that... $4 and $3 are also registers? And which ones? R4 and R3?
For example, R4 could be written as "$4" and "$r4" and "$a0"?

EDIT: I've checked where I got those "$hex" stuff from: It was used in "printgpu.asm" (;GPU print example. 1999 doomed/padua ;-syntax of spasm). That file is using opcodes like "lui a0, $0800". Unfortunately, when dealing with both syntaxes, "$a0" could be either hex A0, or register A0.
In datasheets, IDT is referring to registers as R1..R31, and MIPS as $1..$31. Maybe I'll need to implement both variants, selected via disassembler options, or assembler directives.
AmiDog wrote:reserved as "assembler temp", the assembler will usually not allow directly using it, so that's not really an issue most of the time. With the gnu assembler you need to use the ".set noat" keyword to prevent the assembler from using $at for itself and thus allow you to use it.
Good to know. If the assembler doesn't allow to use R1 in source code then I feel much better with pseudo opcodes that are destroying that register.
AmiDog wrote:As for pseudoinstructions, MOVE and BRA (branch always) would be usefull.
Okay...
"BRA dest" should be "BLEZ R0,dest"?
"MOVE" should be some add/or/shift opcode? And what would it do - "MOVE reg,reg" or "MOVE reg,imm16bit" or both?

Oh, and some more questions...

JALR opcode: Some docs specify it as "JALR RS,RD" and some as "JALR RD,RS". So different assemblers might interprete it this or that way around, making it some sort of a timebomb. Is there some solution for that problem? In most cases one could probably just use "JALR RS" (and default to RD=RA).

Coprocessor opcodes: There are 32 "data" registers, and 32 "control" registers for each coprocessor. As far as I understand, the opcodes do imply whether it's a "data" or "control" register. So writing K0 to control register 7 would be written as "mtc0 $k0,$r7" (ie. not as "$cr7", since the "c" for "control" is already implied in the "mtc0" opcode)?
EDIT: No, the "c" in "mtc0" is for "coprocessor", so it is a data register, not a control register, makes me wonder why I want to support official syntax at all.
And is common to use raw coprocessor register numbers, or something like "$cause", "$sr" for cop0, and "$mac0" for gte?

Branch delays: Is it always required to append a dummy NOP opcode after branches, or is there some (optional) feature to do that automatically? And if yes, is there some way to override it (in case one wants to store an opcode in the branch delay slot)?

Sample source code: is there some small ASM game/demo for PSX somewhere around? Something with pure asm source code (=without C code) would be nice.
Last edited by nocash on February 8th, 2014, 12:13 am, edited 1 time in total.

User avatar
Shendo
Verified
C Programming Expert
C Programming Expert
Posts: 250
Joined: Mar 21, 2012
I am a: Programmer
Motto: Never settle
PlayStation Model: SCPH-7502
Discord: ShendoXT
Location: Croatia, EU

Post by Shendo » February 7th, 2014, 6:26 am

nocash wrote: Sample source code: is there some small ASM game/demo for PSX somewhere around? Something with pure asm source code (=without C code) would be nice.
There are a few on Home of the Hitmen.
It Might Be NES emulator is pure asm also.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 7th, 2014, 11:23 am

Okay, thanks. Then there are at least five ASM projects/demos for PSX:
1) It Might Be NES
2) GreenTro
3) PrintGPU
4) RootCounterExample
5) Vblank
They are all using "$" for HEX numbers. Looks as if that syntax is more common for PSX.

Some more directives from nes.asm:
org n ;self-explaining (except that, it does also seem to imply load address and entrypoint)
align n ;self-explaining
db n ;define 8bit data
dh n ;define 16bit data
dw n ;define 32bit data (not 16bit data!)
dcb $2800,0 ;what the fuck? two 8bit values, one of them being bigger than FFh? or a zerofilled array with 2800h bytes???
xyz ;define label "xyz" at current address (without colon)
xyz = n ;assign value n to xyz
xyz equ n ;probably same as above
move v0,a1 ;that's the ONLY pseudo move opcode used in nes.asm
;xyz ;comments invoked with semicolon
incbin file.bin ;import binary file
include file.asm ;import asm file
zero ;alias for r0
btnCfgWaitNoButsDown ;hmmm, I remember using such labels before I got an assembler with local label support : - )

Btw. the nes.asm file is using both the "at" register and the "sw" pseudo opcode, so one can't trust that all assemblers would reject "at" as reserved register.

EDIT: spasm's DCB directive is actually used as "dcb number_of_bytes,fill_byte".
Ie. completely different as the "dcb data1(,data2(,data3(...)))" which is being used on ARM.
I really hope MIPS assemblers are soley using DCB in the spasm fashion. Or are there also MIPS assemblers that use it in ARM fashion?
Last edited by nocash on February 9th, 2014, 5:33 pm, edited 3 times in total.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 7th, 2014, 10:16 pm

Here's a bit more info on the spasm syntax: http://www.psxdev.net/forum/viewtopic.php?f=49&t=150
Pseudo opcodes that I had missed are "beqz", "bnez", "bal" (purpose looks obvious, except that I've no idea what exact binary encoding they were using for it, for example "beqz" could be "beq" with "r0" as 1st or 2nd operand).

EDIT: No not obvious. My first thought was BAL would be another form for "Branch ALways". But actually it seems to mean "Branch And Link always".

The above thread does also mention that - aside from gcc and spasm - there should be also a "Psy-Q assembler".
I guess that would be Sony's official assembler, right? Anybody knows what syntax it was using?

EDIT: For compilers, the hitmen page is listing separate Psy-Q source code and Yaroze source code. As far as I know, Yaroze is Sony's official homebrew devkit. And I was thinking that Psy-Q would be the official commericial devkit, is that right?
If yes, then I would expect Yaroze and Psy-Q to use the same assembler syntax? Or are they different? Or did Sony completely omit asm support in Yaroze?

EDIT2: This page http://wss.co.uk/pinknoise/psx/software.html says that Yaroze came with gcc/as - so there is at least something known about the yaroze syntax. Still no clue about Psy-Q syntax (except that above page says that PsyQt came with "professional... assembler(s?)... available to buy").
Last edited by nocash on February 8th, 2014, 4:53 pm, edited 2 times in total.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 8th, 2014, 1:11 am

Found two more asm files on the hitmen page. Allmods is PIC source code for modchips (hence not related to MIPS asm).
And "pad.s" contains some joypad routines. That file is a bit different than everything else known so far:
It uses "0x" for HEX values (but doesn't use "$" for registers).
It uses "#" instead of ";" for comments.
It uses ":" for labels (fortunately).
The assembler has at least one directive: ".byte" (equivalent to "db" on other assemblers).
This page http://ffhacktics.com/smf/index.php?topic=8408.0 is also using that 0x=HEX and #=comment stuff.
I've no clue which assembler was used for this source file... could that be the Psy-Q assembler?

User avatar
Shendo
Verified
C Programming Expert
C Programming Expert
Posts: 250
Joined: Mar 21, 2012
I am a: Programmer
Motto: Never settle
PlayStation Model: SCPH-7502
Discord: ShendoXT
Location: Croatia, EU

Post by Shendo » February 8th, 2014, 10:05 pm

You can grab PsyQ SDK from download page.
After you extract it you will find a SRC directory which has a bunch of C and ASM source code files.

Hopefully this should help as it's the official SDK Sony used.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 9th, 2014, 6:44 am

That CD 2.2 file? Looks like a 3-4 hour download, a bit much for seeing some lines of source code, but I may try it.

I am just doing a big turn in the assembler implementation: I was originally removing all advances features from my own assembler syntax, assuming that the official syntax didn't support that stuff. But then, one after another, it has turned out that the existing source files do actually use all kinds of abbreviations:
* addu/subu/slt can be used for immediates (instead of addiu/subiu/sltu)
* probably same for or/xor/etc, and for srl/sll/sra
* destination register can be omitted if it's same as first source register
* (rs) can be used instead of "0(rs)"
So, I am about to delete half of the native syntax decoding that I've written in past some days, and instead pass the parameter interpreting to my old nocash syntax decoding. Could have saved a lot of time if I'd have already known about that features :-/

One new pseudo opcode popped up today: greentro uses "b resetpage" current theory is that it might be same as that "bra" pseudo instruction. It's coming shortly after one of instructions with immediate "288" (=0120h), so it should be possible to build the source with spasm, locate it in the binary, and find out how it is meant to be encoded.
EDIT: Found it. The "B dest" gets encoded as "BEQ r0,r0,dest" (an obvious choice for use on hardware, although "BLEZ R0,dest" should be more efficient; when keeping emulators in mind).
Still no info how "BRA" and "BAL" should be encoded?

About MOVE: As by now, it does seem to be used solely for register operands (loading immediates, in 32bit form and various 16bit forms, appears to be solely done by LI) (or LA, but that appears to be used only for 32bit addresses).

Amok. Found this in It Might Be NES: "sw v0,$DFFC(at)" is that permitted??? Encoding a negative offset as positive value in source code??? The file also does that for additions: "addiu v0,v0,$DFAC" where $DFAC is apparently meant to be a short form for adding FFFFDFACh, weird.

The main issue is that spasm doesn't support any range checks (can be also seen in "db" data lines with 32bit values). The other issue is that some disassemblers might actually display 16bit values without sign-extension; it does look as if the nes.asm author has copied such crippled disassembler output into the source code. Is that common for MIPS programmers? If yes, I could disable any kind of range checks for native syntax, and just let you do what you want.

More issues in nes.asm:
lw v0,$1074(v1) // this line would be at $DFAC where the jump goes from the patch
lw v0,$DFFC(v0) load the address to jump back to that was set in _patch_card
What's that? After a close bracket, one can append comments without ";" ???
Last edited by nocash on February 9th, 2014, 5:20 pm, edited 2 times in total.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 9th, 2014, 8:32 am

EXE Headers: Is there some standard on whether and how to autocreate PSX-EXE headers? The spasm assembler is doing it automatically (unfortunately it cannot be enabled/disasbled via directives, only via command line switch). Downside for automatically generated headers is that's difficult to assign things like custom stacktop, entrypoint, region string, etc.

Surreal Headers: The spasm assembler is actually creating a corrupted header (with the size entry not being aligned by 800h). The kernel's A(60h) dev_cd_read function is definetely refusing to load such files, so there's no chance that those spasm exe files could have ever worked on real hardware (nor in emulators). Makes me wonder if they have ever noticed that it didn't work. I am getting a bit bewildered about the psx asm scene.
Probably they have used Caetla (or Yaroze or ActionReplay or Xploder) to test their exe files on 'real' hardware; I wouldn't be surprised if they complained about 'inaccurate' emulators that couldn't load their corrupted files ;-)
Last edited by nocash on February 9th, 2014, 9:12 am, edited 2 times in total.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 9th, 2014, 9:01 am

Another crazy feature: From the Sys2.asm file in PrintGPU package, apparently inspired on 6502 syntax:
lui at,>mvl1
sw a1,<mvl1(at)
sw a2,<mvl2(at)
which would need to be interpreted as so:
>imm = (imm-(imm AND 8000h))/10000h
<imm = (imm FFFFh)
However, a few lines later it's doing this:
lui a0,>mvl
jal SendList
ori a0,a0,<mvl
that would need to be interpreted as so:
>imm = (imm)/10000h
<imm = (imm FFFFh)
so obviously, either one can't work (or it would work only for 'small' immediates in xxxx0000h..xxxx7FFFh range, but not for immediates in xxxx8000h..xxxxFFFFh range).
I got told that this particular syntax isn't common in MIPS world. So please don't think about using it.
Last edited by nocash on February 9th, 2014, 4:11 pm, edited 1 time in total.

User avatar
Shendo
Verified
C Programming Expert
C Programming Expert
Posts: 250
Joined: Mar 21, 2012
I am a: Programmer
Motto: Never settle
PlayStation Model: SCPH-7502
Discord: ShendoXT
Location: Croatia, EU

Post by Shendo » February 9th, 2014, 9:25 am

nocash wrote: Surreal Headers: The spasm assembler is actually creating a corrupted header (with the size entry not being aligned by 800h). The kernel's A(60h) dev_cd_read function is definetely refusing to load such files, so there's no chance that those spasm exe files could have ever worked on real hardware (nor in emulators). Makes me wonder if they have ever noticed that it didn't work. I am getting a bit bewildered about the psx asm scene.
Probably they have used Caetla (or Yaroze or ActionReplay or Xploder) to test their exe files on 'real' hardware; I wouldn't be surprised if they complained about 'inaccurate' emulators that couldn't load their corrupted files ;-)
It's a known issue. There is a utility called exefixup which addresses this shortcoming.
I've used it in the past when I was programming using Blade's libs, fortunately Tail92's PSXSDK ELF2EXE does it right.
I believe they used Jihad/Hitmen serial upload application which will run those bogus EXEs.
---
PSXSDK is an open source SDK so you are free to browse files. There is assembler code also.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 9th, 2014, 10:52 am

Glad to know that somebody noticed and fixed the exe header bug!

And good to know about PSXSDK, didn't knew much about what & where it is... found at least two asm source files on the PSXSDK page:
http://code.google.com/p/psxsdk/source/ ... syscalls.s
http://code.google.com/p/psxsdk/source/ ... rc/start.s
They're using "#" for comments, ":" for labels, and "0x" for hex (all as in pad.s).
But unlike other source files, they are using $9 and $a0 for registers instead of for hexadecimal immediates.
There are also some more directives: .text .align .global .word .string
Like pad.s and spasm files it does end without "end" directive (so that seems to be common in MIPS world).

That PsyQ CD2.2, is an ISO file? Okay, for people in PSX scene, a tool for extracting files from ISOs is probably an absolute must-have (only I don't have one). Anyways, if there aren't any other PsyQ source files around, then it's probably not really worth to know its syntax :-)
Though it would be slightly interesting to know what kind of syntax the commercial devrs have been using back then.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 9th, 2014, 3:56 pm

I have found a 01020215.ASM file with PsyQ source code...
Registers are called "a0", "t3", etc. and oddly: "AT" in uppercase.
Hex numbers are preceeded by "0x".
Labels are defined with ":".
There is no "$" used, neither for registers nor hex numbers.
Comments are very uncommon: starting with "/*" and ending with "*/" the end marker can be located in the current line, or anywhere in one of following lines (I think C programmers are doing the same way... or somehow similar, but it's rather uncommon in asm).
There is at least one directive that starts with "#" ("#include <filename.h>"; with name enclosed in "<" and ">"), some of the other MIPS assemblers would ignore that and treat it as "#comment string", or maybe even as "#label1 label2" (in case they do allow labels without colons, and don't throw warnings on chars like "#" and "<" used in label names).
I haven't spotted any abbreviations that have Rd omitted.
But it's using "sll" and "srl" for immediates and registers (registers would be normally using "sllv" and "srlv").
And it's occassionally using "(Rs)" as shortform for "0(Rs)", eg. "lwc2 C2_VXY1,(t5)". That's a bit nasty when decoding the string from left to right: an open "(" bracket could occur for "(Rs)" or for stuff like "(imm+5)*2(Rs)" (not that I would have seen such calculations in existing source code yet).
Alu stuff can also have the "i" omitted (eg. "and" instead of "andi" for immediates).
Directives are ".set noat" (the feature mentioned above), and ".set at" (to undo it), ".set noreorder" and ".set reorder", ".text", and ".globl label" (probably similar as ".global" in psxsdk, but without "a" in ".globl"). NB. these directives are invoked via "." unlike as the "#include" one.
Coprocessor opcodes are half as expected (and other half: still unclear).
For example, it uses "mtc2 v0,C2_SZ0", with "C2_SZ0" being the desitnation register, ie. a GTE coprocessor data register (whereas "C2_SZ0" is probably defined in one of the include files, ie. the raw assembler might expect something like "r0..r31" or maybe "dr0..dr31" or whatever instead of "C2_xxx" symbols).
Actual GTE 'commands' are invoked with keywords like "NCLIP" (which is probably also something from an include file, ie. the raw assembler might expect something like "cop2 imm25" instead).
The actual include files seem to be missing (maybe they were held to be located in a different folder than the .ASM file), so it's unclear what notation they have used (maybe something like "equ"... or maybe "#include" was specifically for including C-style header files (not for including ASM files), so they might even contain "non-asm-directives", like "#define" or so).
The 01020215.ASM file doesn't contain data fields... anybody knows if and how PsyQ has allowed to define data within .ASM files?

isufje
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 64
Joined: Apr 11, 2012

Post by isufje » February 9th, 2014, 5:41 pm

Do u have a PDF viewer? I don't know ASM, but i found this PSY-Q Doc that has a lot of ASM banter. It's all gibberish to me, but maybe you can understand it. I think it has examples of all C and ASM equivalents.

Honestly, i was gonna learn ASM until i found out C was enough.
Image


here's the link to the DOC
https://www.dropbox.com/s/go94g1ob9bcn5n3/PSYQ2.PDF

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 9th, 2014, 6:20 pm

Hmmm, so essentially, that pdf says "it is not necessary to learn the intricacies of R3000 assembler"? Okay... great, that's somehow making this whole topic irrelevant ; - )

Anyways, I found some PsyQ include files, one of them is called "asm.h", so I am quite certain that they are ASM includes files, not C ones.
The files are actually using "#define".
For registers: "#define R0 $0" and "#define zero $0", so the raw assembler does NOT understand "R0" or "zero", only the "$" stuff.
For coprocessor registers: "#define C2_VXY0 R0" (data register) and "#define C2_R11R12 R0" (control register), so the plain assembler is just using "R0..R31" for both data registers and control registers. Whereas, "R0..R31" are probably derived from the above "#define R0 $0" definition. So, in reality, it does use $0..$31 for everything (cpu registers, copro data regs, and copro control regs). In turn, those #define's would also allow to access coprocessor registers by improper aliases like "ra".
Coprocessor commands like "NCLIP" are simply manually encoded as ".word 0x0000117f" instead of using anything like "cop2 imm25". Some of those definitions include parameters, eg. "MVMVA(sf,mx,v,cv,lm)" gets encoded as ".word 0x000013bf|sf<<25|mx<<23|v<<21|cv<<19|lm<<18".
That does also give a hint on data definitions: obviously ".word" for 32bit data (and probably, something like ".byte" or ".char" for 8bit data, and ".whoknowswhat" for 16bit data).
But there is one mystery: "NCLIP" should be encoded as "COP2 1400006h" aka ".word 0x4B400006", not as ".word 0x0000117f" (which has primary opcode=00h, and secondary=3Fh, which isn't a valid instruction at all). I can't see how that could work... unless the debug version did intentionally trigger invalid opcode exceptions for simulating (and maybe logging) GTE commands.
Some of the PsyQ include files are also using directives "#if", "#ifndef", "#else", "#endif".

PS. Thanks, that PSYQ2.PDF file contains info about a LOT more directives like DB, DH, INCLUDE, EQU, IF, ELSE, etc. (in this case, without "#" or "." prefixes). I am unsure why it is like that... maybe the assembler actually supported both ".if" and "IF", or "IF" has been some sort of macro, or the .asm files were using a completely different assembler as described in the .pdf file (??)
It does also contain some ASM snippets that do more or less resemble the code in the 01020215.ASM file that I've seen, except that most of those snippets are mixed with macros, directives, and macro operands, which makes it hard to see what is real asm, and what isn't.

PPS. Also from your screenshot (not from the PSYQ2.PDF), this sentence made me laugh:
"Interrupt control in the R3000 is said to be complicated, but the Playstation OS uses a substitute "dispatcher" system which has a simple interface. The dispatcher's overhead is kept very low, and it provides low-level support not available in ordinary operating systems."
The PSX definetly doesn't have ordinary interrupt handling ; - )
The expert info about interrupt control being complicated must have come directly from Sony's lead programmer ; - )

And it's getting even funnier: "the PlayStation OS was designed so that its RAM usage (64K bytes) and use of the CPU are kept to a minimum."
From my own finding's: PSX memcpy takes circa 160 cycles per byte (reasonable would be less than 4 cycles), and bzero takes circa 105 cycles per byte (reasonable would be less than 1 cycles). Maybe they meant that the OS left only a minimum of available CPU time to tasks. But well, they have certainly avoided to "to learn the intricacies of R3000 assembler" ; - )
Also neat: To achieve greater speed, the PlayStation OS doesn't carry out many checks of prohibited items that other operating systems would. I wonder which other OSes were doing that checks. DOS? Win95? Looks more like telling: If the kernel crashes, then it is just because the PSX is so fast.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests