EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: gnuarm on June 12, 2022, 02:10:10 pm
-
I have found a very small number of 4bit MCUs still on the market, but not as many as I expected. Aren't they still used in coffee makers, remote controls, microwave ovens, toys, etc?
I remember talking to a guy who designed toys, and he said they would review his designs and if there was a resistor that was not absolutely essential, they would remove it to save the 0.1 cents.
Then there's also the power issue. I would expect a 4 bit MCU to be more power thrifty than an 8 bit MCU, doing the very simple tasks these parts would be used for. But... I don't know if this would be significant. Even in a remote control, it sits idle 99.99% of the time, then the LED draws 20 mA for a brief moment.
Anyone here using 4 bit microcontrollers?
BTW, I tried searching on "4 bit", but the search requires at least 2 characters in every word and I guess it sees "4" as a word.
-
I have found a very small number of 4bit MCUs still on the market, but not as many as I expected. Aren't they still used in coffee makers, remote controls, microwave ovens, toys, etc?
I remember talking to a guy who designed toys, and he said they would review his designs and if there was a resistor that was not absolutely essential, they would remove it to save the 0.1 cents.
8 bit microcontrollers are usually pad limited these days.
What process node are the inexpensive MCUs being built on? Low priced products are often made on obsolete processes because the equipment is essentially free, fully amortized. Then there's the power issues. MCUs are often used in very low power applications. I believe it was around 90nm where the static power got to be very significant compared to the dynamic. Later geometries focused on power and so got better by trading off improvements in speed.
BTW, I tried searching on "4 bit", but the search requires at least 2 characters in every word and I guess it sees "4" as a word.
This search worked fine:
https://www.google.com/search?q=%224+bit%22+microcontroller (https://www.google.com/search?q=%224+bit%22+microcontroller)
I was talking about the search here, in eevblog.
But the Google search, while "working fine", doesn't pull up many makers of 4bit chips.
-
Here are the first two of several Google hits:
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf (https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf)
https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/ (https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/)
I searched on 4(four) bit here, including some permutations, and got nothing.
-
I was talking about the search here, in eevblog.
But the Google search, while "working fine", doesn't pull up many makers of 4bit chips.
https://www.google.com/search?q=%224+bit%22+microcontroller+site:eevblog.com (https://www.google.com/search?q=%224+bit%22+microcontroller+site:eevblog.com)
Thanks, I hadn't thought of that. But it still doesn't pull up anything useful specifically. I guess I'm looking for someone who uses 4-bit MCUs and knows of various suppliers of 4 bit MCUs that may not show up on Google's radar. I've found two myself.
http://upt-ic.com/en/products.aspx?id=1 (http://upt-ic.com/en/products.aspx?id=1)
https://www.tritan.com.tw/en/Products/1/1141/4-bit-OTP-MCU (https://www.tritan.com.tw/en/Products/1/1141/4-bit-OTP-MCU)
Neither site provides data sheets with any ease.
-
Here are the first two of several Google hits:
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf (https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf)
https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/ (https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/)
I searched on 4(four) bit here, including some permutations, and got nothing.
I know of EM Micro. I haven't gotten a quote from them, but they don't seem to be cheaper than the 8 bit devices. Someone has pointed to an 8 bit device that is only $0.05 at LCSC, Padauk PMS150C. It can be run at 5V. So even if production is 1E6 units, I'm wondering if a 4-bit MCU is useful. Can the price be much lower?
-
I really doubt there is any economic advantage these days for 4 bit MCUs, 8 bit parts are SO cheap and there are so many of them on the market. Economies of scale are going to make them cheap while 4 bit would be a very niche product. Heck now you often see 32 bit ARM processors in stuff like refrigerators and coffee makers, often with internet connectivity.
-
If you want to find 4 bit MCUs in current use these days you need to look to Japan. They make no economic or power consumption sense for most people, but the last time I looked they were still seem to be used in Japan. I doubt anyone is developing significant new 4 bit designs, but many decades old MCUs still see high volume use.
-
There's a matter of market. Even small gadgets theses days tend to have a lot of features, so going for a very underpowered MCU may make sense only for a very small fraction of devices.
Even a simple remote with a few buttons and nothing else, no screen, maybe just a LED, unless it's strictly IR, will require significant software if it uses some kind of "modern" radio, and for this use case, there are many ultra-low power RF SOCs available, already containing a MCU core, and the RF front-end.
Then as as been mentioned, there is a matter of die area. On any decently modern node, a simple 4-bit CPU will take a *very small* die area and the pads will take up a lot more, meaning you'd have most of the die empty. It's worse than bad cost-wise. So you'd probably have to design something with extremely few IOs (possibly less than even the 6 typical on 8-pin devices), which would make the IC, as an off-the-shelf component, only good for very, very niche applications.
So it doesn't make much sense.
While a general-purpose 4-bit MCU would not make much sense these days, using a very simple 4-bit core inside a custom IC can.
-
Then as as been mentioned, there is a matter of die area. On any decently modern node, a simple 4-bit CPU will take a *very small* die area and the pads will take up a lot more, meaning you'd have most of the die empty. It's worse than bad cost-wise. So you'd probably have to
Not true. Most of the die size of a 4 bitter is eaten by rom and ram space. There used to be 4 bitters that were specialized in things like BCD arithmetic and lcd display driving (toshiba, sanyo , nec , hitachi). some of these are still around in things like microwaves , clocks and other stuff. They are typically applications where display functionality is numerical only (like microwaves, fridges , and stuff like that) or simple led's/lcd only. These things are made in old 0.25 or 0.13 technologis and run at very low clockspeed. either Rc oscillator or things like a 32.768KHz tuning fork (those things are not crystals). they do not use eprom but metal mask. development is done on emulators and they release straight to mask.
they are still out there.
-
I really doubt there is any economic advantage these days for 4 bit MCUs, 8 bit parts are SO cheap and there are so many of them on the market. Economies of scale are going to make them cheap while 4 bit would be a very niche product. Heck now you often see 32 bit ARM processors in stuff like refrigerators and coffee makers, often with internet connectivity.
Of course it will use a 32 bit chip for Internet connections. But in a $20 coffee maker or a $10 remote control, there isn't enough margin to toss the cost difference when buying a million processors.
-
I really doubt there is any economic advantage these days for 4 bit MCUs, 8 bit parts are SO cheap and there are so many of them on the market. Economies of scale are going to make them cheap while 4 bit would be a very niche product. Heck now you often see 32 bit ARM processors in stuff like refrigerators and coffee makers, often with internet connectivity.
Of course it will use a 32 bit chip for Internet connections. But in a $20 coffee maker or a $10 remote control, there isn't enough margin to toss the cost difference when buying a million processors.
The price of simple MCUs is dominated by the pin count. It really doesn't matter of the core is a 4 or an 8 bit. When you look at something like a remote control, though, ultra low power qualities really favoured 4 bit MCUs a few years ago. Now there are 8 bit options which can match the power consumption of those Japanese and Swiss 4 bit MCUs, based on technology originally developed for the watch industry.
-
There's a matter of market. Even small gadgets theses days tend to have a lot of features, so going for a very underpowered MCU may make sense only for a very small fraction of devices.
Not sure why you are making an emotional point, "underpowered" is not a technical evaluation. Either a given part is adequate to do the job or it isn't. They don't sell MCUs as "underpowered" or "overpowered".
Even a simple remote with a few buttons and nothing else, no screen, maybe just a LED, unless it's strictly IR, will require significant software if it uses some kind of "modern" radio, and for this use case, there are many ultra-low power RF SOCs available, already containing a MCU core, and the RF front-end.
"Significant"?? The vast majority of remotes are LEDs with some form of modulation to the data. That's hardly a need for an 8 bit MCU. Even a 4-bit MCU is "overpowered" for the task.
Then as as been mentioned, there is a matter of die area. On any decently modern node, a simple 4-bit CPU will take a *very small* die area and the pads will take up a lot more, meaning you'd have most of the die empty. It's worse than bad cost-wise. So you'd probably have to design something with extremely few IOs (possibly less than even the 6 typical on 8-pin devices), which would make the IC, as an off-the-shelf component, only good for very, very niche applications.
That's one reason I'm asking about this. Some people think the minimal MCUs priced under $0.25 are made on more recent processes. I'm thinking they use obsolete, fully depreciated equipment on processes that have very low static leakage power. Processes that have no trouble with 3.3V and even 5V I/Os.
So it doesn't make much sense.
While a general-purpose 4-bit MCU would not make much sense these days, using a very simple 4-bit core inside a custom IC can.
I once spoke with someone who designs toys, and they scrape every fraction of a penny, including resistors that are not absolutely essential in the product. So I'm thinking 4-bit devices are still used in such devices.
It would be inside a custom IC where the real estate is not so important. Such chips are going to be made on more recent processes and the additional die area is not so important.
-
I really doubt there is any economic advantage these days for 4 bit MCUs, 8 bit parts are SO cheap and there are so many of them on the market. Economies of scale are going to make them cheap while 4 bit would be a very niche product. Heck now you often see 32 bit ARM processors in stuff like refrigerators and coffee makers, often with internet connectivity.
Of course it will use a 32 bit chip for Internet connections. But in a $20 coffee maker or a $10 remote control, there isn't enough margin to toss the cost difference when buying a million processors.
The price of simple MCUs is dominated by the pin count. It really doesn't matter of the core is a 4 or an 8 bit. When you look at something like a remote control, though, ultra low power qualities really favoured 4 bit MCUs a few years ago. Now there are 8 bit options which can match the power consumption of those Japanese and Swiss 4 bit MCUs, based on technology originally developed for the watch industry.
Not trying to give anyone a hard time, but I'm asking what is actually used in the products. I'm also interested in hearing from people who have used 4 bit MCUs. So far, most of the comments have been speculative as far as I can tell.
-
I really doubt there is any economic advantage these days for 4 bit MCUs, 8 bit parts are SO cheap and there are so many of them on the market. Economies of scale are going to make them cheap while 4 bit would be a very niche product. Heck now you often see 32 bit ARM processors in stuff like refrigerators and coffee makers, often with internet connectivity.
Of course it will use a 32 bit chip for Internet connections. But in a $20 coffee maker or a $10 remote control, there isn't enough margin to toss the cost difference when buying a million processors.
There are Cortex M0 MCUs which are cheaper than the vast majority of the 8-bitters. Only if really digging the bottom you will find very limited 8-bitters which are cheaper than any 32-bitter, like Padauk PMS150C. Usually for the same price as normal 8 -bitter you can find 32 bit MCU with better peripherals, more FLASH and RAM, and often lower power consumption. EDIT: Though availability sucks with current chip shortage, and prices became all over the place.
-
That's one reason I'm asking about this. Some people think the minimal MCUs priced under $0.25 are made on more recent processes. I'm thinking they use obsolete, fully depreciated equipment on processes that have very low static leakage power. Processes that have no trouble with 3.3V and even 5V I/Os.
Older processes are not necessarily cheaper. People aren't making fine geometry MCUs when it would be cheaper to use a coarse geometry, and most MCUs don't need to be especially fast or low power to succeed. If you want really cheap stuff, there is a narrow band of geometries where the cost is optimised at any point in time. Try looking at foundry wafer prices (if you can find any realistic ones openly available) and you'll see.
-
There are Cortex M0 MCUs which are cheaper than the vast majority of the 8-bitters. Only if really digging the bottom you will find 8-bitters which are cheaper than any 32-bitter, like Padauk PMS150C. Usually for the same price as normal 8 -bitter you can find 32 bit MCU with better peripherals, more FLASH and RAM, and often lower power consumption.
Try negotiating for a large quantity, and see if you still think that's true.
-
There are Cortex M0 MCUs which are cheaper than the vast majority of the 8-bitters. Only if really digging the bottom you will find 8-bitters which are cheaper than any 32-bitter, like Padauk PMS150C. Usually for the same price as normal 8 -bitter you can find 32 bit MCU with better peripherals, more FLASH and RAM, and often lower power consumption.
Try negotiating for a large quantity, and see if you still think that's true.
Well, for example you could get this for 9 cents @ QTY of 500 in the pre-COVID times https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_Nuvoton-Tech-NUC029FAE_C2640145.html (https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_Nuvoton-Tech-NUC029FAE_C2640145.html)
-
Not trying to give anyone a hard time, but I'm asking what is actually used in the products. I'm also interested in hearing from people who have used 4 bit MCUs. So far, most of the comments have been speculative as far as I can tell.
that is going to be VERY hard to find. (both people and tools)
- the tools are very specific. it's not like you can grab a c-compiler and crank out code. it's assembly only. and the tools run on weird machinery : sun workstations, Vax/VMS, DOS and other stuff.
- to run the code you will need an emulator. for many 4 bitters there are no flash or even otp versions. Mask rom only. so you have an emulator that uses a bond-out chip. some of these bond-outs have room for a regular eprom on their back (piggyback devices). more modern emulators have the rom replaced by ram that is loadable from the host. those emulators are very expensive and you can only get them from the device makers.
- volumes are huge and development time is long. your code has to be fully debugged before you go to mask rom...
We had a 4bit core and emulated it on a xilinx FPGA board. the 'compiler' ran under dos (originally on VAX. was written in pascal for the vax). it was a macro assembler. once your code was finished the masks were made. the rom sat to one side of the chip so they would size the chip. if you needed more memory they would just increase the 'length'. it depended on volume. if you had low to medium volume they just did one rom mask. you divided the mask cost over the device , but the individual devices could have a lot of wasted rom space. every square millimeter counts. if you had large volume it was cheaper to run a full maskset because you would claim it back in silicon area. the cost of a wafer is fixed. if you can double the number of devices , you immediately halve the die cost. not that many of these devices do not get packaged ! there is no packaging cost. they simply bond the chip directly to the pcb (glob-top). so your cost is really raw silicon.
applications ?
interior light for a car. open door : light 'fades in fast'. close door : light stays on for some time , then fades out. when you unlocked using remote it would also do the fade-in thing.
blower for a car airconditioning. drive 3 phase BLDC with variable speed control.
clock/thermometer for kitchen oven. you could set temperature , start time. the entire chip was designed to run directly off 220 volts. the only external components needed were a series resistor , a small 10uF capacitor, the power relay and a tiny 600 ohm transformer to hook up the temperature probe and have it galvanically isolated ( as the chip ran off mains you needed that for the probe). the chip had a controlled rectifier on board: as soon as the line voltage start to reach like 10 volts they would open the "rectifier". basically did zero cross detection : activate the mosfet and as soon as we hit a specific point : open the mosfets. the resistor was only there for 'startup bleed'. chip directly drove a VFD. that thing was mass produced for years. the rom had several options. depending on what the customer paid for they zapped fuses during trim to disable certain features.
linear hall sensors : read the adc , do some filtering , apply trimming data that was stored during manufacturing (laser fuses) and then drive a dac to send analog signal back out.
-
Here are the first two of several Google hits:
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf (https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf)
https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/ (https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/)
I searched on 4(four) bit here, including some permutations, and got nothing.
I know of EM Micro. I haven't gotten a quote from them, but they don't seem to be cheaper than the 8 bit devices. Someone has pointed to an 8 bit device that is only $0.05 at LCSC, Padauk PMS150C. It can be run at 5V. So even if production is 1E6 units, I'm wondering if a 4-bit MCU is useful. Can the price be much lower?
if you could get them for free for 1E6 units you'd save 50k, how much engineering time are you going to spend cramming things into a 4bit mcu?
now if the production is 1E6 a month/week..
-
Here are the first two of several Google hits:
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf (https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf)
https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/ (https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/)
I searched on 4(four) bit here, including some permutations, and got nothing.
I know of EM Micro. I haven't gotten a quote from them, but they don't seem to be cheaper than the 8 bit devices. Someone has pointed to an 8 bit device that is only $0.05 at LCSC, Padauk PMS150C. It can be run at 5V. So even if production is 1E6 units, I'm wondering if a 4-bit MCU is useful. Can the price be much lower?
if you could get them for free for 1E6 units you'd save 50k, how much engineering time are you going to spend cramming things into a 4bit mcu?
now if the production is 1E6 a month/week..
When you use words like "crammed" into, you have decided the result before looking at the data.
How much MCU/memory does it take to run a basic microwave, coffee maker, remote control? That is just not an important consideration in the applications being discussed.
-
many micros had 2 or 4k rom. 8049, 8051 ... that is the plague these days. code bloat.
A smart traffic light controller using a 8048 had 700 bytes of firmware !
that 4 bit micro i was talking about had a 12 bit address bit.
intels 4004 as 12 bit address and they made a complete calculator with that !
-
Even my toothbrush uses an MSP430, while the simplicity of it's task could easily be done by a 4-bitter.
In this modern world there is no relation between what it costs to make something, and the amount of money you have to spend to obtain an object.
According to octopart, you can get the small MSP430FR2000IRLLR for 28ct in 1000+ quantities, but I'm guessing you can get them quite a lot cheaper if you skip the retailers and buy millions of them directly from the factory.
The padauk uC's is probably as low as you can get price wise. I think they went as low as 3ct, and I think even those are 8-bitters.
Another guess is that the market for 4-bitters is too small to reach really high quantities, and therefore the more universally usable 8-bitters may be cheaper.
Setting up a semiconductor factory is an expensive business, and to make a profit with 10ct parts, selling millions of them is not enough.
If a 4-bitter is only available in some old process technology and it's sleep current is too high, this may be prohibitive. Saving 5ct on a uC does not help if you need to spend an extra 10ct on a bigger battery.
Recently I saw a documentary from ASML, and they claimed that around 95% of the equipment they ever made (from the '80-ies) is still in use, and I believe that.
Once you make equipment very accurate, keep it clean (cleanroom!) and have regular maintenance, it does not wear anymore and life is virtually infinite. With a perfect oil film there is no mechanical contact, and thus no wear. It's small imperfections, oil contaminated with dust and such that cause wear. (Edit: apparently no oil in semiconductor equipment, but the general principle still stands: better fits in higher quality equipment lowers wear and increases endurance)
In the end this means a lot of the lower-tier stuff is made on quite old equipment, but I don't know how that relates to 4 versus 8 -bitters. :-[
-
What does it even mean for a CPU to be "4 bit"?
Surely if it's going to be useful then RAM addresses are going to have to be at least 8 bits, if not 12 or 16. The same with program code addresses, if they are different. Maybe I/O space can get away with 4 bits (if it is different to RAM).
Surely instructions are bigger than 4 bits too?
A 4 bit ALU? Well, there's the Z80.
4 bit accumulator? I guess so. You can deal with booleans, decimal or hex digits.
Given all the things in it that *can't* be 4 bit, is it really that much of a savings over an 8051, PIC, even 6800 or 8080?
-
What does it even mean for a CPU to be "4 bit"?
the ALU is 4 bit. code words are typically 8 , 10 or 12 bit. there are some very weird architectures out there. jump with offset. sometimes the instruction set is not linear. often used instructions are 3 bit , the fourht bit acts . the fourth bit indicates these instructions need an additional bus cycle to fetch another 4 bits...
data ram is 4 bit. like i said these processors are geared towards decimal number processing. clocks, weighing scales , meters. anything where the user interface is digit based. some have A/D that measure directly in BCD.
-
With a perfect oil film there is no mechanical contact, and thus no wear. It's small imperfections, oil contaminated with dust and such that cause wear.
Oil ? IN A FAB ?!? are you CRAZY ? it gets EVERYWHERE. And it spreads like the plague. contaminate your machines and your downtime will be horrific.
No oil in a fab. Krytox PTFE, yes. Oil ? no way ! The only oil in a fab is in the high voltage tank for the ion implanters. and that sits outside the cleanroom.
-
What does it even mean for a CPU to be "4 bit"?
Surely if it's going to be useful then RAM addresses are going to have to be at least 8 bits, if not 12 or 16. The same with program code addresses, if they are different. Maybe I/O space can get away with 4 bits (if it is different to RAM).
Surely instructions are bigger than 4 bits too?
A 4 bit ALU? Well, there's the Z80.
4 bit accumulator? I guess so. You can deal with booleans, decimal or hex digits.
Given all the things in it that *can't* be 4 bit, is it really that much of a savings over an 8051, PIC, even 6800 or 8080?
Yeah, not sure either. Maybe it's mainly a 4-bit ALU with a 4-bit internal data path, with most instructions, even the simplest ones, taking a number of cycles to complete. Could have a look at the HP Saturn CPUs to get an idea of what that could be. Could not find info on the kind of process they were using for those, but given the application and the date, I would venture something > 1 µm.
Would probably save some resources, but again the point for a standalone (meaning not a core that you can include in some ASIC along with other stuff) MCU using any decently modern process node sounds rather moot.
-
The ultra-cheap 4-function calculators use 4-bit mask ROM MCUs running at a few kHz.
-
The ultra-cheap 4-function calculators use 4-bit mask ROM MCUs running at a few kHz.
They must have several KB of program code ROM, a PC big enough to address it (12 bits?), instructions big enough to call subroutines in different parts of it, a stack deep enough to hold a couple of levels of return address the same size as the PC.
-
Well, for example you could get this for 9 cents @ QTY of 500 in the pre-COVID times https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_Nuvoton-Tech-NUC029FAE_C2640145.html (https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_Nuvoton-Tech-NUC029FAE_C2640145.html)
Hehe, yes that was then...
Now, the cheapest MCU in stock from Nuvoton at lcsc is 8-bit
100+ US$0.4527 58048 In Stock MS51FB9AE 16KB -40℃~+105℃ 2.4V~5.5V 51Series 1@x6ch/16bit 1@x8ch/12bit 1 1.25KB 4MHz~32MHz TSSOP-20
-
I have found a very small number of 4bit MCUs still on the market, but not as many as I expected. Aren't they still used in coffee makers, remote controls, microwave ovens, toys, etc?
That depends what you mean by 'on the market' :)
For distributor sales and 'not massive' sales volumes, most designers these days use flash/MTP MCUs and that means they follow the process nodes the big chip vendors use.
Even OTP MCUs ( of all bit-sizes) are fading from the landscape, as the process nodes become EOL.
LCSC still lists a few OTP parts for 6c/100, and MTP parts start about 10c/100 - users do not care if the cores inside those are 4 or 8 bit data and 8/12/14/16 bit opcodes.
-
What does it even mean for a CPU to be "4 bit"?
Surely if it's going to be useful then RAM addresses are going to have to be at least 8 bits, if not 12 or 16. The same with program code addresses, if they are different. Maybe I/O space can get away with 4 bits (if it is different to RAM).
Surely instructions are bigger than 4 bits too?
A 4 bit ALU? Well, there's the Z80.
4 bit accumulator? I guess so. You can deal with booleans, decimal or hex digits.
Given all the things in it that *can't* be 4 bit, is it really that much of a savings over an 8051, PIC, even 6800 or 8080?
Generally, a CPU's bit width is the width of its data path. That makes the Z80 an 8 bit CPU despite the 4 bit ALU in early versions.
In reality its not so easy, there are always exceptions.
Was EDSAC a 1, 17 or 35 bit processor?
Is the MC68008 an 8, 16 or 32 bit processor?
There is a RISC V implementation (SERV) that processes 1 bit at a time but it's still a 32 bit CPU.
Bit width, like MHz, is a poor metric to measure performance or capability of a processor.
-
What does it even mean for a CPU to be "4 bit"?
Surely if it's going to be useful then RAM addresses are going to have to be at least 8 bits, if not 12 or 16. The same with program code addresses, if they are different. Maybe I/O space can get away with 4 bits (if it is different to RAM).
Surely instructions are bigger than 4 bits too?
A 4 bit ALU? Well, there's the Z80.
4 bit accumulator? I guess so. You can deal with booleans, decimal or hex digits.
Given all the things in it that *can't* be 4 bit, is it really that much of a savings over an 8051, PIC, even 6800 or 8080?
Generally, a CPU's bit width is the width of its data path. That makes the Z80 an 8 bit CPU despite the 4 bit ALU in early versions.
In reality its not so easy, there are always exceptions.
Was EDSAC a 1, 17 or 35 bit processor?
Is the MC68008 an 8, 16 or 32 bit processor?
There is a RISC V implementation (SERV) that processes 1 bit at a time but it's still a 32 bit CPU.
Bit width, like MHz, is a poor metric to measure performance or capability of a processor.
It's pretty fundamental (at least to me) that the bitness of a computer is a property of the instruction set, not the implementation. All CPUs that run the same instruction set have the same bitness. So the 68008, 68000, 68020 are all 32 bit. And all RV32 implementations are 32 bit.
It's tricky in the case of the "8 bit" microprocessors such as the 8080, 6800, z80, 6502, 6809 to decide whether they are 8 bit or 16 bit because they all have a mix of 8 and 16 bit features.
But whatever the answer is, it's a question that must be answered by looking at the programmer's manual, NOT at the physical circuit or the packaging.
Look at the z80. It has a lot of 16 bit registers. You can push and pop 16 bit registers. You can {add,adc,sbc} (but not sub) {bc,de,sp} to {hl,ix,iy} or add {hl,ix.iy} to themselves. There is 16 bit {inc,dec} on all registers. You can move {hl,ix,iy} to sp. You can load a 16 bit constant into any 16 bit register. You can load/store between an absolute address from any 16 bit register. You can exchange hl with de, or {hl,ix,iy} with the top of stack. You can exchange all of {bc,de,hl} with their shadow registers at the same time.
Other than the above move to sp or swapping hl and de, there are no 16 bit register move instructions -- you have to use two 8 bit move instructions ("ld" in z80 mnemonics). There is no 16 bit compare. There is no 16 bit load or store except to an absolute location -- you can't use any of the register indirect or indexed addressing modes. You have to do two 8 bit transfers, and adjust the pointer or offset between.
It's certainly much easier / shorter / faster to deal with 16 bit variables on the 8080 and z80 than on the 6502. But I think the killer, which alone disqualifies it as a 16 bit ISA, is that there is no 16 bit compare and the 16 bit arithmetic operations that do exist don't set flags in the way 8 bit ones do.
The 6809 on the other hand has 16 bit add and subtract and compare (only memory to register, not register to register, but that's the same with 8 bit). You can load or store any 16 bit register using the full set of addressing modes. You can move or swap between any pair of 16 bit registers. The only thing really lacking 16 bit operations is AND/OR/XOR and shift/rotate.
There is very little daylight between the 6809 (an "8 bit" CPU) and the 8088 (a "16 bit" CPU). The biggest difference is the segment registers.
-
Here are the first two of several Google hits:
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf (https://www.emmicroelectronic.com/sites/default/files/products/datasheets/em6607_ds.pdf)
https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/ (https://www.electronics-lab.com/bit4-is-a-4bit-microcontroller-fully-programmable-with-only-three-buttons/)
I searched on 4(four) bit here, including some permutations, and got nothing.
I know of EM Micro. I haven't gotten a quote from them, but they don't seem to be cheaper than the 8 bit devices. Someone has pointed to an 8 bit device that is only $0.05 at LCSC, Padauk PMS150C. It can be run at 5V. So even if production is 1E6 units, I'm wondering if a 4-bit MCU is useful. Can the price be much lower?
You are not buying 4 bit microcontrollers from these guys. You buy 4 bitters directly from the semiconductor company, because the mask ROM.
And they don't really make sense unless it is a chip-on-board. I have a quotation somewhere for a MC34063 clone for 4 cents a piece, in a SO8 package for a single reel. Your microcontroller should be below this in price, somewhere in the 0.5-1 cent region I believe. And I wouldn't be surprised if it wouldn't make any sense to use it. Do you know prices of the 8 bit 8051 clones and STM8s in the millions?
-
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.
-
megaAVR core as many other 8-bitters have more gates than Cortex M0 core (12k), so one could argue that spending silicon on making those is a waste. Only heavily gate count optimized 8 bit cores have a significant advantage in this regard.
-
The ultra-cheap 4-function calculators use 4-bit mask ROM MCUs running at a few kHz.
They must have several KB of program code ROM, a PC big enough to address it (12 bits?), instructions big enough to call subroutines in different parts of it, a stack deep enough to hold a couple of levels of return address the same size as the PC.
To get an idea of the kind of MCU these 4-function calculators may have: http://files.righto.com/calculator/TI_calculator_simulator.html (http://files.righto.com/calculator/TI_calculator_simulator.html) (btw. this chip has only 320 11-bit words of program memory).
The MCU used here is not general purpose, it is specifically tailored for calculators. I don't know what those ultra-cheap 4-function calculators use these days, but I wouldn't be surprised if they use designs created several decades ago.
-
The ultra-cheap 4-function calculators use 4-bit mask ROM MCUs running at a few kHz.
They must have several KB of program code ROM, a PC big enough to address it (12 bits?), instructions big enough to call subroutines in different parts of it, a stack deep enough to hold a couple of levels of return address the same size as the PC.
To get an idea of the kind of MCU these 4-function calculators may have: http://files.righto.com/calculator/TI_calculator_simulator.html (http://files.righto.com/calculator/TI_calculator_simulator.html) (btw. this chip has only 320 11-bit words of program memory).
Very interesting, thanks!
So, no doubt, the actual chip at the time was microcoded or hardware sequenced using a 4 bit data path and ALU but that's just implementation, and a later fully-compatible chip could implement the same ISA and run the same programs much more quickly using a parallel implementation instead of a serial one.
From the point of view of the programmer writing those 320 instructions -- and this is what determines the number of instructions that need to be written and executed, and the program size, this ...
- is a 44 bit chip with three 44 bit registers and three 11 bit mask registers, plus a mask+constant ROM
- instructions are 11 bits, large enough to contain a 9 bit address for an instruction to jump to
- a single instruction can add, compare, move, exchange an entire 44 bit register with another one. There are both binary and BCD add and subtract instructions.
- ALU instructions contain a 4 bit field that selects one of 16 digit mask and/or constant combinations. You can operate on the whole register (with carries propagating if it's an add), or just on the 2 exponent digits (rightmost), or just on the 9 mantissa digits (leftmost).
- there are also "mask" field values that select just the mantissa digits and also provide a constant "1" value, or just the exponent digits and also provide a constant "1" value, or just the least significant mantissa digit and a constant "1" value. And a couple of others which are more mysterious.
If z80 is an 8 bit ISA, not a 4 bit one (and it is!) then this is a 44 bit ISA.
-
In the old days when transistors were big and expensive, there was a 80386, which was produced in an "SX" and in an "DX" variant. They ran the same code, but the "SX" only had an 16 bit external databus while the "DX" variant had a 32 bit databus to the outside world.
-
Texas Instruments TMS1000 springs to mind for some reason.
-
The reason you don't find many 4 bitters in the 'market' is because they are ROM devices. There are very few, if any, that feature user programmable code space. You have to deal with the manufacturer directly.
-
In the old days when transistors were big and expensive, there was a 80386, which was produced in an "SX" and in an "DX" variant. They ran the same code, but the "SX" only had an 16 bit external databus while the "DX" variant had a 32 bit databus to the outside world.
And the 8086 had an 8088 version (FAR more widely used) that had only an 8 bit data bus.
And the 68000 had a 68008 version (almost never used .. the Sinclair QL is an exception) that had an 8 bit data bus.
And the 68020 could work on an 8 bit, 16 bit, or 32 bit bus.
And the ARM7TDMI could use either a 32 bit or 16 bit data bus. The main reason for the Thumb ISA being developed was not code size, but speed when a 16 bit bus was used.
-
I just saw Dave's old teardown of a toothbrush again:
NL
12:04 / 32:53
EEVblog #284 - Braun Toothbrush Teardown
https://www.youtube.com/watch?v=JJgKfTW53uo (https://www.youtube.com/watch?v=JJgKfTW53uo)
Curiously, this has such an EM6600 4-bitter, while my newer toothbrush has an MSP430, and I wonder why?
Maybe they got a better offer from TI?
Maybe all of Brauns engineers ate too much lead, went drooling and cross eyed and they needed TI's reference design to get something going again:
https://www.ti.com/lit/ug/tiduaz7/tiduaz7.pdf (https://www.ti.com/lit/ug/tiduaz7/tiduaz7.pdf)
Maybe they had some disagreement with that EM factory or their development tools?
Maybe they preferred a flash based controller that can be customized to different toothbrushes and thus reduce inventory?
Maybe they don't want to be dependent on one uC manufacturer?
This one shows a 430G2332 @ 06:50. https://www.youtube.com/watch?v=qGovZykUF68 (https://www.youtube.com/watch?v=qGovZykUF68)
-
Curiously, this has such an EM6600 4-bitter, while my newer toothbrush has an MSP430, and I wonder why?
Maybe they got a better offer from TI?
Maybe, but, just maybe, it's also from the fact the EM6600 series, at least from what I got, is mask-ROM only, which would make it much more cumbersome when firmware changes, and would make firmware updates impossible. While I don't think those toothbrushes can ever be updated by end-users, that would still make any change in factory much more flexible. But there could be myriads of other reasons.
-
Curiously, this has such an EM6600 4-bitter, while my newer toothbrush has an MSP430, and I wonder why?
Maybe they got a better offer from TI?
Maybe, but, just maybe, it's also from the fact the EM6600 series, at least from what I got, is mask-ROM only, which would make it much more cumbersome when firmware changes, and would make firmware updates impossible. While I don't think those toothbrushes can ever be updated by end-users, that would still make any change in factory much more flexible. But there could be myriads of other reasons.
MSP430 is a very decent and compiler-friendly true 16 bit ISA: 16 bit addresses, 16 bit arithmetic, 16 bit instructions. And nice compact code. I've actually been thinking about seeing how it would work as a "bytecode" for 6502 -- see how large an emulator would be, and what slow-down vs native code. It's hard to beat Woz's SWEET16 on either metric, but there isn't optimising gcc/llvm for that! Both should be much faster and also more compact than UCSD P-code, JVM, or the like (interpreting wasm?)
Anyway .. EM6600. I found a data sheet for EM6607. 2k x 16 bit ROM, 96 x 4 bit RAM, 5 x 4 bit I/O ports, 72 instructions, 2 clocks (32 KHz?) per instruction. EM6626 expands ROM to 4k x 16, and RAM to 128 x 4. EM6600 seems to have 80 x 4 RAM.
EM6607 datasheet shows "RAM" addresses 96-126 used for I/O, interrupt, timer etc. So how does EM6626 get 128 x 4 RAM? 8 bit addresses?
I didn't find the instruction set yet ... is it secret?
-
I have some tmp47 toshiba 4bit chips with OTP EPROM technology.
They look A lot like an 8bit PIC crossed with an 8080. Instruction words longer than data words, with registers and alu at 4bits wide. H and L 4bit registers linked together to make a HL pointer that can address 4bit data memory. 4bit wide PORTS, too.
I had high hopes of doing obscure things, but never got past the search for tools. There isn’t even a free official assembler. All very 1980s. And then the memory wants to be programmed like an 80s multi-voltage eprom, too.
Has anybody ever seen a flash-based 4bit chip?
-
I have some tmp47 toshiba 4bit chips with OTP EPROM technology.
They look A lot like an 8bit PIC crossed with an 8080. Instruction words longer than data words, with registers and alu at 4bits wide. H and L 4bit registers linked together to make a HL pointer that can address 4bit data memory. 4bit wide PORTS, too.
I had high hopes of doing obscure things, but never got past the search for tools. There isn’t even a free official assembler. All very 1980s. And then the memory wants to be programmed like an 80s multi-voltage eprom, too.
Has anybody ever seen a flash-based 4bit chip?
nope. the problem is the need for a floating gate in anything e(e)prom/flash. That is "costly" process and mask wise. the memory array is large. for cost sensitive stuff that is prohibitive.
assemblers ? the toolchains (if you can call it that...) were mainly written in fortran77 and ran on PDP or VAX... some were available on intel MDS under ISIS and or CP/M . some were on IBM370. there were other systems like motorola's Exorciser or they were custom machines altogether. NEC, Toshiba, Sanyo , Hitachi, National semi all had their own computers (most 8080/8085 based) and came with the required software.
These early development systems were typically S100 bus (like...) like the intel MDS or Starplex. you would plug in target CPU boards. the host cpu (Z80 , 8080 8085) ran the toolchain and 'host' board could execute it. they were hardware emulators with full breakpoint and trace capability. Old intel and National semi (early 80's) typically have lots of documentation on those systems. I used the MDS for 8051 development (PL/M compiler , A51 assembler and including the emulator pod) and later an Isis machine for i960. I have seen a starplex, but never used it.
http://www.1000bit.it/support/manuali/national%20semi%20conductor/starplex.pdf (http://www.1000bit.it/support/manuali/national%20semi%20conductor/starplex.pdf)
Many of these devices used a single metal layer. some had double-exposure . the chips were made ready with the rom 'unmasked' when the rom mask arrived a second exposure was done to pattern the rom. so they had half-processed material and would combine the metal mask from the base mask + the rom mask.
-
Rreally, I don't think there's any place in the market for 4-bit programmable mcus.
Perhabs large-scale ROM mask mcus for toys and such, but not flash/eeprom.
The're quite a lot of very cheap 8-bitters around, like the famous 3-cent Padauk mcus.
-
Rreally, I don't think there's any place in the market for 4-bit programmable mcus.
Perhabs large-scale ROM mask mcus for toys and such, but not flash/eeprom.
The're quite a lot of very cheap 8-bitters around, like the famous 3-cent Padauk mcus.
The 4-bitters were never e(e)prom or flash. Mask rom only.
-
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
-
Curiously, this has such an EM6600 4-bitter, while my newer toothbrush has an MSP430, and I wonder why?
The MSP430 that goes into most toothbrushes in a 0.9V MCU. This means it can run from a single NiMh cell, when its near to exhaustion. Most other 0.9V MCUs are extremely slow. I think they wanted something up to the job of motor control in this application. A lot of brushes now use lithium batteries and don't have the same voltage constraint.
-
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.
-
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.
-
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
-
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).
-
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
-
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.
-
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 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.
-
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.
-
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.
-
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 :)
-
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.
-
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.
-
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…
-
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.
-
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?
-
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?
-
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.
-
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?
-
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.
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.
-
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.
-
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.
-
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.
-
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. :-( :-(
-
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.
-
I haven't thought every aspect of complying with the standard through regarding exact-width types, but I'm still "almost" sure that not being able to access memory as 8-bit chunks and using the (u)int8_t types would break something. And I'm of course not talking about (u)int_least8_t. Haven't taken the time to find a good example as an illustration though.
Now if anything, even if that were possible without breaking any aspect of the standard, that would imply emitting convoluted assembly for a lot of cases, which IMO makes it a bit unpractical.
One of the questions that pops up (among a bunch) is regarding the sizeof operator.
sizeof(char) is 1 by definition, if I'm not mistaken. 'char' is thus the smallest unit of memory for sizeof. In cases for which (u)int8_t is smaller than char (let's assume a 9-bit char), what is sizeof((u)int8_t) ?
What is sizeof(int8_t[10])? Is it respectively 1 and 10? Or is it 1 in the first case (because it's the minimum size) and 9 in the second case, considering the array is "packed"? In the latter case, the usual sizeof(a)/sizeof(a[0]) to get the number of items would not work.
I admit I am not even sure how arrays would be implemented in this case, aren't the items supposed to be packed? If so, if int8_t[10] were actually an array of 9-bit words (keeping my example), then would it not break something somehow? It looks confusing. There may be a clear answer in the std that I haven't seen yet. But if, still in this example, int8_t is actually implemented as a masked 9-bit word under the hood (which I suppose is what you have in mind and what may be implied by the std), then this size matter kinda bugs me.
That may end up being one of those aspects of the C std that will eventually get cleared up. Time will tell.
-
Is it a requirement that the addressable unit in C be an 8 bit byte?
I'm not sure what the standards say, but there are numerous compilers where the addressable unit is 16 bits or more, because the machine is incapable of addressing smaller units. DSPs are the typical example of this.
-
One of the questions that pops up (among a bunch) is regarding the sizeof operator.
sizeof(char) is 1 by definition, if I'm not mistaken. 'char' is thus the smallest unit of memory for sizeof. In cases for which (u)int8_t is smaller than char (let's assume a 9-bit char), what is sizeof((u)int8_t) ?
1, clearly. Or 2 if you're using 6 bit char on your 36 bit machine (which used to be common, but the current C standard does not allow I think)
What is sizeof(int8_t[10])? Is it respectively 1 and 10? Or is it 1 in the first case (because it's the minimum size) and 9 in the second case, considering the array is "packed"?
I don't see how it can be 9 -- that's not big enough. It could be 12, right? Three 36 bit words. At least if it's in a struct? Maybe not a bare array.
I admit I am not even sure how arrays would be implemented in this case, aren't the items supposed to be packed? If so, if int8_t[10] were actually an array of 9-bit words (keeping my example), then would it not break something somehow? It looks confusing. There may be a clear answer in the std that I haven't seen yet. But if, still in this example, int8_t is actually implemented as a masked 9-bit word under the hood (which I suppose is what you have in mind and what may be implied by the std), then this size matter kinda bugs me.
It has to be masked, right? Either in 36 bits or in (least waste) 9. Sizes have to be an even number of "bytes", and calculations have to be "as if" it was actually stored in 8 bits.
So an array would be 4 masked 9 bit items in each word, not 4 packed 8 bit items and 4 bits unused at the end.
-
One of the questions that pops up (among a bunch) is regarding the sizeof operator.
sizeof(char) is 1 by definition, if I'm not mistaken. 'char' is thus the smallest unit of memory for sizeof. In cases for which (u)int8_t is smaller than char (let's assume a 9-bit char), what is sizeof((u)int8_t) ?
What is sizeof(int8_t[10])? Is it respectively 1 and 10? Or is it 1 in the first case (because it's the minimum size) and 9 in the second case, considering the array is "packed"? In the latter case, the usual sizeof(a)/sizeof(a[0]) to get the number of items would not work.
afaik the (u)intX_t types must only be defined on platforms that directly support them with no padding, so a platform with 9bit chars won't have int8_t
-
One of the questions that pops up (among a bunch) is regarding the sizeof operator.
sizeof(char) is 1 by definition, if I'm not mistaken. 'char' is thus the smallest unit of memory for sizeof. In cases for which (u)int8_t is smaller than char (let's assume a 9-bit char), what is sizeof((u)int8_t) ?
1, clearly. Or 2 if you're using 6 bit char on your 36 bit machine (which used to be common, but the current C standard does not allow I think)
What is sizeof(int8_t[10])? Is it respectively 1 and 10? Or is it 1 in the first case (because it's the minimum size) and 9 in the second case, considering the array is "packed"?
I don't see how it can be 9 -- that's not big enough. It could be 12, right? Three 36 bit words. At least if it's in a struct? Maybe not a bare array.
Uh? Yes it is. I was assuming a target on which the smallest addressable unit was 9-bit.
If the compiler "packs" the array, 9 9-bit words are enough to store 10 8-bit words.
I don't really see anything in the standard that would prevent a compiler for implementing arrays like this, although this is again one of the things that seem a bit confusing there. (Of course that wouldn't be very efficient, but that's another matter.)
-
One of the questions that pops up (among a bunch) is regarding the sizeof operator.
sizeof(char) is 1 by definition, if I'm not mistaken. 'char' is thus the smallest unit of memory for sizeof. In cases for which (u)int8_t is smaller than char (let's assume a 9-bit char), what is sizeof((u)int8_t) ?
What is sizeof(int8_t[10])? Is it respectively 1 and 10? Or is it 1 in the first case (because it's the minimum size) and 9 in the second case, considering the array is "packed"? In the latter case, the usual sizeof(a)/sizeof(a[0]) to get the number of items would not work.
afaik the (u)intX_t types must only be defined on platforms that directly support them with no padding, so a platform with 9bit chars won't have int8_t
Good, we're moving forward. =)
Are you sure that (u)int8_t type is not mandatory in the std though and thus one can't avoid implementing it? Which, if such platform existed, would just mean that any C compiler for it couldn't be compliant past C89.
-
One of the questions that pops up (among a bunch) is regarding the sizeof operator.
sizeof(char) is 1 by definition, if I'm not mistaken. 'char' is thus the smallest unit of memory for sizeof. In cases for which (u)int8_t is smaller than char (let's assume a 9-bit char), what is sizeof((u)int8_t) ?
What is sizeof(int8_t[10])? Is it respectively 1 and 10? Or is it 1 in the first case (because it's the minimum size) and 9 in the second case, considering the array is "packed"? In the latter case, the usual sizeof(a)/sizeof(a[0]) to get the number of items would not work.
afaik the (u)intX_t types must only be defined on platforms that directly support them with no padding, so a platform with 9bit chars won't have int8_t
Good, we're moving forward. =)
Are you sure that (u)int8_t type is not mandatory in the std though and thus one can't avoid implementing it? Which, if such platform existed, would just mean that any C compiler for it couldn't be compliant past C89.
from the last free C17 draft:
7.20.1.1 Exact-width integer types
1
The typedef name int N _t designates a signed integer type with width N, no padding bits, and a
two’s complement representation. Thus, int8_t denotes such a signed integer type with a width of
exactly 8 bits.
2
The typedef name uint N _t designates an unsigned integer type with width N and no padding bits.
Thus, uint24_t denotes such an unsigned integer type with a width of exactly 24 bits.
3
These types are optional. However, if an implementation provides integer types with widths of
8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement
representation, it shall define the corresponding typedef names.
-
OK thanks. I had to re-open the C99 to see what it said too. And indeed, from what I get, actually all integer types from stdint.h seem to be optional.
For some reason, I remembered (falsely) that at least the 8, 16 and 32-bit types were mandatory.
But interestingly, I didn't find any mention of this non-padding rule in C99.
So, I was onto something but the conclusion is (slightly) different: for what I can deduce from the wording in the std (at least in C17), for any platform not being able to support 8-bit words without padding, the stdint exact-width types multiple of 8-bit would just not be available. Which would effectively make supporting them... non-compliant.
-
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.
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.
I wasn't asking how many programs print. I was asking how many programs use the C library printf code. That was the context of the reference to copying data from ROM to RAM. Then your example clearly prints directly from the ROM.
-
Personally, I never used one. Can I get any datasheet?
-
I wasn't asking how many programs print. I was asking how many programs use the C library printf code. That was the context of the reference to copying data from ROM to RAM. Then your example clearly prints directly from the ROM.
on an 8-bitter with constrained resources like an 8051 and likes ? nobody in his right mind would use the printf library. it is too large. and it most likely cannot handle the duality of printing from rom and ram.
i analysed the C-compilers from Mikroe once. they have a "helper" function that copies the string from rom to a ram buffer, and then pass it to printf. The problem is the variable list of arguments in printf .
printf("blah") <- clearly hardcoded string
const blah_string "Blabla"
print blah_string <- still hardcoded as it is a constant
blabla char[11] = "more blabla \0" <- this starts getting tricky ... you need to analyse all code to see if blabla ever gets modified. if not, you can plonk it in rom ... otherwise ram
printf ("blabla %1",some_number) <- well.. blabla can be stuffed in rom while the integer needs a conversion routine to ascii string and that has to be stored somewhere and memory allocated for it... so one portion comes from om , another from ram...
that is getting tricky for the printf library. on a von Neumann machine it doesn't matter, it's all flat memory and there is only one machine language operation for access.. in a Harvard machine the opcodes are different... it becomes spaghetti very quickly.
So the compiler builders resort to trickery where they allocate ram and build the complete string , constants and all in a ram buffer first.... then send it to a uniform handler that writes it to the output buffer. the problem is ... you only have 128 bytes of ram (or less) on those machines. so you end up eating half of your rom for the printf and half of the ram to send out a string of 80 characters ...
Many programming languages for these machines do not have a printf. you roll your own. and you constrain it enough so that you have a routin to print form rom and one from ram. you do the splitting and optimise it for the least amount of ram usage.
-
that is getting tricky for the printf library. on a von Neumann machine it doesn't matter, it's all flat memory and there is only one machine language operation for access.. in a Harvard machine the opcodes are different... it becomes spaghetti very quickly.
So the compiler builders resort to trickery where they allocate ram and build the complete string , constants and all in a ram buffer first.... then send it to a uniform handler that writes it to the output buffer. the problem is ... you only have 128 bytes of ram (or less) on those machines. so you end up eating half of your rom for the printf and half of the ram to send out a string of 80 characters ...
Many programming languages for these machines do not have a printf. you roll your own. and you constrain it enough so that you have a routin to print form rom and one from ram. you do the splitting and optimise it for the least amount of ram usage.
This is where C++ cout "foo" << someInt << "bar" << endl is better. Properly implemented, this doesn't need to assemble the whole line anywhere, and each part can come from ROM, RAM, or be converted in a minimal buffer as appropriate.
The same goes for the C++ overloaded single-argument print() functions in Arduino, designed for use on microcontrollers with barely any RAM.
People only like actual printf() because it's more convenient to type a format string with %s in it, and it's less code at the caller (only one function call).
When the printf format string is constant, a compiler can split it up into print_literal_string_from_ROM(); print_integer(); print_literal_string_from_ROM(); And then you don't drag in the long long or floating point conversions that you're not using.
-
There are several ways of handling this problem of data access.
The first obvious (but not efficient as far as RAM use is concerned, which could be a problem on small targets) way is to put all "constants" in data memory (RAM) so that the CPU never has to access anything in, say, Flash memory during normal execution of the code.
This can be "trivially" done. A C compiler isn't required to put constants in Flash memory (or generally speaking, in some kind of read-only memory.)
All that can be done writing an appropriate linker script. Then the "startup code" would have to copy all constants in RAM, just like it does for initializing non-zero global variables, using specific instructions for doing so. Most Harvard architectures used these days are modified Harvard, and there is always some kind of bridge between the different memory areas, even when it's not fully transparent.
The second way, which is what was required on older 8-bit PICs, for instance, is that you need to use specific instructions to access Flash memory - and the compiler needs to handle two types of pointers with specific qualifiers. Not very nice, but the plus side is that you don't waste RAM as in the above solution, and you have full control over memory access. Yes, as inconvenient as it can be, I consider this also a benefit for security reasons.
And that said, using printf() on small targets when all you need are simple formats for displaying integers and maybe floating point numbers, is rarely a good idea. Writing your own conversion functions is not difficult and will be much more efficient. And, once you have written them, you can reuse them as often as you want.
-
The first obvious (but not efficient as far as RAM use is concerned, which could be a problem on small targets)
well that is the problem on these small machines.
printf ('Hello %i world %s : %i' , 128, q , b)
passing a constant integer , a string (could be ram , could be rom...) and a ram integer
very difficult to unroll, so they simply build it in a ram buffer, then pass that off to the output handler. the output handler becomes simple and short because only one source and one target , but you eat memory... of which you have very little
-
A bit late to the show, but closer to the original topic: Has anybody ever worked with the Atmel MARC4? I had my eyes on that one for several projects, but its use was never justified by the expected savings. Atmel discontinued this family in 2015.
https://media.digikey.com/pdf/Data%20Sheets/Atmel%20PDFs/T48C510.pdf
Digikey lists several devices as 0 stock / discontinued. Some MCU core with RF interface.
-
A bit late to the show, but closer to the original topic: Has anybody ever worked with the Atmel MARC4?
Never heard of them. I'll have a look at the DS out of curiosity.
Has anyone ever written assembly for one of the HP Saturn CPUs I mentioned earlier? Those were, at least in my memory, pretty interesting and the assembly was rather nice. I did write routines in assembly on the HP28s and HP48 back in the days.
-
SiliconWizard, after three decades my HP48SX is still in use, albeit rarely. I only ever was a user of other people's low level code (Sokoban...). I used the high level language to write small programs, e.g. transmission line calculations and such.
There are a bunch of emulators available, in case anybody wants to dabble with that architecture.
-
A bit late to the show, but closer to the original topic: Has anybody ever worked with the Atmel MARC4? I had my eyes on that one for several projects, but its use was never justified by the expected savings. Atmel discontinued this family in 2015.
https://media.digikey.com/pdf/Data%20Sheets/Atmel%20PDFs/T48C510.pdf
Digikey lists several devices as 0 stock / discontinued. Some MCU core with RF interface.
I can't say I worked with it. I did take a hard look at trying to use it, but that was around 10 years ago and even then they were not doing much to support it. I don't recall ever finding the tools for it.
-
gnuarm, thanks to your comment, I figured out that my interest in MARC4 was over 20 years ago. At that time I was still an inmate at a large American medical devices manufacturer. Paying real money to the manufacturer for the development tools (hard- and software) was much more common then.