> On Sep 17, 2016, at 10:10 AM, Chuck Guzis <[email protected]> wrote: > > On 09/17/2016 09:23 AM, Eric Smith wrote: > >> I don't know what the width of the TMS9900 ALU is, but I'm pretty >> sure it's not bit-serial, as an add instruction only takes 14 clock >> cycles, including four memory cycles. I'd be very surprised if the >> ALU isn't either 8 or 16 bits, though 4 might be possible. >> >> Possibly someone is confused by the bit-serial "CRU' I/O space, but >> that is unrelated to the ALU width. > > Could very well be--I'm just going by other's appraisals of the > architecture. > > But there were some "8 bit" MPUs with bit-serial ALUs, so the question > is still valid. >
Why? What does the width of the ALU have to do with the “bitness” of the architecture? If the programmer’s view is 8-bits (or 16 or 23, or ??), what does it matter (other than performance) what the width of the internal data paths or ALU are? It’s interesting from an implementation point of view but not really anything else. In a previous email, I mentioned the IBM 360 as an example of a 32-bit machine (architecture) that had 8, 16 and 32 bit internal data paths and I don’t think anyone would suggest that the 360 models that did not have 32-bit data paths wasn’t a 32-bit “machine”. The same could be said for the PDP-8/s. That’s a bit serial machine but it is a member of the PDP-8 family. Would you call it a 1-bit machine or a 12-bit machine? That’s why (in my previous email) I made the distinction between architecture and implementation. The reference “machine” (which I’ve intentionally used here) is somewhat ambiguous and I tend to use architecture or implementation when I want to be specific. TTFN - Guy
