DEC Alpha: why no 8/16-bit load/stores?

Question

The first version of the DEC Alpha had no load/store instructions for 8 or 16-bit values; if you wanted to deal with data of such sizes, you had to do it by shifting and masking values in registers as necessary. (This restriction was abandoned later because too much existing technology was designed around the assumption that addressing bytes is a commonplace thing to do; I'm asking purely about the technical reasons for doing it that way in the first version.)

On the face of it, it makes sense that it would simplify the hardware. According to http://alasir.com/articles/alpha_history/press/alpha_intro.html

Alpha is unconventional in the approach to byte manipulation. Single-byte stores found in conventional RISC architectures force cache and memory implementations to include byte shift-and-mask logic, and sequencer logic to perform read-modify-write on memory words. This approach is awkward to implement quickly, and tends to slow down cache access to normal 32- or 64-bit aligned quantities. It also makes it awkward to build a high-speed error-correcting write-back cache, which is often needed to keep a very fast RISC implementation busy. It also can make it difficult to pipeline multiple byte operations.

But hang on. Alpha did support storing 32-bit numbers. But it was a 64-bit architecture. So that's already supporting storing values smaller than a full word. Doesn't that already incur precisely the complexity that they were trying to avoid?

In other words, in a 64-bit CPU, isn't it pointless to refuse to support 8-bit stores if you are already supporting 32-bit stores that already need the same kind of hardware support? Or if not, why not?

Answer 1

Support for byte writes throughout a memory system is expensive. Among other things, if one wishes to use error-corrected memory that can correct single-bit errors, a memory that can be written in independent 8-bit chunks byte-writable memory will require four extra bits per octet, or 16 bits per 32-bit word. A memory that is limited to writing 16-bit chunks will require five bits extra per 16-bit word, or 10 bits per word; one that's limited to writing 32-bit chunks would only require six extra bits per word.

Worse, support for byte granularity increases the complexity of caching hardware. If one is using a 256-bit bus between the cache and main memory, limiting writes to multiples of 32 bits would require using eight read/write control circuits and keeping track of eight dirty bits per row. Allowing individual octets to be written would increase that to 32 separate read/write control circuits and 32 dirty bits.

For most tasks, having to use a read-modify-write sequence to update individual bytes would not be an issue. Unfortunately for DEC, many programming languages specify that adjacent bytes within any character array may be safely written by different threads without requiring synchronization, and offer no means by which programmers can indicate that they don't need such semantics. While the Alpha could efficiently process programs that wouldn't require it to accommodate the possibility of simultaneous writes to different parts of a word, languages provide no means of identifying such programs.

Answer 2

Apart from anything else, Alpha was the VAX replacement - indeed, it was internally called EVAX. It would be necessary to take VMS source code written in VAX MACRO-32 assembler and compile it into Alpha machine code.

VMS had a lot of dependency on 32-bit words. MACRO-32 code was explicit about length. Higher-level code, in BLISS-32, tended to be explicit about operand length or perhaps merely assumed that a fullword was exactly 32 bits. Ergo, any credible hardware base for VMS requires efficient 32-bit operations.

I assume there was perceived to be no particular byte requirement for VMS since most (non-C) software would be using VMS conventions for strings (counted, not with a terminator character) and VAX machine instructions (MOVC3, CMPC3, etc., or the equivalent BLISS-32 'CH$' builtins), said instructions easily being emulated on Alpha. C was not seen as a major implementation language on VMS at the time.

(Warning: opinion of one DEC software guy only)