Op 17 sep. 2016 8:34 p.m. schreef "Guy Sotomayor Jr" <g...@shiresoft.com>: > > > > On Sep 17, 2016, at 10:10 AM, Chuck Guzis <ccl...@sydex.com> 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”.
Don't forget about the 64-bit implementations, like the model 65. > > 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 >