> 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”.

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

Reply via email to