Exophase
Nothing good will ever come of Exophase.
At first I wasn't that enthusiastic about a DSP, as second CPUs don't really get a lot of attention from homebrew devs on GP2X and PSP (more on DS though). However, after reading the documentation, this one looks like it may be so powerful that it could be useful even when not really running in parallel with the Cortex-A8, ie through blocking remote procedure calls.
Here's the link again (thanks to Laurent for originally posting it):
http://focus.ti.com/dsp/docs/dspsupporttec...ctName=spru732g
I read through it pretty completely, it's pretty well written/organized and for the most part easy to understand (unlike the Blackfin documentation -_-).
Pros:
- 8 instructions per cycle over 4x2 functional units. There is two of every type of unit, so almost every instruction can be paired per cycle at least 2x. Furthermore, a number of common operations are redundant over 2 or even 3 unit types (add, sub, or, and xor can be done on 3 unit types)
- 32x2 general purpose 32bit registers. Nominally each set is tied to a functional unit block, but there are "cross paths" for allowing a register from the other set to be used directly in an operation, you're just limited to how much you can do this per cycle. This huge amount of registers should help for making algorithms more parallel.
- Lots of bit crunching instructions (extracts, packs, interleave, reverse, etc)
- Predication (conditional execution over registers, like in ARM but with more direct boolean values, if you're familiar with PPC or Itanium they have the same mechanism) - useful for avoiding the very costly conditional branches.
- Can do 2 64bit loads or stores per cycle (unfortunately not 2 loads AND stores, but can do one of each). Actually, the 64x+ has 256bit paths to dcache but I'm not too sure why. 64bit loads/stores use register pairs.
- Can do unaligned loads/stores w/o additional cycle penalty (maybe this is why there are 256bit paths). Unfortunately you can only do one memory access per cycle if it's unaligned.
- There's a strictly one cycle fire-off/throughput rate for every functional unit, with stalls (nops generated by the CPU) only being inserted in a few situations.
- Has a mechanism for assisting software pipelining. I understand the principle but don't really get the implementation yet.
- Has circular buffer addressing, although I think that the base has to be aligned to the offset size, which seems a lot less useful to me...
- Single cycle decrement + branch instruction (these are great, I don't know why so many modern CPUs have stopped favoring them)
- 80KB of L1 dcache. I wish the Cortex-A8 had this, although it's only 2-way set associative here (probably optimized for a single input + output set). There's also 64KB of unified L2 cache and 32KB of L2 SRAM (I wonder how fast it is..)
Cons:
- The latency for loads is pretty terrible, at 4 cycles. Because of the 1 cycle throughput these are all "delay slots." Good scheduling/unrolling is going to need to be done to compensate for this.
- Naturally branches are pretty bad too, with delay slots of 5 cycles. There's no branch prediction or anything like that. This isn't really a problem with loops; for them it's much better that these slots are exposed than if compulsory stalls were introduced (like on ARM and MIPS w/o branch prediction or mispredictions)
- Although there's 32KB of L1 icache, it's direct mapped so it's really just good for running one piece of code at a time, for a long time. Not good if the OS interrupts it a lot, but this is what we have a general purpose CPU for.
- It's very bare metal, in that it won't protect you from doing a lot of things. You have to be really careful not to cause dependency problems or performing multiple writes to the same register during the same cycle (especially a danger for the many instructions that have multiple cycle latency).
- There are some weird bugs, that I hope get fixed at some point :/
Applications:
- Obviously it'll be used for video and hopefully audio decoding too. Hopefully there will be libraries or at least binaries available for everyone to use this freely.
- One thing that immediately comes to mind is using it to render scanlines for 2D emulators. It should be able to fire off rendered tiles in quite a few less clocks than the Cortex-A8, although it is clocked a bit lower (430MHz vs 600MHz.. I wonder where they got 430MHz, and if that's off a separate clock than the CPU... their greatest common multiple seems to be ~3GHz, divided by 5 and 7)
Here's the link again (thanks to Laurent for originally posting it):
http://focus.ti.com/dsp/docs/dspsupporttec...ctName=spru732g
I read through it pretty completely, it's pretty well written/organized and for the most part easy to understand (unlike the Blackfin documentation -_-).
Pros:
- 8 instructions per cycle over 4x2 functional units. There is two of every type of unit, so almost every instruction can be paired per cycle at least 2x. Furthermore, a number of common operations are redundant over 2 or even 3 unit types (add, sub, or, and xor can be done on 3 unit types)
- 32x2 general purpose 32bit registers. Nominally each set is tied to a functional unit block, but there are "cross paths" for allowing a register from the other set to be used directly in an operation, you're just limited to how much you can do this per cycle. This huge amount of registers should help for making algorithms more parallel.
- Lots of bit crunching instructions (extracts, packs, interleave, reverse, etc)
- Predication (conditional execution over registers, like in ARM but with more direct boolean values, if you're familiar with PPC or Itanium they have the same mechanism) - useful for avoiding the very costly conditional branches.
- Can do 2 64bit loads or stores per cycle (unfortunately not 2 loads AND stores, but can do one of each). Actually, the 64x+ has 256bit paths to dcache but I'm not too sure why. 64bit loads/stores use register pairs.
- Can do unaligned loads/stores w/o additional cycle penalty (maybe this is why there are 256bit paths). Unfortunately you can only do one memory access per cycle if it's unaligned.
- There's a strictly one cycle fire-off/throughput rate for every functional unit, with stalls (nops generated by the CPU) only being inserted in a few situations.
- Has a mechanism for assisting software pipelining. I understand the principle but don't really get the implementation yet.
- Has circular buffer addressing, although I think that the base has to be aligned to the offset size, which seems a lot less useful to me...
- Single cycle decrement + branch instruction (these are great, I don't know why so many modern CPUs have stopped favoring them)
- 80KB of L1 dcache. I wish the Cortex-A8 had this, although it's only 2-way set associative here (probably optimized for a single input + output set). There's also 64KB of unified L2 cache and 32KB of L2 SRAM (I wonder how fast it is..)
Cons:
- The latency for loads is pretty terrible, at 4 cycles. Because of the 1 cycle throughput these are all "delay slots." Good scheduling/unrolling is going to need to be done to compensate for this.
- Naturally branches are pretty bad too, with delay slots of 5 cycles. There's no branch prediction or anything like that. This isn't really a problem with loops; for them it's much better that these slots are exposed than if compulsory stalls were introduced (like on ARM and MIPS w/o branch prediction or mispredictions)
- Although there's 32KB of L1 icache, it's direct mapped so it's really just good for running one piece of code at a time, for a long time. Not good if the OS interrupts it a lot, but this is what we have a general purpose CPU for.
- It's very bare metal, in that it won't protect you from doing a lot of things. You have to be really careful not to cause dependency problems or performing multiple writes to the same register during the same cycle (especially a danger for the many instructions that have multiple cycle latency).
- There are some weird bugs, that I hope get fixed at some point :/
Applications:
- Obviously it'll be used for video and hopefully audio decoding too. Hopefully there will be libraries or at least binaries available for everyone to use this freely.
- One thing that immediately comes to mind is using it to render scanlines for 2D emulators. It should be able to fire off rendered tiles in quite a few less clocks than the Cortex-A8, although it is clocked a bit lower (430MHz vs 600MHz.. I wonder where they got 430MHz, and if that's off a separate clock than the CPU... their greatest common multiple seems to be ~3GHz, divided by 5 and 7)
I'm hoping to get something running on it over the next few months.
