PSP2 features - the handheld version *renamed
- Thread starter AzBat
- Start date
- Status
ARM vs. MIPS, dual core vs. single core plus stripped coprocessor, apples vs. oranges. The PSP is also clocked at 222MHz by default. And as was already mentioned, developers only have access to 32MB of those 64MB RAM, and even then, they need to compensate for the slow as molasses mass storage.
Assuming the 2x266MHz ARM11 reveal is correct, we still don't know if user code would be allowed on the second core. It isn't on the DS, afterall (or PSP, which I guess is what you implied by it being "stripped")
PSP having an earlier clocking restriction of 222MHz is irrelevant. Games have been allowed 333MHz for years. If Sony wanted to they could also update the firmware to allow trusted developers access to the second core and RAM used as UMD cache on the 2000+ models, but it's pretty late to try such a thing.
ARM vs MIPS is much less of a relevant comparison than the particular CPU architectures in question, ie ARM11 vs Allegrex. Both are single issue and execute most non-FPU instructions in one cycle, with the major exception being that ARM11 has branch prediction while Allegrex has delayed branches that always imply at least a 1-cycle additional stall (but the mispredict cost on ARM11 is much worse, and its predictor isn't that great). ARM11 also has a worse load-use latency of 2 cycles vs 1 cycle on Allegrex, and has an address generation interlock cycle. In other words, a longer/more complex pipeline and it pays for it. Oh, and I guess the 64-bit interfaces to icache and dcache helps sometimes too.
So while they're indeed different processors they're not exactly in two entirely different classes. IMO, ARM11's strengths are in its higher clock speeds, and unless it has lower power consumption at 266MHz I'd probably sooner go with an ARM9, because I doubt the ARM11 is much faster.
It's been a long time since I studied the MIPS architecture, but surely there is, in effect, only a 1-cycle "additional stall" if you don't have a useful instruction to put in the delay slot?
Only for the original 5-stage pipeline in the first implementations. Again, MIPS is an instruction set, not a CPU design, which is precisely why mechanisms like delay slots aren't a great idea.
The second core on the DS has always been a lower clocked cheaper CPU (in comparison to the main gaming CPU), same goes for Wii (Starlet). I'd be suprised if their isn't a lower clocked ARM7/9 in their with both ARM11 cores being used for games.
By the way, by stripped I think he's saying that the second CPU core in PSP isn't identical to the first, but instead a stripped down version. I'm not personally sure how true that is but that's how I read it (I think the second core has no FPU?, but I'm not sure about the specifics).
I suppose they could create games that work in an enhanced mode on the newer models, they won't of course.
Last edited by a moderator:
I actually expect the 3DS to use a dual ARM11MPCore which developers have access to, as well as an additional ARM9 core for background tasks like Spotpass and Streetpass.
And the PSP Media Engine is not a full blown second CPU core, no matter if or how it's accessible. The VPU was removed, it has no access to the VRAM, and there's no cache coherency, just to name a few examples.
On the other hand, maybe the rumored 3DS specs are completely wrong. It seems to be proven now that there was, in fact, an early version of the 3DS devkit based on Tegra. Tegra uses ARM11MPCore. After Nintendo switched to DMP, they might have switched to a different CPU as well.
DS and DSi are the only Nintendo handhelds that have had second processors running auxiliary/interface code for the main game. I'm not familiar with Starlet, but is it programmable or does it just run off of a ROM?
There's no VFPU, but that's sort of moot given that chances are low that either 3DS CPU will have a vector coprocessor. Otherwise, it's the same basic architecture, clock speed, cache size, etc, and has a standard FPU.
wsippel said:
Sure, it's possible, and there are reasons to do it, but right now we just don't know.
wsippel said:
None of those things have anything to do with whether or not something is a "full blown" CPU core. You don't know if 3DS will have a VFPU (it probably won't), you don't know if its VRAM will even be directly visible to either CPU much less both, and you don't even know if the L1 cache will be coherent between the two. Or maybe you're saying that it doesn't count because it's not symmetric and therefore you can't blindly issue threads to either agnostically?
wsippel said:
The rumors were that it's based on Tegra 2, and the only verification we had was that the boards had a "TEG2" designator. Tegra 2 is a dual core Cortex-A9 design.
Thanks - as I said it's been many years since I looked at MIPS devices, but I did do quite a bit of development on a TI DSP which had branches with 3 delay slots.
Initially, I was going to agree with you but, having thought more about it, I can't see that it is a problem to have an ISA that has, say, 1 delay-slot branches. In effect it is equivalent to any non-branch instruction having the option to also branch (based on an earlier instruction).
There is nothing, AFAICS, preventing an actual CPU then also implementing prediction and/or out-of-order instruction execution, and/or predication given sufficient silicon budget. <shrug>
Yeah, IIRC TI's TMS320C6x series DSPs have an amazing 5 delay slots. Real fun to code an 8-way VLIW like that, you could have dozens of instructions before the branch hits.
Delay slots are good when the alternative is an unavoidable cost per branch, but they're not exactly without consequence. If you can't fill them that's a wasted cycle and adds to code size, and a lot of the time they can't be filled. Platforms with annulment like SPARC could potentially avoid this, but it'd be complex to make them behave like anything more than delay slot branches with an implicit NOP placed.
Another annoyance with delay slots is that they make exception handling trickier, for both hardware and software. On SPARC you have to go through a ritual of restoring both the PC and next PC. The C6x is so heavily delay slotted that you pretty much have to turn off interrupts when using code that isn't intentionally heavily crippled to be interrupt safe.
Theoretically it may be possible to perform branch prediction based on the most recent modification to whatever the branch can decide on (usually flags), which would let you get the same sorts of benefits delay slots provide. Of course this requires the ability to not set flags on ALU operations. The only processors I know of that do this are PowerPCs, but there are probably others.
Last edited by a moderator:
Anecdotal evidence, but I havent had much problem filling branch delay-slots (MIPS)
It might be a problem if you want absolute smallest code-size, but otherwise you typically have something usefull to do after unrolling a loop once or fitting a instruction that might be useless in one branch but doesnt do any other harm.
I think its a rather simplistic way of OoO, and has a benefit aslong the implementation isnt faster than the architectural delay slot(s) (unlikely that executing branches will ever have less latency than 1 clockcycle). Even if you have an OoO CPU, there are times where its behind in fetching - so detecting a branch early can help there too.
Yeah this is the most annoying issue.
Well GameBoy didn't really have any need for a second processor due to the fact there was no interface outside of the game itself. Ever since Nintendo started creating handhelds/consoles with basic OS's (DS/Wii) they've used a second lower clocked CPU to run them.
Starlet is an ARM9 CPU (243Mhz AFAIK) inside Wii's GPU, I'm no Wii dev so I don't know much about the CPU, but it seems its similar in prupose/use to the second CPU in the DS.
DS games don't run what I could consider an OS, regardless of Nintendo's terminology. Just some peripheral abstraction libraries. Starlet is more or less the same, although it also does security. I don't know what you mean by interface outside of the game itself, do you mean hardware abstraction?
Probably the biggest reason why DS has an ARM7 is to execute GBA games on. From there it made sense to incorporate it into other aspects of the design. The situation on Wii is kind of in reverse - they use another CPU + glue logic to abstract the new peripherals away from the Broadway chip, so it can work without running code on it in Gamecube mode.
No doubt backwards compatibility was a big reason for it. Just saying that recently Nintendo seems to like using an additional lower clocked CPU in their system designs and I wouldn't be suprised if 3DS includes one. Perhaps a 133Mhz ARM9 for DS backward compatibility, which will also do any other grunt work for the system outside of gaming.
I agree of course that DS's interface isn't really an OS, I did say basic though and that was a big understatement
Last edited by a moderator:
ltcommander.data
Regular
http://www.engadget.com/2011/01/19/bloomberg-sony-psp2-to-debut-next-week-playstation-phone-at-mw/
Well the wait is supposedly nearly over. Bloomberg is reporting that the PSP2 will be announced next week and the Playstation Phone next month. I'll be interested to see how Sony intends to play them off each other. Will they be cannibalizing each other or does Sony actually expect people to buy both? If the performance and controls are decent in the Playstation Phone will the PSP2 really be necessary for most customers? I guess the only issue is battery life on a gaming phone, but then people may well rather carry a spare battery than a whole other device.
Well the wait is supposedly nearly over. Bloomberg is reporting that the PSP2 will be announced next week and the Playstation Phone next month. I'll be interested to see how Sony intends to play them off each other. Will they be cannibalizing each other or does Sony actually expect people to buy both? If the performance and controls are decent in the Playstation Phone will the PSP2 really be necessary for most customers? I guess the only issue is battery life on a gaming phone, but then people may well rather carry a spare battery than a whole other device.
D
Deleted member 13524
Guest
IMHO the PSP2 only needs a larger 3D screen than 3DS and better processing hardware. Neither are really hard to find nowadays. Sharp has been shipping 3.7" 840*480 3D Screens for a while and the rumoured SGX543MP4 should be way faster than PICA200 (not to mention the dual ARM11 266MHz).
But the PSP2 needs to have a 3D screen, or the novelty-halo from the 3DS will certainly take most of the market (and Sony may be spending too much money on a portable console that may never really take off).
But the PSP2 needs to have a 3D screen, or the novelty-halo from the 3DS will certainly take most of the market (and Sony may be spending too much money on a portable console that may never really take off).
One is Sony, the other is Sony Ericsson, which are entirely different companies, and it appears that the platforms are not related in anyway.
The rumoured rear mounted touch controls on the PSP2 would be a differientator.
Its hard to gauge the 3DS 3D effect, in terms of whether the experience is great or just transient. I think doing glassless 3D (and making that the core selling point) is as much a gamble as not doing 3D in many ways. If 3DS 3D works and its generally really well received then PSP2 will have a harder time, the converse is also true.
The rumoured rear mounted touch controls on the PSP2 would be a differientator.
Its hard to gauge the 3DS 3D effect, in terms of whether the experience is great or just transient. I think doing glassless 3D (and making that the core selling point) is as much a gamble as not doing 3D in many ways. If 3DS 3D works and its generally really well received then PSP2 will have a harder time, the converse is also true.
Last edited by a moderator:
- Status
