You are now used to computers with byte-granular pointers. Users of CRAY computers, however, don't have this luxury and must deal with 64-bits words. Now, have fun with ASCII/UTF8 strings !
OK, a CRAY is not designed for word processing. And it can handle 8 bytes at a time. But still, it's miserable when you must deal with data that doesn't have the same granularity as your registers and pointer type.
"Canon" RISC machines such as MIPS and Alpha have byte pointer granularity and word-wide registers and memory granularity. It's a compromise. Trap when the pointer is not aligned and... OK it sucks too. But less because the pointers have a reasonable, matching granularity.
And then, there's the SHARC. Analog Devices' ADSP21k family is not the most world's best-known 32-bits DSP but it's a really wonderful architecture. I have learned so many tricks by reading its manual 20 years ago... One interesting "trick" is to split the addressing range into sections with different word granularities.
The core is 32-bits but depending on where you address data, it will come back as a byte, a half-word or a word. The size is not encoded in the instruction, no "special unit" (like YASEP's LSU) to perform post-load adjustment. It's in the pointer.
This idea is great... to a certain extent. The SHARC has no virtual memory, no problem with aliases, it's not a multi-user application CPU. It's a beast that performs large fancy FFT with carefully crafted code, written by careful people.
If you want such a heterogeneous granularity in an application processor, you'll face quite a few problems because data has to be shifted/masked at one point or another. Either it's implicit with the pointer and you'll have to include shifters in the datapath of the memory load/store unit (which will slow things down), or you have to do it explicitly. In all cases, format changes take space and time. Everything has a price...
In the end, if a heterogeneous space works for a specialised processor, it creates more problems than it solves for a General Purpose Application Processor.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.