Re: end of Intel?

On 2/22/2025 9:39 AM, Dennis wrote:

On 2/22/25 08:46, Don Y wrote:
 

And, things like the 432 were *decades* ahead of their time

 Not really - the IBM System/38 was doing what the 432 was trying to do and actually shipping. It was object oriented, had capability based security, and tagged memory. It lived on for decades as the AS/400 and later iSeries.

It wasn't an "integrated" device that could be slapped on a board
with other bits to make <something>.  I don't think folks realize
just how different designing for a 4/8 bit device of that era was
vs. "big iron" of the same day.
How many "big iron" systems do you think EVER existed -- vs the
number of embedded devices produced in an given *year*?!
[Having some technology "filling a room" is little consolation to
a guy trying to squeeze something into a box that can be sold for a
few hundred dollars]
There were lots of "old big iron" devices that were considerably
better architected than the microprocessors of that day -- or even
today! (e.g., Burroughs B5000).  Yet, none of them moved forwards
into "smaller (more economical) form factors", either.
[e.g., ARM peripherals are a step BACKWARDS in terms of abilities]
DEC made a lame attempt with the F11/T11/J11 but it was too little
(and there wasn't much that was "truly extraordinary" about the 11's
architecture that wasn't easily copied in other *cheap* MPUs.)
As a result, the emphasis was on faster and cheaper instead of
on devices that facilitated the writing of "good/reliable code".
The attitude persists, today, as if cost/speed/throughput mattered
more than correctness, security, etc.
[Why is the presence of an MMU still not /de rigueur/?  Has no one
"discovered" its value REGARDLESS OF PROJECT SCALE?  It's like saying
"you don't need seat belts on small cars".  Do we have to wait ANOTHER
generation for folks to learn how to code in such an environment?
And, the learning pains that products will exhibit as a result??]
So, today (many decades later!) we still have to EMULATE these
functionalities in software instead of calling on the hardware
to provide them for us.  Thankfully, we can over-provision cheap/fast
hardware so "wasting" a good portion of it on these implementations
doesn't impact performance.  But, this means few people get the
experience of working in those realms and THAT state-of-the-art
stagnates.