On Thu, 15 Sep 2016, Chuck Guzis wrote: Ah, but can the manufacturer be trusted? What would motivate them to take a 32 bit processor and CALL it 16 bit? Was that a marketing decision? "We can call it a good competitive 32 bit processor, or we can make an indisputable claim that it is the BEST 16 bit processor!" There are more than a hundred different parameters involved. There is no definitive agreement as to which parameter is to be used for the classification, nor even which parameterS. Whenever somebody has the efrontery to build a product that has one classification by one parameter, and a different classification by another parameter, there will be disputed classifications, since different parameters are more or less important to each viewer. Few, if any processors could be unambiguously classified. What size is a Z80? 8088? 8086? 80286? 6809? Everybody here can agree that that is a stupid question, because the list of answers is "OBVIOUS". And yet a comparison of answers WILL have discrepancies. Register size would be an obvious one. But, as soon as provision is made for accessing half registers and double ones, it is open to variant interpretations even of what the register size is. Should we classify them, instead by their heat output? Which part of the elephant are we looking at? -- Grumpy Ol' Fred cisin at xenosoft.com

On 9/15/2016 1:34 PM, Chuck Guzis wrote: I have a nice paper design for a 32 bit CPU using 2901 bit slices that accesses 16 bit data for the 1976..1981 time frame. With 512 Kb of address space, 16Kx1 drams fill it to the brim. Ample in hindsight for a Text Based DOS but not Window style OS. 1 Logic cards and 2 Alu cards would comprise the computer section. Real I/O is still big iron , and that needs more thought what size my SD card will be. However at the moment my FPGA development platform, will be with 9/18 bit TTL Style cpu and I/O devices in the .5 to 2.5 MB range on the SD CARD. Back to the 68000. I really have no beefs about the 68000 other than it could not handle Virtual Memory as well as the fact IBM had 370 mainframe cpu chip by changing the uCode in the 68000. I still have found a Computer Architecture I like, with the evil 8 bit bytes. Ben. PS: Ternary arithmetic I can understand, but Ternary Logic needs Mr Spock to figure out.

On 16 September 2016 at 14:51, David Bridgham <dab at froghouse.org> wrote: Huh? But there have been several -- the Russian/Polish SETUN was the first committed to hardware. http://www.computer-museum.ru/english/setun.htm But there have been others: https://en.wikipedia.org/wiki/Ternary_computer One chap is even trying to build his own: https://hackaday.io/project/1043-base-3-ternary-computer-from-scratch -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 26 September 2016 at 17:55, Tomasz Rola <rtomek at ceti.pl> wrote: Ah, sorry. I think I was confusing 2 different machines. Possibly the one I was thinking about was Elwro's UMC: https://en.wikipedia.org/wiki/UMC_(computer) -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

In a talk on the HP9810 desktop calculator I said, somewhat tongue-in-cheek that it could claim to be 1, 3, 4, 6, 8 or 16 bits. The justifications for those are as follows : The processor has 16 bit registers. It's bit serial, so the normal internal ALU and data path width is 1 bit. But it does BCD additions between the A (accumulator) and T (memory data) registers a nybble (4 bits) at a time. The memory system is odd, with hardware translating a read or write into 2 cycles on successive locations. One location stores the odd bits, the other the even bits. So the physical width of memory for things like the system stack is 8 bits. Even odder, the machine stores user programs as sequences of 6 bit keycodes. User program memory is logically 6 bits wide. But because of the memory control system, such memory is physically 3 bits wide, user program memory expansion consists of Intel 1103 (1K*1bit) DRAMs fitted in sets of 3. So : 1 bit -- physical width of binary ALU and data paths 3 bits -- physical width of user program memory 4 bits -- physical width of BCD ALU and data paths 6 bits -- logical width of user program memory 8 bits -- physical width of data memory 16 bits -- logical width of data memory, physical width of CPU registers Call it what you will :-) -tony

I wrote: Ooops- my explanation got the last two ALUs backwards. DataHigh and AddressHigh share an ALU. Note that in the conclusion to this 1979 article, the Motorola engineers say "It is a 32-bit architecture that supports many data types and data addresses." - Jecel.

The important part (I believe) is to differentiate ?architecture? from ?implementation?. It is quite possible to have a single architecture with multiple implementations. For example, the IBM 360. It is a 32-bit architecture. It had a number of implementations where the data paths were 8, 16 and 32 bits. Does that mean that the models that were implemented with 8 bit data paths were an 8 bit architecture and the models with 16 bit data paths were 16 bit architecture? I think not. Where some confusion comes in when we call something a 32-bit machine. Does that refer to its architecture or its implementation? Sure it does. It say ?architecture? in the above quote, so I think that settles it. What is the programming model? If the 22 bit word is the fundamental unit of expression (ie registers and memory are fundamentally organized around 22-bits) then I would say it?s a 22-bit architecture. It?s very similar to the AVX instructions on Intel. The latest are 512-bit instructions. Some *implementations* have 256 bit data paths. But no one argues that the AVX instruction architecture is 512-bits. Likewise, using memory width as a differentiator is also un-informative (as well as being ?just an implementation detail?). For example, IBM?s POWER processors have had 256 and 512 bit data bussesfor many years (basically the width was determined by the size of a cache line). Would that make them 256/512 bit architectures? The latest Intel CPUs also have very wide paths to memory (some of which is determined by how many banks of DRAM are installed). TTFN - Guy

On 09/16/2016 05:37 PM, Cameron Kaiser wrote: So the "bitedness" is determined by the memory bus? e.g., a 68008 is an 8-bit MPU? The PB250 is serial throughout--the registers are implemented as 1 bit recirculating devices that are 22 bits in length. Memory is addressable in 22 bit words (no shorter unit of addressing is present) and is again, loops of recirculating serial data. Basic operations are performed on 22-bit words. FWIW, it's a one-plus-one instruction set. My point being that it's a slippery concept that can mean a lot of different things, depending upon who's doing the calling. --Chuck

On 09/16/2016 07:33 PM, Cameron Kaiser wrote: Simply because, as you noted on the TMS9900, a data path can override the consideration that a machine has a 1-bit ALU. In the PB250 there are no 22-bit data paths in the whole machine. As a matter of fact, the PB250 has on the order of only 400 transistors (lots of diodes, however). So, does the internal data path width to the machine bear on the bit-edness of the architecture? As I pointed out, since, on a machine with no user-visible registers, the bit-edness can be anything if you ignore data path widths. A bit-serial memory and ALU could define a word size to be thousands of bits--all that would be needed is a bit counter to keep one's position within a "word". In particular, there were variable word-length machines, so a machine could have a mixture of word sizes all in play at the same time. But if you define a machine by the minimum width of its data paths, then a bit-serial ALU in the TMS9900 would cause it to become a 1-bit machine. I believe that there were other bit-serial ALU micros in the early days--maybe the SC/MP? Memory fails me at this point. --Chuck

On Fri, Sep 16, 2016 at 5:41 PM, Chuck Guzis <cclist at sydex.com> 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.

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

Perhaps the best way to look at this question is that the architecture width of an architecture is what the architect says it is. It's often the width of the registers, but not always. It may be the width of the memory, but not necessarily. It may or may not match the width of the system bus (if there is one) or the main data paths -- but often it doesn't. One other example of a machine that confuses the picture is the CDC 6000 series peripheral processor. I doubt there would be much objection to calling that a 12 bit architecture. But its main register (the accumulator) is 18 bits wide. paul

Op 17 sep. 2016 8:34 p.m. schreef "Guy Sotomayor Jr" <ggs at shiresoft.com>: internal machine think paths Don't forget about the 64-bit implementations, like the model 65. it 12-bit architecture used here) when I

On 09/15/2016 05:17 PM, js at cimmeri.com wrote: So what's the width of an IBM 1620? --Chuck

On 09/15/2016 11:18 PM, ben wrote: Nope, that can't be. 1620 is a decimal machine (normally) and while the memory interface is 12 bits, two of those bits are parity bits, so you can't count those. That leads to "bytes" of 10 bits, two of which are flag/sign bits, so they don't really enter into computation. That is, the smallest unit on which one can do arithmetic is two decimal digits, with one flag bit serving as field demarcation and the other serving as sign. While you might call this a 10 bit machine, that's misleading. There are special bit patterns that mean things (such as 8-2 bit, which means a record mark, but the special combinations must be read, as there's no way to generate or test for them programatically. There are no visible registers; i.e., there's no way to query the P-counter directly. My point is that there are many machines that defy simple labels. Harvard architecture machines can be sioppery--take the humble PIC it its simplest form--12 bit instruction words that may also contain data, but 8 bit computation and data registers. I'm aware of supercomputers with 512 bit memory paths that, for example, can compute 128 bits per cycle, but have 64-bit GP registers. --Chuck

On Thu, Sep 15, 2016 at 8:07 PM, Cameron Kaiser <spectre at floodgap.com> wrote: How about 65k of RAM?! http://tr3.cbsistatic.com/hub/i/2011/04/06/5174da48-c3aa-11e2-bc00-02911874… That's like...a whole 1k more than the competition!

On 16/09/16 12:19, Peter Corlett wrote: I've never encountered anyone claiming that a 10Mb/s network means anything other than ten million bits per second. I suppose *someone* must have fiddled their network speeds in some marketing brochure, but they'd be the exception rather than the rule. Antonio -- Antonio Carlini arcarlini at iee.org