How dead are 4bit MCUs?

[mariush]

Indeed, many 8-bit CPUs have a lot of "16-bitness" in them. A 4-bit CPU would have even more 8-bitness to it, and probably similar level of 16-bitness. Any savings are going to be just minimal.

But you totally can live without any 32-bitness. For simple control applications, IMHO a true 16-bit CPU seems quite sweet spot regarding power, cost, etc. Numbers exceeding -128..+127 range are extremely common, to the point that the extra logic in ALU is not sitting unused that much. Fewer memory operations are needed, code runs in fewer cycles, clock speed can be slower to compensate. And the whole CPU can be then 16-bit, not a strange mix where you have 8-bit ALU which you use to crunch 16-bit numbers 75% of the time, plus then some special registers that can be combined to perform a few special 16-bit operations, or used as pointers.

This is to say, any power/cost savings from a 8-bit CPU is already quite questionable, compared to a 16-bitter. I see absolutely no point in a 4-bitter.

Now, for very simple applications, a 32-bit CPU is indeed mostly waste compared to 16-bit, yet that's where we are going nevertheless.

This made me curious why there's no 10 bit or 12 bit microcontrollers  (in the sense of properly advertised as 10 bit, not like PICs with 10 or 12 or 14 bit words).

Just like they do optimizations when doing video encoding by packing 3 x 10 bit values into a 32 bit variable, seems like you could have 10 bit registers and if needed use 3 such registers to keep a 32 bit number and also have a couple bits for overflow, sign etc

I can only assume if the effort is made to go more than 8 bits,  you may as well go full 16 bits.

[coppice]

This made me curious why there's no 10 bit or 12 bit microcontrollers  (in the sense of properly advertised as 10 bit, not like PICs with 10 or 12 or 14 bit words).

There used to be 12 bit microcontrollers. Toshiba had a 12 bit MPU that I'm not sure was ever extended into a full MCU. However, the 6100 - a 12 bit MPU from Intersil and Harris that emulated the PDP8 - made it into some MCUs.

[langwadt]

Indeed, many 8-bit CPUs have a lot of "16-bitness" in them. A 4-bit CPU would have even more 8-bitness to it, and probably similar level of 16-bitness. Any savings are going to be just minimal.

But you totally can live without any 32-bitness. For simple control applications, IMHO a true 16-bit CPU seems quite sweet spot regarding power, cost, etc. Numbers exceeding -128..+127 range are extremely common, to the point that the extra logic in ALU is not sitting unused that much. Fewer memory operations are needed, code runs in fewer cycles, clock speed can be slower to compensate. And the whole CPU can be then 16-bit, not a strange mix where you have 8-bit ALU which you use to crunch 16-bit numbers 75% of the time, plus then some special registers that can be combined to perform a few special 16-bit operations, or used as pointers.

This is to say, any power/cost savings from a 8-bit CPU is already quite questionable, compared to a 16-bitter. I see absolutely no point in a 4-bitter.

Now, for very simple applications, a 32-bit CPU is indeed mostly waste compared to 16-bit, yet that's where we are going nevertheless.

This made me curious why there's no 10 bit or 12 bit microcontrollers  (in the sense of properly advertised as 10 bit, not like PICs with 10 or 12 or 14 bit words).

Just like they do optimizations when doing video encoding by packing 3 x 10 bit values into a 32 bit variable, seems like you could have 10 bit registers and if needed use 3 such registers to keep a 32 bit number and also have a couple bits for overflow, sign etc

I can only assume if the effort is made to go more than 8 bits,  you may as well go full 16 bits.

there has been some 24 bit DSPs, 16 bit not quite enough and 32 bit more than needed

[coppice]

there has been some 24 bit DSPs, 16 bit not quite enough and 32 bit more than needed

Most DSPs have mixed word lengths - a shortish length for parameters (typically 16 or 24) and a much longer length (typically a bit more than double the parameter word length) for the accumulators gathering the sum of product results from those parameters (e.g. 56 bits in a 24 bit MC56000 DSP, or 35 bits in some 16 bit DSPs).

[langwadt]

there has been some 24 bit DSPs, 16 bit not quite enough and 32 bit more than needed

Most DSPs have mixed word lengths - a shortish length for parameters (typically 16 or 24) and a much longer length (typically a bit more than double the parameter word length) for the accumulators gathering the sum of product results from those parameters (e.g. 56 bits in a 24 bit MC56000 DSP, or 35 bits in some 16 bit DSPs).

adsp2100 was 24 bit instructions, 16 bit data and 40 bit accumulator

[coppice]

there has been some 24 bit DSPs, 16 bit not quite enough and 32 bit more than needed

Most DSPs have mixed word lengths - a shortish length for parameters (typically 16 or 24) and a much longer length (typically a bit more than double the parameter word length) for the accumulators gathering the sum of product results from those parameters (e.g. 56 bits in a 24 bit MC56000 DSP, or 35 bits in some 16 bit DSPs).

adsp2100 was 24 bit instructions, 16 bit data and 40 bit accumulator

Most DSPs use a fairly pure Harvard architecture, and the instruction word length is completely unrelated to the data.

[free_electron]

This made me curious why there's no 10 bit or 12 bit microcontrollers  (in the sense of properly advertised as 10 bit, not like PICs with 10 or 12 or 14 bit words).

There used to be 12 bit microcontrollers. Toshiba had a 12 bit MPU that I'm not sure was ever extended into a full MCU. However, the 6100 - a 12 bit MPU from Intersil and Harris that emulated the PDP8 - made it into some MCUs.

the famous F8

[free_electron]

The 4-bitters were never e(e)prom or flash. Mask rom only.

The NEC uPD75P402 was a 4-bit MCU with OTPROM. It could be programmed on a regular programmer set to 27c256. There were some others in that family too. Used it as an RC-5 infrared decoder.

Ben

there were only a few. You could get them in piggyback though.

[free_electron]

many of the four bitters have special functions such as multiplane LCD drivers or VFD drivers. they are NMOS (not cmos) devices and could often handle high voltages on some of their I/O pins to drive VFD's directly
many video recorders , stereo systems, 5.1 receivers etc use those for the front panel control. typically sanyo , hitachi , nec , toshiba or mitsubishi machines.
open anything made by yamaha, denon, onkyo, technics, panasonic or any car radio made in the 90's and you will find these 4-bit micros doing that work.

[coppice]

This made me curious why there's no 10 bit or 12 bit microcontrollers  (in the sense of properly advertised as 10 bit, not like PICs with 10 or 12 or 14 bit words).

There used to be 12 bit microcontrollers. Toshiba had a 12 bit MPU that I'm not sure was ever extended into a full MCU. However, the 6100 - a 12 bit MPU from Intersil and Harris that emulated the PDP8 - made it into some MCUs.

the famous F8

The TMS1000 was the first microcontroller, and was 4 bit. The F8 was the first 8 bit device you might call a microcontroller. I don't remember anything 12 bit about it.

[PCB.Wiz]

This made me curious why there's no 10 bit or 12 bit microcontrollers  (in the sense of properly advertised as 10 bit, not like PICs with 10 or 12 or 14 bit words).

Just like they do optimizations when doing video encoding by packing 3 x 10 bit values into a 32 bit variable, seems like you could have 10 bit registers and if needed use 3 such registers to keep a 32 bit number and also have a couple bits for overflow, sign etc

I can only assume if the effort is made to go more than 8 bits,  you may as well go full 16 bits.

Part of that is to do with available memory.  PICs managed to do 12 and 14 bit opcodes, because they never planned to use external memory. If you only do on-chip memory, you are free to choose any size, and the PICs did that.
Early MCU parts like 8048 / 8051 / 6805 all had external memory versions first, before they had OTP or flash.

Even the 8088 CPU came into being, because of memory trade offs 

[aheid]

Maybe you could give these guys a call https://spectrum.ieee.org/plastic-microprocessor

Apparently low gate count leads to better yield on plastic, so they went with a 4-bit design.

[gnuarm]

there has been some 24 bit DSPs, 16 bit not quite enough and 32 bit more than needed

Most DSPs have mixed word lengths - a shortish length for parameters (typically 16 or 24) and a much longer length (typically a bit more than double the parameter word length) for the accumulators gathering the sum of product results from those parameters (e.g. 56 bits in a 24 bit MC56000 DSP, or 35 bits in some 16 bit DSPs).

adsp2100 was 24 bit instructions, 16 bit data and 40 bit accumulator

I don't recall the family designation, but AD had fixed point, 24 bit register devices, optimized for audio work.  Motorola did as well.  That was the last of the Motorola DSPs I believe. 

[westfw]

This made me curious why there's no 10 bit or 12 bit c

The secondary costs of not supporting the established 8bit byte addressing established by IBM 360 and DEC pdp-11 is quite high.  C becomes quite difficult (and you can’t copy any current C compiler with “minor modifications”), and there goes all the low level stuff that is written in C…

[free_electron]

This made me curious why there's no 10 bit or 12 bit c

The secondary costs of not supporting the established 8bit byte addressing established by IBM 360 and DEC pdp-11 is quite high.  C becomes quite difficult (and you can’t copy any current C compiler with “minor modifications”), and there goes all the low level stuff that is written in C…

i never understood why everyone is catering to a language that is designed for the pdp machines ... it fits like pliers on a pig to any other architecture.

[gnuarm]

This made me curious why there's no 10 bit or 12 bit c

The secondary costs of not supporting the established 8bit byte addressing established by IBM 360 and DEC pdp-11 is quite high.  C becomes quite difficult (and you can’t copy any current C compiler with “minor modifications”), and there goes all the low level stuff that is written in C…

Is it a requirement that the addressable unit in C be an 8 bit byte?  I use Forth and the addressable unit size is up to the system designer, and of course, the hardware.  They can be any size from 8 bits, up to the size of a "cell", the normal data unit size. 

What problem would that cause in C?

[gnuarm]

This made me curious why there's no 10 bit or 12 bit c

The secondary costs of not supporting the established 8bit byte addressing established by IBM 360 and DEC pdp-11 is quite high.  C becomes quite difficult (and you can’t copy any current C compiler with “minor modifications”), and there goes all the low level stuff that is written in C…

i never understood why everyone is catering to a language that is designed for the pdp machines ... it fits like pliers on a pig to any other architecture.

  How is that so?  Which architectures are the pig?

[free_electron]

This made me curious why there's no 10 bit or 12 bit c

The secondary costs of not supporting the established 8bit byte addressing established by IBM 360 and DEC pdp-11 is quite high.  C becomes quite difficult (and you can’t copy any current C compiler with “minor modifications”), and there goes all the low level stuff that is written in C…

i never understood why everyone is catering to a language that is designed for the pdp machines ... it fits like pliers on a pig to any other architecture.

  How is that so?  Which architectures are the pig?

wants a big stack , large register banks. try any 8 bit micro that does no have that. anything that is accumulator based for example where you have no register bank. or processors that have switchable banks (like 8051) or processors with hardware stacks (pic).
the PDP-11 had uniform memory where i/o was mapped in the memory. basically von neumann.  try a harvard machine...
i've seen compilers that, to perform a print operation, have to move the data first from rom to ram and then pass the ram copy off ... they waste lots of time and ram just to copy and shuffle data.

[gnuarm]

wants a big stack , large register banks. try any 8 bit micro that does no have that. anything that is accumulator based for example where you have no register bank. or processors that have switchable banks (like 8051) or processors with hardware stacks (pic).
the PDP-11 had uniform memory where i/o was mapped in the memory. basically von neumann.  try a harvard machine...
i've seen compilers that, to perform a print operation, have to move the data first from rom to ram and then pass the ram copy off ... they waste lots of time and ram just to copy and shuffle data.

How many programs on an 8051 use print statements?  Isn't the library that supports that very large, as in too large for such small memory devices? 

[free_electron]

wants a big stack , large register banks. try any 8 bit micro that does no have that. anything that is accumulator based for example where you have no register bank. or processors that have switchable banks (like 8051) or processors with hardware stacks (pic).
the PDP-11 had uniform memory where i/o was mapped in the memory. basically von neumann.  try a harvard machine...
i've seen compilers that, to perform a print operation, have to move the data first from rom to ram and then pass the ram copy off ... they waste lots of time and ram just to copy and shuffle data.

How many programs on an 8051 use print statements?  Isn't the library that supports that very large, as in too large for such small memory devices?

i do it all the time. i have written programs that drive VT100 terminals including the ansi escape codes to emulate field entry. fits in 8kilobyte, using my own print routines. Sending text to uart is like 10 bytes of code to send a null terminated string. Sending numbers is barely 20 bytes. Written in PL/M.

Code: [Select]

putchar : procedure (char) public;
   declare char byte;
   do while not TI;  /* wait for Transmit flag to set. TI is the name of a bit in the SCON register */
   end;
   TI=0; /*arm the transmitter*/
   SBUF=char; /*throw character in transmit register. this will automatically set TI to one when transmit is complete*/
end putchar;

printstring : procedure (stringpointer) public;
   declare stringpointer address;                           /* we will be receiving a pointer*/
   declare char based stringpointer byte constant;  /* pointer points to a byte that resides in rom (constant)*/
   do while char <>0; /* look for null terminator*/
   call putchar(char);
   stringpointer=stringpointer+1;
   end;
end printstring;

printstring(.('hello world'),0);

yeah it's not a fullblown printf, but it can do strings , strings are stored in rom anyway. why would you want to copy those to ram ? as for numbers , another 30 bytes or so create the routines to send out bytes, words and quads (32 bit). larger numbers use BCD arithmetic and are stored as packed bytes. (2 digits per byte). The runtime library is like 300 bytes to do almost anything you want.

the pl/m manual gives an example of a simple calculator program that works over uart. it does unsigned 16 bit arithmetic with + - / *. it's roughly 700 bytes in rom ( 400 bytes are strings for the user.. there's barely 300 bytes of real code) long, uses 5 bytes of ram and 4 bytes of stack.

[westfw]

Is it a requirement that the addressable unit in C be an 8 bit byte?

Pretty much.  I mean, not semantically, but part of the attraction of C is not the language itself, but the existing base of knowledge, applications, tools, and libraries.
I worked with some people doing C for the PDP-10 (36bit words, and "special" addressing modes that could deal with bytes (7bit ascii, 8bit, whatever.)  And it worked, and people did useful things with it, but ... it wasn't pretty.  I guess nowadays you'd just use 8bit text for everything and waste some space, but the architecture and peripherals didn't have gigawords of storage, and that extra byte per word (5 ascii chars vs 4 8bit bytes) was pretty important.

[SiliconWizard]

Is it a requirement that the addressable unit in C be an 8 bit byte?

Pretty much.  I mean, not semantically,(...)

Well, from the standard's strict POV you're right, but I would just add something.

Ever since C99, which introduced stdint.h, the answer is, I suppose, a bit more straightforward. As the int8_t/uint8_t are mandatory types in C99 AFAIR, a compliant compiler *has* to have means of accessing memory in 8-bit chunks on any supported platform. Otherwise those types would be unusable, as they are exact-width types. So it's a bit of a deduction from the standard rather than a fact that's clearly stated. Maybe someone will expose a way of fully supporting those types with wider accesses (like, I dunno, 9-bit, or 12-bit, etc), although I suppose that might imply some kind of non-compliance along the way.

[brucehoult]

Is it a requirement that the addressable unit in C be an 8 bit byte?

Pretty much.  I mean, not semantically,(...)

Well, from the standard's strict POV you're right, but I would just add something.

Ever since C99, which introduced stdint.h, the answer is, I suppose, a bit more straightforward. As the int8_t/uint8_t are mandatory types in C99 AFAIR, a compliant compiler *has* to have means of accessing memory in 8-bit chunks on any supported platform.

Wassa problem? You already have to be able to access integer values stored in arbitrary width bitfields in structs in memory.

How do you represent an int8_t[N] on a 36 bit machine? Assuming you're allowed to use N/4 words and waste 4 bits in each of them then it all seems pretty simple. Do any 36 bit machines support more than 2^34 words of RAM (72 GB)? I suspect not, They're probably all so old that they don't even support 72 MB, let alone GB.

So, you represent a int8_t* as the word address shifted left by 2, with the bottom two bits indicating bytes 0,1,2,3 within the word.

Many such machines with have separate and much smaller pointer registers anyway.

There is no requirement in C for int* and int8_t* to have the same representation.

[westfw]

There is no requirement in C for int* and int8_t* to have the same representation.

Really?  Don't they both have to cast to void* at some point?

represent a int8_t* as the word address shifted left by 2, with the bottom two bits indicating byte within the word.

Assuming that you don't mind throwing performance away.
The PDP10 in question had a "byte pointer" "thing" that contained bit offset, byte size, and indexible (word) memory address (with the default 18bit address space.)  But it was slower than normal memory accesses, and not easily indexed by byte number.   Also "One Word Global Byte Pointers" that handled the common byte sizes within the extended address space (30bits?  The last released DEC PDP10 supported 23bits, and I don't think it was possible to put that much physical memory on a system.)
The whole "extended addresses" on PDP10 worked about as well as the bank switching on smaller instruction architectures with inherently smaller addresses; ie not very well.  :-(  It's probably one of the things that led to the early (IMO) demise of the architecture.  :-( :-(

[brucehoult]

There is no requirement in C for int* and int8_t* to have the same representation.

Really?  Don't they both have to cast to void* at some point?

You have to be able to cast to void* and back to the original type and get the same value again. You don't have to be able to cast between int8_t* and int* (even via void*). And void* doesn't have to have the same representation.

represent a int8_t* as the word address shifted left by 2, with the bottom two bits indicating byte within the word.

Assuming that you don't mind throwing performance away.

That's pretty much inherent in using subword operations, on anything. That's why Pascal distinguished between "array of char" (one word per char) and "packed array of char" and had the pack() and unpack() standard functions to convert between them. BCPL had something similar too.