I'm pretty sure that's true of MIPS64 as well
yes, I confirm it, it's a big mess with MIPS64
I have recently bought a few cpu modules for my Malta board
although "CoreLV-5KC" sounds like the cpu used by SGI in their Indy-station
"5K" doesn't mean "R5000"
"4KC" means MIPS32r2, "5KC" means MIPS64
the first one is a true 32bit machine, the second one is a true 64bit machine
but it also comes with 32bit legacy mode
confused? well … looking at the cpu user manual you will have a shock
especially if you compare what you read with the Core20K's UM
Core20K is "5kc", but … it has different definitions in its AN
so, what the frog is 64bit? it's not clear when they talk about
pointer, and data, sometime p_uint64_t is NOT a 64bit pointer
(especially in legacy 32bit mode) so, why they call it _64_t ?
not clear at all
It's a bit shocking how much code breaks when sizeof (long*) != sizeof(long)...
yes, an example is the Atlas board
it accepts both the cpu modules, 32bit and 64bit
but you can't recompile the same examples without having to deal a lot of messes
actually you have two branches, the same code forked into two branches
because of messes with sizeof (long*) != sizeof(long)
long* is 64 bit with "5kc" (but it can also be 32bit if you use the legacy mode)
long* is 32bit with "4kc"
computer science, feelings of pity and sorrow for someone else's misfortune