Inheriting from a class and overriding user-defined conv. operators

[bitrex]

Consider the following class "UFixed", which implements some
user-defined conversion operators to (explicitly) convert the type to
double, float, and "IntegerTypes":

<https://github.com/Pharap/FixedPointsArduino/blob/master/src/FixedPoints/UFixed.h>

I'd like to derive a class from it that has materially equivalent
functionality to the parent class, except where those conversions are
non-explicit. Truth is I don't use inheritance very much outside of
defining interfaces and I don't really know where to start implementing
that to end up with anything nice.

Merry C++hristmas y'all!

[Öö Tiib]

On Monday, 25 December 2017 03:44:36 UTC+2, bitrex wrote:
> Consider the following class "UFixed", which implements some
> user-defined conversion operators to (explicitly) convert the type to
> double, float, and "IntegerTypes":
>
> <https://github.com/Pharap/FixedPointsArduino/blob/master/src/FixedPoints/UFixed.h>
>
> I'd like to derive a class from it that has materially equivalent
> functionality to the parent class, except where those conversions are
> non-explicit.

You mean implicit? Why to implement it as derived class? Edit the
implementation, remove the "explicit", rename it to "EvilUFixed" and
save as different files.

What is the purpose? Need security vulnerability? It likely already
contains defects. Isn't for example UFixed<20,20>::MaxValue incorrect
on most platforms? You can exploit it. Sufficiently advanced deliberate
security vulnerability is indistinguishable from innocent C++ typo. ;)

[Alf P. Steinbach]

On 12/25/2017 11:00 AM, Öö Tiib wrote:
>
> What is the purpose? Need security vulnerability? It likely already
> contains defects. Isn't for example UFixed<20,20>::MaxValue incorrect
> on most platforms? You can exploit it. Sufficiently advanced deliberate
> security vulnerability is indistinguishable from innocent C++ typo. ;)

Or magic.

Cheers!,

- Alf

[bitrex]

On 12/25/2017 05:00 AM, Öö Tiib wrote:
> On Monday, 25 December 2017 03:44:36 UTC+2, bitrex wrote:
>> Consider the following class "UFixed", which implements some
>> user-defined conversion operators to (explicitly) convert the type to
>> double, float, and "IntegerTypes":
>>
>> <https://github.com/Pharap/FixedPointsArduino/blob/master/src/FixedPoints/UFixed.h>
>>
>> I'd like to derive a class from it that has materially equivalent
>> functionality to the parent class, except where those conversions are
>> non-explicit.
>
> You mean implicit? Why to implement it as derived class? Edit the
> implementation, remove the "explicit", rename it to "EvilUFixed" and
> save as different files.

Assume there are like, reasons and stuff that I don't wish to do that. :-(

> What is the purpose? Need security vulnerability? It likely already
> contains defects. Isn't for example UFixed<20,20>::MaxValue incorrect
> on most platforms? You can exploit it. Sufficiently advanced deliberate
> security vulnerability is indistinguishable from innocent C++ typo. ;)
>

The bare-metal platform I'm deploying for is too stupid to know anything
about networking. I don't think its ALU can do multiplication in
hardware, much less floating-point operations. Hey, drum machines and
stuff need software, too. If someone wants to make an insecure Internet
virtual drum-machine using unmodified fixed-point library on a platform
that it was never designed for then I'd guess they've got bigger
problems then getting haxed

Anyway this "works for me", 'sokay?

template <unsigned Integer, unsigned Fraction>
struct EvilUFixed : public UFixed<Integer, Fraction>
{
typedef UFixed<Integer, Fraction> fixed_point_t;
using fixed_point_t::fixed_point_t; //pull in base constructors
using typename fixed_point_t::IntegerType; //pull in "IntegerType"

using fixed_point_t::operator double;
using fixed_point_t::operator float;
using fixed_point_t::operator IntegerType;

constexpr EvilUFixed(const fixed_point_t& rhs) :
fixed_point_t(rhs) //constructor from base type
{}

//implicit conversions

constexpr operator float() const
{
return static_cast<float>(*this);
}

constexpr operator double() const
{
return static_cast<double>(*this);
}

constexpr operator IntegerType() const
{
return static_cast<IntegerType>(*this);
}
};

[Vir Campestris]

On 25/12/2017 18:29, bitrex wrote:
> I don't think its ALU can do multiplication in hardware, much less
> floating-point operations

Admit it, you're as old as I am. I was told a few years ago that I
should expect a HW divider.

It must be a very small and specialised chip that doesn't have a HW
multiplier. Heck, even an 8080 had one of those... What is it?

Andy

[Robert Wessel]

The 8080 had no multiplier, certainly not a general purpose one (if
you use a *very* loose definition of what a multiplier is). Nor did
the Z-80, or their contemporaries, the 6800 and 6502. For examples of
more current architectures without a multiplier, there are the low end
PICs and the smaller AVRs.

[bitrex]

<https://www.microchip.com/wwwproducts/en/ATtiny85>

Nah, I'm still in my 30s. :-) The Microchip (formerly Atmel) RISC 8 bits
ain't my grandad's 8 bit! 32 registers, most instructions execute in one
clock cycle. At 20 MHz I can run multiple fixed-point digital filters on
there fed from the 10 bit ADC channels, no problem at all. An 8x8
unsigned software-multiply IIRC comes in at under 40 clocks.

You can cram a lot of C++11 in 8k program memory and 512 bytes SRAM. The
current project I'm working on is nearly 2000 SLOC in C++ and with
link-time optimization comes in occupying about 6k of the program space.

[Dombo]

Op 29-Dec-17 om 23:16 schreef Robert Wessel:

Only the smallest (i.e. ATtiny) 8-bit AVRs. Most 8-bit AVRs do have a
2-cycle hardware multiplier. These days you have to use a very low-end
CPU not to get a hardware multiplier, I doubt there exists a reasonable
C++ compiler for those.

[David Brown]

There used to be some quite large AVR's without multipliers. Some
designs are long-lived, and still work with such old devices (AVRs or
other microcontrollers). There are still a depressing number of
8051-based devices around (small USB devices, Z-Wave chips, "smart"
ADCs, etc.).

And in some cases, you can use C++ just fine. C++ (excluding exceptions
and RTTI, which is usually what you want anyway) works just fine across
the board for AVRs - even the smallest devices.

But for modern chips there is are very few that don't have hardware
multiply, even at the low end.

[Dombo]

Op 30-Dec-17 om 20:33 schreef David Brown:

The 8051 does have a multiply instruction.

> And in some cases, you can use C++ just fine. C++ (excluding exceptions
> and RTTI, which is usually what you want anyway) works just fine across
> the board for AVRs - even the smallest devices.

I didn't intend to imply that you can't have a C++ compiler for a
low-end CPU core, just that it less likely someone has bothered to make
one. The really low-end CPU cores (below lets say the 8-bit AVRs) tend
to be more awkward in several aspects (Harvard architecture,
bank-switching, very limited stack...etc.) making it harder to make a
halfway decent compiler for them and due to their limited nature also
less necessary.

My experience with the 8-bit AVRs is that one do need to adapt ones C++
coding style significantly to suit the limitations of this
microcontroller to get the compiler to produce something that is memory-
and performance-wise reasonably efficient. This makes it unlikely that
one could just use a generic C++ library that is not written with the
limitations of 8-bit AVR in mind and expect a acceptable result. Once
you get to the slightly higher end processors (e.g. ARM Cortex M0) this
becomes less and less of an issue.

> But for modern chips there is are very few that don't have hardware
> multiply, even at the low end.

These days one can expect a hardware multiplier in contemporary
microcontrollers that cost 1 USD or even less in small quantities.
Unless one intends to target extremely price-sensitive and very high
volume markets, it does make little sense to me to worry about CPUs
without hardware multiplier.

[bitrex]

There's not much below the ATTiny series; an ATTiny85 is around 75 cents
in quantity. You get 8k of program space and 512 bytes of SRAM for your
money, and C++11 code using all the "modern" features except for dynamic
allocation and smart pointers works well via avr-gcc. Templates,
policy-based design, abstract virtual classes, lambdas, all the stuff.

[David Brown]

There are many 8051 variants - I think only some have multiply hardware.
(Even if they have multiply hardware, 8051 cores are still depressing!).

>
>> And in some cases, you can use C++ just fine.  C++ (excluding
>> exceptions and RTTI, which is usually what you want anyway) works just
>> fine across the board for AVRs - even the smallest devices.
>
> I didn't intend to imply that you can't have a C++ compiler for a
> low-end CPU core, just that it less likely someone has bothered to make
> one.

I don't expect anyone intentionally planned to make a C++ compiler for
an AVR tiny! But the AVR family are all supported by gcc - once you
have the C compiler working for them, the basic C++ support is free.
Last I heard, there was minimal C++ library support for avr-gcc, and
thus things like exceptions don't work. (Header libraries are fine, of
course.)

IAR certainly has C++ support for some small microcontrollers. I
haven't looked at the details there, and don't know which ones they support.

> The really low-end CPU cores (below lets say the 8-bit AVRs) tend
> to be more awkward in several aspects (Harvard architecture,
> bank-switching, very limited stack...etc.) making it harder to make a
> halfway decent compiler for them and due to their limited nature also
> less necessary.

That is certainly true. But support for C++ (at least baring
exceptions) is not much harder than supporting C. Once you have a C
compiler, most of the work of C++ support is in the front end - and that
will be common for a whole family of different targets.

Of course, that does not mean you get /efficient/ C++ support. Virtual
methods are going to be really big and slow on a COP8, 8051 or PIC16.
It's just that /if/ you have made a C compiler for them, and you already
have a C++ front end for your ARM targets (or whatever), then supporting
virtual methods (or any other C++ feature) is not actually that much work.

>
> My experience with the 8-bit AVRs is that one do need to adapt ones C++
> coding style significantly to suit the limitations of this
> microcontroller to get the compiler to produce something that is memory-
> and performance-wise reasonably efficient.

Yes, you usually want to write code in a specific way for that kind of
chip. It applies to C as well. You make a lot more use of uint8_t and
int8_t than you normally would, for example (since these are 8-bit
cores). You minimise the use of pointers, as their pointer registers
are not great. You need compiler extensions to make efficient use of
read-only data in flash rather than ram.

> This makes it unlikely that
> one could just use a generic C++ library that is not written with the
> limitations of 8-bit AVR in mind and expect a acceptable result. Once
> you get to the slightly higher end processors (e.g. ARM Cortex M0) this
> becomes less and less of an issue.
>

Agreed.

>
>> But for modern chips there is are very few that don't have hardware
>> multiply, even at the low end.
>
> These days one can expect a hardware multiplier in contemporary
> microcontrollers that cost 1 USD or even less in small quantities.
> Unless one intends to target extremely price-sensitive and very high
> volume markets, it does make little sense to me to worry about CPUs
> without hardware multiplier.
>

We are getting to that stage. There are still cases where a Cortex M0
is too big, too slow, too power-hungry, too expensive - but it is a
rapidly shrinking section of the market. (I once knew someone whose job
was cost reduction for board designs. With the boards he worked on, if
he could find a way to eliminate a single SMD resistor, it would justify
his year's salary.) Still, many designs don't change much and last a
long time - it can be far more efficient to keep the same 15 year old
device on the board than swap it for a new device and re-do much of the
development.

For new designs, however, it is going to be very rare that you don't
have a 16-bit or 32-bit core with hardware multiply and tools with at
least reasonable C++ support.

[Dombo]

Op 30-Dec-17 om 23:44 schreef bitrex:

> There's not much below the ATTiny series; an ATTiny85 is around 75 cents
> in quantity.

Actually there is a lot below the ATtiny series if you look beyond the
8-bit AVR family. There are many, many other microcontroller families on
the market that target the really low-end/low-cost/low-power/high volume
market, where the unit price of a controller is only a few cents each.
For those few cents you can expect a small OTP or mask ROM program
memory of at most a couple of kilobytes, a couple of bytes of RAM, a few
4-bit registers and a few peripherals. The average hobbyist won't know
about those; companies selling them won't talk to you unless you intend
to buy quantities of a like a million or more. However chances are you
have already many of those in your home.

[David Brown]

There are very few 4-bit microcontrollers used now, even in the most
cost-sensitive mass produced applications. The cost difference between
a 4-bit core and an 8-bit (or even 16-bit or 32-bit) core is too small
now with smaller processes and many free or cheaply licensed cpu cores.
In a typical cheapo device (like those "amusing" birthday cards that
play a tune, or plastic giveaway toys with a kid's comic) the
peripherals like a timer or two and a DAC or PWM with amplifier cost a
lot more than the cpu core in terms of die space. But you are right
that these cores may be a more limited than even an ATTiny - though some
of them are /exactly/ as limited as ATTiny's, as a major part of Atmel's
business is ASICs with these kinds of cores.

And in these sorts of devices, I think you'd be surprised at the amount
of memory or other peripherals. It is not uncommon to have quite a bit
of ROM - far more than the flash sizes of an off-the-shelf ATTiny. But
it will be masked ROM, not OTP - the programming time for writing an OTP
and the electronics for making the high voltages would be far too expensive.

The last 4-bit microcontroller family that was available to mere mortals
was from Atmel - I've forgotten the name of it. They had devices with
flash (for prototyping) as well as masked ROM. Some of them had 30 or
more pins, and a wide range of peripherals - especially wireless
communication. But no C++ compiler - just a limited variation of Forth.

[bitrex]

Ok, I know what you mean. As you say they usually have inscrutable names
like Hitachi XM7FB194910JJ29-3 and aren't available to anyone buying in
quantities of a bajillion (professional term) or fewer

[bitrex]

Right, but it's a non-issue. There's no OS or true multitasking (there
are 'multitasking' libraries for 8-bit processors but it would probably
be better to call them multiprocessing/threading libraries, all you
usually get is register-saving context switching plus some type of queue
for inter-process communications. Where would one throw an exception to,
and who would catch it?

>> The really low-end CPU cores (below lets say the 8-bit AVRs) tend to
>> be more awkward in several aspects (Harvard architecture,
>> bank-switching, very limited stack...etc.) making it harder to make a
>> halfway decent compiler for them and due to their limited nature also
>> less necessary.
>
> That is certainly true.  But support for C++ (at least baring
> exceptions) is not much harder than supporting C.  Once you have a C
> compiler, most of the work of C++ support is in the front end - and that
> will be common for a whole family of different targets.
>
> Of course, that does not mean you get /efficient/ C++ support.  Virtual
> methods are going to be really big and slow on a COP8, 8051 or PIC16.
> It's just that /if/ you have made a C compiler for them, and you already
> have a C++ front end for your ARM targets (or whatever), then supporting
> virtual methods (or any other C++ feature) is not actually that much work.

Virtual methods are pretty efficient on the AVR; each virtual method in
a class or structure results in a "hidden" 2 byte vtable entry, then to
execute IIRC it's a 2 clock instruction to load the vtable entry into
the "Z" register from program memory, and then a 2 clock instruction to
indirect-jump to the function address

[Dombo]

Op 31-Dec-17 om 0:23 schreef David Brown:

> On 30/12/17 23:05, Dombo wrote:
>> The 8051 does have a multiply instruction.
>
> There are many 8051 variants - I think only some have multiply hardware.
> (Even if they have multiply hardware, 8051 cores are still depressing!).

I have a databook from 1984 which mentions that the 8051 has a multiply
instruction; therefore I'm inclined to believe that the MUL instruction
has been a integral part of the 8051 instruction set right from the
start. Though their are a huge number of 8051 variants, I believe the
difference is mostly in the peripherals and not so much in the core
instruction set. I agree that the 8051 isn't exactly pretty from the
programmers perspective. In its defense it's from an era when
microcontrollers were typically programmed in assembly, not C.

> I don't expect anyone intentionally planned to make a C++ compiler for
> an AVR tiny!

I think the C++ support for the 8-bit AVR is mostly a "lucky"
side-effect of using GCC. In theory it should be relatively easy to also
support the other programming languages GCC supports (Fortran, Ada,
Go...) on the AVR.

> But the AVR family are all supported by gcc - once you
> have the C compiler working for them, the basic C++ support is free.

That is largely true for GCC because it has a relatively clear
separation of the programming language dependent front-end and the
processor dependent back-end. However this is not necessarily the case
for compilers that are not GCC based.

>> The really low-end CPU cores (below lets say the 8-bit AVRs) tend to
>> be more awkward in several aspects (Harvard architecture,
>> bank-switching, very limited stack...etc.) making it harder to make a
>> halfway decent compiler for them and due to their limited nature also
>> less necessary.
>
> That is certainly true. But support for C++ (at least baring
> exceptions) is not much harder than supporting C.

Only if your compiler is GCC or CLang based, or at least if you have a
suitable C++ front-end that can be easily bolted on to your compiler. If
you are writing a compiler from scratch I think you are going to find
supporting C++ a lot harder than supporting just C. For example I don't
expect C++ support for the 8-bit PIC microcontrollers (given your
comments about the 8051 I can guess how you feel about that family),
simply because the MPLAB XC8 doesn't appear to be GCC based, hence
supporting C++ would be a rather costly proposition with little reward.

For the really low-end processors (4-bit, few bytes RAM, a kilobyte or
so of program memory and a little bit of I/O) there isn't even really a
point in creating a C compiler for it.

[David Brown]

On 31/12/17 15:34, Dombo wrote:
> Op 31-Dec-17 om 0:23 schreef David Brown:
>> On 30/12/17 23:05, Dombo wrote:
>>> The 8051 does have a multiply instruction.
>>
>> There are many 8051 variants - I think only some have multiply
>> hardware.   (Even if they have multiply hardware, 8051 cores are still
>> depressing!).
>
> I have a databook from 1984 which mentions that the 8051 has a multiply
> instruction; therefore I'm inclined to believe that the MUL instruction
> has been a integral part of the 8051 instruction set right from the
> start. Though their are a huge number of 8051 variants, I believe the
> difference is mostly in the peripherals and not so much in the core
> instruction set.

There are a surprising number of variants in the instruction set and key
registers too, such as additional accumulators, pointer registers, and
even addressing modes. But it is unlikely that they will be missing
features from the original 8051 - if you say it had a multiply
instruction from the beginning, then I expect you are right if you say
they have it. My actual experience of using 8051's is not that wide - I
avoid them whenever possible.

> I agree that the 8051 isn't exactly pretty from the
> programmers perspective. In its defense it's from an era when
> microcontrollers were typically programmed in assembly, not C.

The 8051 was quite an old-fashioned design when it came out (as was the
8086 - Intel have been innovative in their implementations and
production processes, but quite conservative and old-fashioned in many
of their ISA designs). What bugs me about the 8051 is not so much that
it is painful to use in C (and in assembly), but that some manufacturers
of systems-on-a-chip still, to this day, put 8051 cores in their
designs. The problem is hardware designers that make nice radio
devices, or programmable motion sensors, or configurable analogue parts,
and think "we should put a microcontroller in this chip to make it more
flexible. Which one will we choose? I know - an 8051. Everyone likes
those". They never bother talking to the poor sod that has to program
them - nor the development company that has to splash out multiple $K
for bug-ridden development tools that belong in the last century
(because "everyone has Keil's 8051 compiler").

There we go - rant over. I don't like 8051's, and I don't like when
manufacturers make me use them (or chase me away from good peripherals
due to their poor choice of cpu core).

>
>> I don't expect anyone intentionally planned to make a C++ compiler for
>> an AVR tiny!
>
> I think the C++ support for the 8-bit AVR is mostly a "lucky"
> side-effect of using GCC. In theory it should be relatively easy to also
> support the other programming languages GCC supports (Fortran, Ada,
> Go...) on the AVR.

Yes, that is mostly correct. There have been some people who have
actively contributed to gcc C++ on the AVR, but they would not have
bothered if they hadn't got most of it free with the gcc C AVR port.
There are also people programming AVR's in Ada, in the same way. (I
haven't heard of anyone using Fortran or Go on the AVR. But maybe there
is someone out there trying it - after all, there is at least one Linux
system running on an AVR Mega.)

>
>> But the AVR family are all supported by gcc - once you have the C
>> compiler working for them, the basic C++ support is free.
>
> That is largely true for GCC because it has a relatively clear
> separation of the programming language dependent front-end and the
> processor dependent back-end. However this is not necessarily the case
> for compilers that are not GCC based.

It is also true for clang/llvm. And the original C++ "compiler" was a
C++ to C translator. You can implement C++ (at least excluding
exceptions) without a code generation beyond what you need for C -
although some C++ specific features would be useful for efficiency. But
you are certainly correct that other compilers could be structured
differently in a way that makes C++ support harder.

>
>>> The really low-end CPU cores (below lets say the 8-bit AVRs) tend to
>>> be more awkward in several aspects (Harvard architecture,
>>> bank-switching, very limited stack...etc.) making it harder to make a
>>> halfway decent compiler for them and due to their limited nature also
>>> less necessary.
>>
>> That is certainly true.  But support for C++ (at least baring
>> exceptions) is not much harder than supporting C.
>
> Only if your compiler is GCC or CLang based, or at least if you have a
> suitable C++ front-end that can be easily bolted on to your compiler. If
> you are writing a compiler from scratch I think you are going to find
> supporting C++ a lot harder than supporting just C. For example I don't
> expect C++ support for the 8-bit PIC microcontrollers (given your
> comments about the 8051 I can guess how you feel about that family),
> simply because the MPLAB XC8 doesn't appear to be GCC based, hence
> supporting C++ would be a rather costly proposition with little reward.
>

Moving from a C-only compiler for a PIC16 to provide C++ support would
certainly be a lot of effort for little return. But some of the other
big embedded toolchain manufacturers already have C++ support - IAR
springs to mind. I expect that for them, supporting C++ on their PIC16
compiler would not be a huge job. It might still not be worth the
effort, of course - it still costs time and money, and the market is
going to be very small.

> For the really low-end processors (4-bit, few bytes RAM, a kilobyte or
> so of program memory and a little bit of I/O) there isn't even really a
> point in creating a C compiler for it.
>

I have once used an AVR Tiny with no ram other than the 32 8-bit
registers, and 2K (IIRC) flash. I programmed it in C, using gcc. I
suppose I could have used C++ :-)

[Hergen Lehmann]

Am 31.12.2017 um 17:06 schrieb David Brown:

> What bugs me about the 8051 is not so much that
> it is painful to use in C (and in assembly), but that some manufacturers
> of systems-on-a-chip still, to this day, put 8051 cores in their
> designs.  The problem is hardware designers that make nice radio
> devices, or programmable motion sensors, or configurable analogue parts,

Well, an 8051 core is very small (doesn't require much space on the
silicon) and VHDL sources are available from various sources for free or
very low cost.

If it does suit the purpose of basically acting as the bootloader for
some configurable analog front-end chip, why bothering with something
more complex, which requires you to pay royalities and sign NDAs?

[Dombo]

Op 31-Dec-17 om 14:53 schreef David Brown:

> On 31/12/17 13:46, Dombo wrote:
>> Op 30-Dec-17 om 23:44 schreef bitrex:
>>
>>> There's not much below the ATTiny series; an ATTiny85 is around
>>> 75 cents in quantity.
>>
>> Actually there is a lot below the ATtiny series if you look beyond
>> the 8-bit AVR family. There are many, many other microcontroller
>> families on the market that target the really
>> low-end/low-cost/low-power/high volume market, where the unit
>> price of a controller is only a few cents each. For those few cents
>> you can expect a small OTP or mask ROM program memory of at most a
>> couple of kilobytes, a couple of bytes of RAM, a few 4-bit
>> registers and a few peripherals. The average hobbyist won't know
>> about those; companies selling them won't talk to you unless you
>> intend to buy quantities of a like a million or more. However
>> chances are you have already many of those in your home.
>
> There are very few 4-bit microcontrollers used now, even in the most
> cost-sensitive mass produced applications. The cost difference
> between a 4-bit core and an 8-bit (or even 16-bit or 32-bit) core is
> too small now with smaller processes and many free or cheaply
> licensed cpu cores.

It true that the cost reductions in higher end of the market squeezes
the lower end of the market. Especially if the volume isn't extremely
high you see 32-bit processors are being used where with a bit of effort
a 8-bit processor could do the job as well. Lower NRE, shorter time to
market, easier grow path to more advanced versions of product may very
well outweigh a small difference in BOM cost.

However at the most extreme end of the market (very high volume/very low
retail price) every fraction of a cent still counts, and there is no
thing like a "too small cost difference".

> In a typical cheapo device (like those "amusing" birthday cards that
> play a tune, or plastic giveaway toys with a kid's comic) the
> peripherals like a timer or two and a DAC or PWM with amplifier cost
> a lot more than the cpu core in terms of die space.

It is true that for applications that must drive a relatively heavy load
the output transistor(s) are relatively large. Also the bonding pads
take up percentage wise quite a bit of space on a small die. However
4-bit microcontrollers tend to have very few peripherals. Timers and PWM
circuitry typically do not require more die space than the core and the
associated RAM and ROM memory. A DAC (whose resistor network would
occupy quite a bit of die real-estate) is usually omitted as PWM is for
those applications good enough.

Also those applications typically don't use the smaller, more advanced
(& more expensive) processes. That means the core, ROM and RAM still
takes up quite a bit of die space. Hence when every fraction of cent is
relevant it still pays to have very low-end microcontroller that can do
the job. Also for extremely low power applications (like clock,
thermometer...etc.) a dedicated 4-bit processor can still have an edge
compared to a more general purpose 8- or 32-bit processor.

Sometimes you find 4-bit microcontrollers in places were you would not
expect a microcontroller in the first place, like in my toothbrush.
Given its functionality (on/off/charge) I'd expect a few discretes would
suffice, yet apparently a 4-bit microcontroller was more economical, but
something like a general purpose 8-pin PIC apparently too expensive.

> But you are right that these cores may be a more limited than even
> an ATTiny - though some of them are /exactly/ as limited as ATTiny's,
> as a major part of Atmel's business is ASICs with these kinds of
> cores. And in these sorts of devices, I think you'd be surprised at
> the amount of memory or other peripherals. It is not uncommon to
> have quite a bit of ROM - far more than the flash sizes of an
> off-the-shelf ATTiny.

Once we are talking about more than a few kilobytes of memory, we are no
longer talking about a market that is targeted by the bottom-end
microcontrollers that may only cost a few cents.

> But it will be masked ROM, not OTP - the programming time for
> writing an OTP and the electronics for making the high voltages would
> be far too expensive.
>
> The last 4-bit microcontroller family that was available to mere
> mortals was from Atmel - I've forgotten the name of it.

Atmel is/was hardly the benchmark for the very low-end & cost sensitive
market. The 8-bit AVRs are relatively expensive. They are popular in the
hobbyist scene due to the easy availability of the chips, tools &
documentation and more recently the Arduino kits, but you don't find
8-bit AVRs that often in high volume products. At the real bottom end of
the microcontroller market you find different players than the familiar
players of the higher end microcontrollers (like Microchip, ST,
Freescale....etc.).

Either way for C++ this has little to no relevance. If I were to write a
general purpose C++ library these days, I wouldn't be too bothered how
well it would do on anything less than a contemporary 32-bit processor.
Given how the market is developing even the 16-bit microcontroller
families like the PIC24 and MSP430 don't appear to have a very bright
future ahead of them.

[Vir Campestris]

On 29/12/2017 22:16, Robert Wessel wrote:
> The 8080 had no multiplier, certainly not a general purpose one (if

> you use a*very* loose definition of what a multiplier is). Nor did

> the Z-80, or their contemporaries, the 6800 and 6502. For examples of
> more current architectures without a multiplier, there are the low end
> PICs and the smaller AVRs.

My apologies. I haven't used one since ... 1982? and I seem to have
forgotten the instruction set.

The smallest thing I've used recently is a MIPS router chip.

With a Gig of ram... so not all that small!

Andy

[Ian Collins]

On 01/01/2018 05:06 AM, David Brown wrote:
>
> The 8051 was quite an old-fashioned design when it came out (as was the
> 8086 - Intel have been innovative in their implementations and
> production processes, but quite conservative and old-fashioned in many
> of their ISA designs). What bugs me about the 8051 is not so much that
> it is painful to use in C (and in assembly), but that some manufacturers
> of systems-on-a-chip still, to this day, put 8051 cores in their
> designs. The problem is hardware designers that make nice radio
> devices, or programmable motion sensors, or configurable analogue parts,
> and think "we should put a microcontroller in this chip to make it more
> flexible. Which one will we choose? I know - an 8051. Everyone likes
> those". They never bother talking to the poor sod that has to program
> them - nor the development company that has to splash out multiple $K
> for bug-ridden development tools that belong in the last century
> (because "everyone has Keil's 8051 compiler").
>
> There we go - rant over. I don't like 8051's, and I don't like when
> manufacturers make me use them (or chase me away from good peripherals
> due to their poor choice of cpu core).

As one of the lucky few to get hold of preproduction prototype 8751s
back in the early 80s I have to disagree! It was a big step up from the
8748s we had been using. I never had the (dubious) pleasure of
programming one in C, but had great fun writing complex assembly
solutions in the 4K of EPROM available to us. Bit addressable memory
was incredibly useful for the kind of products we were building at the
time, but I've no idea how is is exploited from C or C++.

--
Ian.

[David Brown]

Yes.

> However at the most extreme end of the market (very high volume/very low
> retail price) every fraction of a cent still counts, and there is no
> thing like a "too small cost difference".
>

There is no extreme end where that is true - there is /always/ a
trade-off. Even for the most long-lived products, there are deadlines
and limits to development costs, and even the most mass-produced
products have limit production quantities in a given time period.

>> In a typical cheapo device (like those "amusing" birthday cards that
>> play a tune, or plastic giveaway toys with a kid's comic) the
>> peripherals like a timer or two and a DAC or PWM with amplifier cost a
>> lot more than the cpu core in terms of die space.
>
> It is true that for applications that must drive a relatively heavy load
> the output transistor(s) are relatively large. Also the bonding pads
> take up percentage wise quite a bit of space on a small die. However
> 4-bit microcontrollers tend to have very few peripherals. Timers and PWM
> circuitry typically do not require more die space than the core and the
> associated RAM and ROM memory. A DAC (whose resistor network would
> occupy quite a bit of die real-estate) is usually omitted as PWM is for
> those applications good enough.

Agreed - this will vary from application to application.

>
> Also those applications typically don't use the smaller, more advanced
> (& more expensive) processes. That means the core, ROM and RAM still
> takes up quite a bit of die space.

That will vary. Small mass-produced systems rarely need a lot of RAM,
but can find ROM useful (such as for storing those irritating tunes).
An electric toothbrush, of course, does not need much ROM or RAM.
Typically the choice of process will be determined by many factors,
including other electronics on the chip (radio senders will need finer
processes, power electronics will be best with more robust processes)
and factory capacity.

> Hence when every fraction of cent is
> relevant it still pays to have very low-end microcontroller that can do
> the job. Also for extremely low power applications (like clock,
> thermometer...etc.) a dedicated 4-bit processor can still have an edge
> compared to a more general purpose 8- or 32-bit processor.
>

These sorts of things are often done with dedicated devices that can
hardly be called a microcontroller.

> Sometimes you find 4-bit microcontrollers in places were you would not
> expect a microcontroller in the first place, like in my toothbrush.
> Given its functionality (on/off/charge) I'd expect a few discretes would
> suffice, yet apparently a 4-bit microcontroller was more economical, but
> something like a general purpose 8-pin PIC apparently too expensive.

There is a /huge/ gap between 4-bit microcontrollers and general purpose
off-the-shelf devices.

For the biggest quantity systems, you use a dedicated ASIC with a
microcontroller core. In some of these, you might still find 4-bit
cores - but I think it is rare, because the die area cost difference
between a 4-bit core and an 8-bit core is much smaller than it used to
be, while development times and time-to-market is more relevant than a
decade ago.

The next step down for not quite so big productions is to use ready-made
chips as bare die, rather than in a package. By that point, testing
costs for the die and mounting costs are getting more relevant.

And by the time you get to pre-packaged devices, the cost of a small
8-bit core is irrelevant.

Even when you are talking about very large quantities, fractions of a
cent spared here and there often don't amount to real savings. A
slightly better core might mean extra features, or shorter development
and prototyping time, or shorter production test times, or more re-use
of parts or code.


But all this is speculation on my part - I have no experience with large
production quantities. At my company, we only have a few products at
more than 10K boards per year - most are smaller runs than that.

>
>> But you are right that these cores may be a more limited than even
>> an ATTiny - though some of them are /exactly/ as limited as ATTiny's,
>> as a major part of Atmel's business is ASICs with these kinds of
>> cores. And in these sorts of devices, I think you'd be surprised at
>> the amount of memory or other peripherals.  It is not uncommon to
>> have quite a bit of ROM - far more than the flash sizes of an
>> off-the-shelf ATTiny.
>
> Once we are talking about more than a few kilobytes of memory, we are no
> longer talking about a market that is targeted by the bottom-end
> microcontrollers that may only cost a few cents.
>
>> But it will be masked ROM, not OTP - the programming time for
>> writing an OTP and the electronics for making the high voltages would
>> be far too expensive.
>>
>> The last 4-bit microcontroller family that was available to mere
>> mortals was from Atmel - I've forgotten the name of it.
>
> Atmel is/was hardly the benchmark for the very low-end & cost sensitive
> market. The 8-bit AVRs are relatively expensive. They are popular in the
> hobbyist scene due to the easy availability of the chips, tools &
> documentation and more recently the Arduino kits, but you don't find
> 8-bit AVRs that often in high volume products.

You are thinking of the Atmel products available to general customers.
A great deal more AVR cores are sold in ASICs than in off-the-shelf
microcontrollers. In fact, the off-the-shelf AVRs were started almost
as a side line to the main business of ASICs as someone thought that by
adding a few extra peripherals and better documentation they could sell
it to a wider audience with higher profit margins.

But you are right that AVR's are not very low end - as I said, Atmel
made a series of 4-bit microcontrollers too. The MARC4 devices were
targeted at infrared controls and wireless tyre pressure gauges amongst
other things. I have no idea how these compare to others in price -
they were just somewhat different in being available to mere mortals.

> At the real bottom end of
> the microcontroller market you find different players than the familiar
> players of the higher end microcontrollers (like Microchip, ST,
> Freescale....etc.).

Yes indeed - few people will have heard of them. However, even folks
like ST and Freescale make cores, ASICs, and dedicated chips for mass
productions. I read somewhere that the great majority of Coldfire cores
(Coldfire is the successor to the M68K family - certainly not low-end)
were in dedicated chips for single customers, rather than in readily
available processors and microcontrollers.

>
> Either way for C++ this has little to no relevance. If I were to write a
> general purpose C++ library these days, I wouldn't be too bothered how
> well it would do on anything less than a contemporary 32-bit processor.
> Given how the market is developing even the 16-bit microcontroller
> families like the PIC24 and MSP430 don't appear to have a very bright
> future ahead of them.
>

The msp430 is still a fine choice in some areas. But I agree with you
here - it is not at all unreasonable to assume 32-bit for C++ libraries.