Some 10 years ago when I was teaching a basic electronics course with an
an intro to 8051 embedded programming, a student asked this exact same
question.
He had a hand-held calculator with a couple of non-functional keys. We tore
it open to investigate, and noticed it had an incredibly tiny little IC tucked
away in there that was handling everything.
We managed to re-solder a few bad connections to the IC, and had his
calculator back up & going in a few minutes, but it raised his curiosity. He
asked; why can't they just stuff something like this little IC into a controller
core?
Then we wouldn't all be banging our heads on our desks trying to convert
degrees C to degrees F in assembler for this stupid temperature sensor!
Rather than debate the issue in class, we fired that same question at a
couple of embedded engineers from Intel.
When they all finished laughing, spilling coffee all over themselves, and
managed to get up off the floor & back to the phone to answer his question,
one of them said, "what's the point".
If we added this to the core, it would just drive the price per unit up for a
hardware solution to something that nobody needs & certainly don't want to
pay extra for.
Anyone that really needs to compute an FP result already has the library
in their bag-of-tricks, and if they don't, we have already provided tons of
examples in assembler, and it's already supported by high-level languages if
someone prefers to use them.
It's a feature that 99.9% of the high-level compiler manufacturers will even
recommended you use "only" as a last resort!
At the time, it would have increased the size of the controller also. I think
now they could probably manage to squeeze this into a core without making
the controller any larger, but it for sure would drive up the cost per unit, and
make people that just don't need FP math more than a little upset.
Especially if they already owned a compiler that supported FP.
Bookmarks