@cdimauro

Quote:

@Heimdall: good luck with PowerPC! This architecture is really terrible for developers which want to code in assembly. It has HUNDREADS of instructions, with very very poor mnemonics to remember. Something to get crazy!

I browsed through two PDFs so far, and it doesn't appear to be as bad as people usually say.

Besides, this is not my first RISC rodeo. And while Jaguar's RISC instruction set is smaller, it more than sufficiently compensates by being, basically, pre-alpha version of the silicon (but as a final release HW).

Which meant a lot of HW bugs. No, the Atari's manual doesn't list all of them. I discovered more than double HW bugs over the years - all kinds of combinations of instructions wreaking havoc on the RISC pipeline, results from previous ops being overwritten by different op (even though the processor manual says that the HW has provisions for that and that it shouldn't happen - yet it does - but very subtly - only for certain combination of ops - which is way worse than if it happened all the time - because then you'd find out immediately).

Trust me, that's easily an order of magnitude more hair-pulling than just understanding some mnemonics.

When all you have to do to break your RISC code is to insert one NOP, it is extremely frustrating.
And of course, there was no debugging as that HW was not available to buy these days, so you're basically debugging completely blindly, which takes 10x more effort than via gdb...

@matthey

Quote:

PowerPC is the most acronym purgatory outside of the US military but maybe he can reskin the mnemonics with his Higgs compiler.

That's the idea with the Higgs - I will create one set of RISC ops for each high-level command (conditions, loops, expressions) and Higgs will then take care of it, forever.

The performance-critical loops (I know very well which ones from my benchmarks) will be, however, written in straight ASM.


Quote:

At least the PowerPC Compiler Writer's Guide is helpful. I learned a few things from it and not just to avoid PPC.

It's an amazing document, indeed! I wish I had such document for the RISC DSP/GPU for Jaguar !

But, without Jaguar's HW bugs, the PowerPC code will just straight execute! That's, like, kindergarten level compared to Atari

@Heimdall

Quote:

Heimdall wrote: @cdimauro Quote: @Heimdall: good luck with PowerPC! This architecture is really terrible for developers which want to code in assembly. It has HUNDREADS of instructions, with very very poor mnemonics to remember. Something to get crazy! I browsed through two PDFs so far, and it doesn't appear to be as bad as people usually say.

If you limit yourself to a common, small set of instructions, then it's easy. You implement it on your compiler, and then you forget this burden.
Quote:

Besides, this is not my first RISC rodeo. And while Jaguar's RISC instruction set is smaller, it more than sufficiently compensates by being, basically, pre-alpha version of the silicon (but as a final release HW). Which meant a lot of HW bugs. No, the Atari's manual doesn't list all of them. I discovered more than double HW bugs over the years - all kinds of combinations of instructions wreaking havoc on the RISC pipeline, results from previous ops being overwritten by different op (even though the processor manual says that the HW has provisions for that and that it shouldn't happen - yet it does - but very subtly - only for certain combination of ops - which is way worse than if it happened all the time - because then you'd find out immediately). Trust me, that's easily an order of magnitude more hair-pulling than just understanding some mnemonics. When all you have to do to break your RISC code is to insert one NOP, it is extremely frustrating.

Those were bugs. Which might happen with early products, which went to market without good testing.
Quote:

And of course, there was no debugging as that HW was not available to buy these days, so you're basically debugging completely blindly, which takes 10x more effort than via gdb...

Like the "good, old times": when I developed my games, I only had the "Copper bars" and some on-screen debugging information trying to understand what the hell was happening.

@cdimauro

Quote:

cdimauro wrote: but you first need to understand all such instructions and mnemonics. Which is a big pain...

Big Pain ? Really ?!?

I just checked the mpc603e.pdf and all I see is the same-old group of ops, like on other processors that I already coded in ASM for (6502, 68000, RISC DSP/GPU, 80286-80586, Z80):

General-Purpose Group:
- load (8/16/32 bit)
- store (8/16/32 bit)
- branch/compare/trap

Integer Math Group:
- add/sub/mul/div
- and/or/xor/ext
- shift/rotate

I see only few other new [to me] groups there:
- processor / external control
- segment register / lookaside buffer / cache management

I can see endianness being an issue to silently trip me up during debugging, because I did, after all, spent majority of my life working with a different one...

@cdimauro

Quote:

If you limit yourself to a common, small set of instructions, then it's easy. You implement it on your compiler, and then you forget this burden.

I don't think it's a "small" set of instructions (the general purpose and integer math group). I'm only discarding floating-point ops, because I went to great lengths to make my engine fully integer (fixed-point) - based.
But, yes. I will only need to implement most high-level commands once.

There will, however, be about 4-8 weeks of pure ASM coding for the innermost loops of the rasterizer (the scanline loop), as that's where ~85% of performance/framerate is.
I already wrote that for RISC DSP, so I have a pretty good idea of that effort.

Besides, without HW bugs of Jaguar, it should just work, anyway...



Quote:

Those were bugs. Which might happen with early products, which went to market without good testing.

Yeah, Atari was already going down the drain, so it resorted to shipping a pre-alpha chip (it "worked") when it ran out of money.
Now, to their credit, they did have a dev-kit, that allowed you to debug/step through the DSP/GPU RISC code, instruction by instruction.
So, for official coders in 1992, it wasn't nearly as horrendous as today.



Quote:

Like the "good, old times": when I developed my games, I only had the "Copper bars" and some on-screen debugging information trying to understand what the hell was happening.

Well, You can't really compare debugging on 68000 where you have, basically, unlimited memory (compared to the Jaguar's 4 KB RISC cache).
Only a very small amount of RISC code fits within its 4 KB, thus you can debug and test small blocks/functions.
A number printing set of functions can take anywhere from 800-1600 Bytes, so you can debug in detail (via printing) around 2-3 KB of code.

But what do you do when you merge everything and have 16-32 Bytes left (no RAM for printing or drawing) and it's not suddenly working ? That's a doozy

Emulators are completely useless, because they are utterly naive and expect the RISC code to just execute flawlessly - meaning if you store value #32 in register R1, it should just be there, right ? Yeah, right

@Heimdall

Quote:

Heimdall wrote: @cdimauro Quote: cdimauro wrote: but you first need to understand all such instructions and mnemonics. Which is a big pain... Big Pain ? Really ?!? I just checked the mpc603e.pdf and all I see is the same-old group of ops, like on other processors that I already coded in ASM for (6502, 68000, RISC DSP/GPU, 80286-80586, Z80): General-Purpose Group: - load (8/16/32 bit) - store (8/16/32 bit) - branch/compare/trap Integer Math Group: - add/sub/mul/div - and/or/xor/ext - shift/rotate I see only few other new [to me] groups there: - processor / external control - segment register / lookaside buffer / cache management I can see endianness being an issue to silently trip me up during debugging, because I did, after all, spent majority of my life working with a different one...

If you take a look at the OpenPOWER ISA 3.1 document you'll see that there are much more instructions for the same that you've listed above.

For example, you have not a single add, but several of them: addi, addis, addpcis, add, add. addo, addo., addc, addc., addco, addco., adde, adde. addeo, addeo., addme, addme. addmeo, addmeo., addze, addze., addzeo, addzeo., addex, plus some "prefixed" versions. And that's only for the fixed-point/integer data type.
Quote:

Heimdall wrote: @cdimauro Quote: If you limit yourself to a common, small set of instructions, then it's easy. You implement it on your compiler, and then you forget this burden. I don't think it's a "small" set of instructions (the general purpose and integer math group). I'm only discarding floating-point ops, because I went to great lengths to make my engine fully integer (fixed-point) - based.

See above.
Quote:

But, yes. I will only need to implement most high-level commands once. There will, however, be about 4-8 weeks of pure ASM coding for the innermost loops of the rasterizer (the scanline loop), as that's where ~85% of performance/framerate is.

OK, so you have an hybrid approach: you mostly use your high-level compiler but some parts are still in assembly (which makes sense, due to the poor hardware resources available, that need to be squeezed).
Quote:

I already wrote that for RISC DSP, so I have a pretty good idea of that effort.

I don't know the Jaguar's DSP, but probably it has less instructions compared to PowerPCs. But they can be more specialized (e.g.: more difficult to use for an high-level compiler).
Quote:

Quote: Like the "good, old times": when I developed my games, I only had the "Copper bars" and some on-screen debugging information trying to understand what the hell was happening. Well, You can't really compare debugging on 68000 where you have, basically, unlimited memory (compared to the Jaguar's 4 KB RISC cache). Only a very small amount of RISC code fits within its 4 KB, thus you can debug and test small blocks/functions. A number printing set of functions can take anywhere from 800-1600 Bytes, so you can debug in detail (via printing) around 2-3 KB of code. But what do you do when you merge everything and have 16-32 Bytes left (no RAM for printing or drawing) and it's not suddenly working ? That's a doozy Emulators are completely useless, because they are utterly naive and expect the RISC code to just execute flawlessly - meaning if you store value #32 in register R1, it should just be there, right ? Yeah, right

Bugs...

I had a similar experience some years ago, programming an Arduino based on Atmel AVR (8-bit) microcontroller. With just 2.5kB of RAM and three LEDs it was a nightmare to debug the issues which popped-up.

Fortunately I've used Python to prototype (and test -> unit test) the most important part of the code, and then I've translated it to C.

I've also written part of the Arduino & Atmel libraries to actually "emulate" many things of the board, that allowed me to create some hundreds of unit-tests which I've easily executed on Visual Studio.

Without those "tricks" (well... experience) it would have been much much worse develop that project.

@cdimauro

The mnemonics are many but it follows a pattern of having a mnemonic for every imaginable variation of the basic addition opcode.

Even on 68K, thanks to assemblers understanding the context we forget that we also have specific mnemonics for adding immediates, adding to address registers, etc as well as using a dot extension for the size. On PPC, all the variations are just part of the opcode name. It's very tedious.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro The mnemonics are many but it follows a pattern of having a mnemonic for every imaginable variation of the basic addition opcode. Even on 68K, thanks to assemblers understanding the context we forget that we also have specific mnemonics for adding immediates, adding to address registers, etc as well as using a dot extension for the size. On PPC, all the variations are just part of the opcode name. It's very tedious.

Indeed, but even taking into account the patterns for PowerPC, 68k has only ADD, ADDI, ADDX, ADDX, ADDQ and maybe we can put ABCD.

@ppcamiga1

insane..

cdimauro Quote:

Indeed, but even taking into account the patterns for PowerPC, 68k has only ADD, ADDI, ADDX, ADDX, ADDQ and maybe we can put ABCD.

You forgot some POWER ISA ADD encodings, especially if counting BCD.

addic, addg6s (BCD), dadd (BCD)

POWER is a good example of a load/store architecture that is not a Reduced Instruction Set Computer (RISC). The POWER ISA is so big that fixed length 32-bit encodings were not enough so they added a 64-bit encoding and turned it into a very bad code density 32-bit VLE. ARM64/AArch64 is also a 32-bit fixed length load/store architecture that is far from a RISC with a large ISA and growing. Will they follow POWER into creating a 32-bit VLE when they run out of encoding space too?