Assembly is important

Or you could just develop for a real platform =)

Don''t start flaming about this, it''s a topic perfect for that
Anyway, assembler can always be useful, but again and again, it all depends on what you develop. That''s all I had to say.

Having developed for GC and PS2, you most certainly have to use assembler for the PS2 but not the GC.

On the GC, you''ve got one CPU and one GPU. Writing games in C/C++ for the main CPU is fast enough to keep the GPU busy - there''s no advantage to using assembler and the special GC instructions are available as a C/C++ library.

However, on the PS2 you''ve got one CPU, the EE, two vector units, VU0 and VU1 and the GPU. The CPU cannot directly control the GPU the way the GC works. The CPU builds DMA lists which are then processed by the DMA manager. The DMA manager reads the DMA list and sends the data in the list to the specified target: code to VU1 for execution, data to VU1, data to GPU (textures). Building these DMA chains is a tricky business, you have to ensure that when the VU1 is sending triangle data to the GPU that the DMA has finished uploading the required textures. Getting the GPU and VU1 running efficently (i.e. as near to 100% as possible) is the tricky bit. The CPU is fast enough that these DMA chains can be built using C/C++.

The real headache comes from writing the VU1 code. The vector units are similar: they both have 8/16K code/data space. VU0 is tied to the CPU and can act as either a co-processor or a stand alone processor. VU1 is connected to the DMA and VU0 (VU0 can control / send data to VU1). Both vector units are VLIW based and issue two instructions per cycle, an upper and lower instruction. This is not optional, you have to issue two instructions. There are no safety nets with the units - issue a multiply instruction too soon and the unit stops working. You need to understand the architecture and the timings for all instructions (set-up and through-put times). As timings are critical and space is a premium, assembler is the only method to use (not having a C compiler is a minor set back as well).

Getting Sony''s boast about 75 million polys per second is possible if all your model data can fit in VU1''s data space and all the transformation code fits in the code space and you don''t use any textures. It''d be a bit limited though.

In any case, you''re looking at up to 2% of the total code for the game being written in assembler. And like Pixel/Vertex shaders, VU1 modules are highly reusable.

Skizz

I have been developing on PS2 for more than 3 years.

Even in graphic engine, C++ code is much more than
asm code.

The fact on PS2 is,
C++ or C code organize the render pipe, and
VU1 asm do the low level thing.

And for the GameCube,
asm code is almost unnecessary.

GC gives a much more high level graphic API than
PS2 does.


[edited by - law_zou on March 24, 2003 2:19:21 AM]

Skizz: Thanks for giving us such an insider''s view on the PS2, I had no idea how it worked on the inside :D

Join the World Wide Revolution:

Skizz:
I use SONY VCL compiler to compile VU code.
The VCL language is a macro language in which
you can define variables and let the compiler
arrange instruction for you.
It''s very productive, you may try it.