In the early days of the microcomputer era, one could either
have a cheap small computer with a single-chip CPU, or, if
one wanted something bigger, moderate performance was available
from bit-slice chips.

If you wanted higher performance than a bit-slice design would
allow, you had to use older, less highly integrated technology,
so the increase in cost was too large to be justified by the
increase in performance.

Eventually, the Pentium Pro, and its popular successor the Pentium
II came along, and now a System 360/195 architecture was placed
on a single chip (two dies, though, as even the L1 cache, which
was on the chip, had to have a separate die) and the problem was
solved.

This explains my goal of including a Cray I style vector capability
on a microprocessor - this is the one historic thing not yet reduced
to a chip which extends into a performance space beyond that of the
360/195. My reasoning may be very naive, because I'm failing to take
into account how the current gap between CPU and DRAM speeds makes
older architectures not practical.

And, as I've noted also, the overwhelming dominance of Windoes on
the x86 shows "there can be only one", which is why I want my new
architecture to offer something the x86 doesn't... efficient
emulation of older architecures with 36-bit, 48-bit, and 60-bit
words, so that those who have really old programs to run are no
longer disadvantaged.

While this seems like a super-niche thing to some, I see it as
something that's practically _essential_ to have a future world of
computers that doesn't leave older code behind - so that the
computer you already have on your desktop is truly general in its
capabilities.

I don't see FPGAs in their current form as efficient enough to
offer a route to the kind of generality I'm seeking.

By explaining what my goals are, rather than discussing the ISA
proposals that I see as a means to those goals, perhaps this makes
it possible for a better and more practical way to achieve those
goals to be suggested.

John Savard

Quadibloc wrote:

> In the early days of the microcomputer era, one could either
> have a cheap small computer with a single-chip CPU, or, if
> one wanted something bigger, moderate performance was available
> from bit-slice chips.

> If you wanted higher performance than a bit-slice design would
> allow, you had to use older, less highly integrated technology,
> so the increase in cost was too large to be justified by the
> increase in performance.

> Eventually, the Pentium Pro, and its popular successor the Pentium
> II came along, and now a System 360/195 architecture was placed
> on a single chip (two dies, though, as even the L1 cache, which
> was on the chip, had to have a separate die) and the problem was
> solved.

> This explains my goal of including a Cray I style vector capability
> on a microprocessor - this is the one historic thing not yet reduced
> to a chip which extends into a performance space beyond that of the
> 360/195.

It has not been reduced into practice because it takes too many pins,
wiggling at too high a rate, ...

> My reasoning may be very naive, because I'm failing to take
> into account how the current gap between CPU and DRAM speeds makes
> older architectures not practical.

3 accesses per CPU cycle continuously (2 LDs and 1 ST) and hundreds
of banks {Without cache lines}

> And, as I've noted also, the overwhelming dominance of Windoes on
> the x86 shows "there can be only one",

There is now an ARM Windows.

> which is why I want my new
> architecture to offer something the x86 doesn't... efficient
> emulation of older architecures with 36-bit, 48-bit, and 60-bit
> words, so that those who have really old programs to run are no
> longer disadvantaged.

Do you have a market demand survey ??

> While this seems like a super-niche thing to some, I see it as
> something that's practically _essential_ to have a future world of
> computers that doesn't leave older code behind - so that the
> computer you already have on your desktop is truly general in its
> capabilities.

> I don't see FPGAs in their current form as efficient enough to
> offer a route to the kind of generality I'm seeking.

> By explaining what my goals are, rather than discussing the ISA
> proposals that I see as a means to those goals, perhaps this makes
> it possible for a better and more practical way to achieve those
> goals to be suggested.

> John Savard

On Wed, 14 Feb 2024 05:50:41 -0000 (UTC), Quadibloc wrote:

> Eventually, the Pentium Pro ...

Ah, the poor Pentium Pro, that was a bit of a joke. The problem was that
Intel expected that the majority of Windows code would be 32-bit by that
point. It wasn’t.

> And, as I've noted also, the overwhelming dominance of Windoes on the
> x86 shows "there can be only one", which is why I want my new
> architecture to offer something the x86 doesn't... efficient emulation
> of older architecures with 36-bit, 48-bit, and 60-bit words, so that
> those who have really old programs to run are no longer disadvantaged.

Didn’t a company called “Transmeta” try that ... something like 30 years
ago? It didn’t work.

There is no path forward for Windows on non-x86. Only open-source software
is capable of being truly cross-platform.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 14 Feb 2024 05:50:41 -0000 (UTC), Quadibloc wrote:
>
>> Eventually, the Pentium Pro ...
>
>Ah, the poor Pentium Pro, that was a bit of a joke. The problem was that
>Intel expected that the majority of Windows code would be 32-bit by that
>point.

We used the P6 (aka the Pentium Pro) for a large massively parallel system
(64 2-processor nodes, each with a SCSI controller and 1Gb ethernet port)
running a single-system-image version of SVR4.2ES/MP.

I wouldn't call it a joke. We also had the orange books for the
never-built P7 (which morphed eventually into Itanium).

>Didn’t a company called “Transmeta” try that ... something like 30 years
>ago? It didn’t work.

They tried to build an architecture that supported run-time
translation of x86 instructions to native instructions. Several
former colleagues worked there - one of whom is now with Apple managing
their ARM core development group. He used to take Linus Torvalds (another
former transmeta employee) up in his Cessna 414 (A fun plane to fly).

>
>There is no path forward for Windows on non-x86.

That's entirely up to Microsoft. As has been noted, they do have
ARMv8 versions of windows 11.

https://learn.microsoft.com/en-us/windows/arm/overview

> Ah, the poor Pentium Pro, that was a bit of a joke. The problem was
> that Intel expected that the majority of Windows code would be 32-bit
> by that point. It wasn’t.

Maybe for some segment of the Windows world, but for the
workstation/unix/RISC world, the Pentium Pro was no joke at all: it was
a game changer.

Stefan

Lawrence D'Oliveiro wrote:

> On Wed, 14 Feb 2024 05:50:41 -0000 (UTC), Quadibloc wrote:

>> Eventually, the Pentium Pro ...

> Ah, the poor Pentium Pro, that was a bit of a joke. The problem was that
> Intel expected that the majority of Windows code would be 32-bit by that
> point. It wasn’t.

I had the first 200 MHz Pentium Pro out of the Micron factory.
It ran DOOM at 73 fps and Quake at 45+ fps both full screen.
I would not call that a joke.

It was <essentially> the death knell for RISC workstations.

On Wed, 14 Feb 2024 21:32:11 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>There is no path forward for Windows on non-x86.
>
> That's entirely up to Microsoft. As has been noted, they do have ARMv8
> versions of windows 11.

They’ve been trying for years: Windows Phone 8, Windows RT, that laughable
“Windows 10 IOT Edition” for the Raspberry Pi, whatever the name is for
the current effort ... Windows-on-ARM has always been a trainwreck.

On Wed, 14 Feb 2024 16:57:54 -0500, Stefan Monnier wrote:

>> Ah, the poor Pentium Pro, that was a bit of a joke. The problem was
>> that Intel expected that the majority of Windows code would be 32-bit
>> by that point. It wasn’t.
>
> Maybe for some segment of the Windows world, but for the
> workstation/unix/RISC world, the Pentium Pro was no joke at all: it was
> a game changer.

A chip with the emphasis on 32-bit performance, later replaced by the
Pentium II, with a greater emphasis on 16-bit performance ... only in the
x86 world, eh?

Lawrence D'Oliveiro wrote:

> On Wed, 14 Feb 2024 16:57:54 -0500, Stefan Monnier wrote:

>>> Ah, the poor Pentium Pro, that was a bit of a joke. The problem was
>>> that Intel expected that the majority of Windows code would be 32-bit
>>> by that point. It wasn’t.
>>
>> Maybe for some segment of the Windows world, but for the
>> workstation/unix/RISC world, the Pentium Pro was no joke at all: it was
>> a game changer.

> A chip with the emphasis on 32-bit performance, later replaced by the
> Pentium II, with a greater emphasis on 16-bit performance ... only in the
> x86 world, eh?

This sounds remarkably like you expected sane behavior from x86 land.

Lawrence D'Oliveiro wrote:
> On Wed, 14 Feb 2024 05:50:41 -0000 (UTC), Quadibloc wrote:
>
>> Eventually, the Pentium Pro ...
>
> Ah, the poor Pentium Pro, that was a bit of a joke. The problem was that

That is so wrong that it isn't even funny.

> Intel expected that the majority of Windows code would be 32-bit by that
> point. It wasn’t.

This is of course correct, but it really didn't matter!

What did matter, a lot, was the fact that when the PPro arrived, at an
initial speed of up to 200 MHz, it immediately took over the crown as
the fastest specINT processor in the world. I.e. it was a huge deal and
have been the basis for pretty much all x86 processors since then.

Dominating a market for ~30 years is not "a bit of a joke" imho.

>
>> And, as I've noted also, the overwhelming dominance of Windoes on the
>> x86 shows "there can be only one", which is why I want my new
>> architecture to offer something the x86 doesn't... efficient emulation
>> of older architecures with 36-bit, 48-bit, and 60-bit words, so that
>> those who have really old programs to run are no longer disadvantaged.
>
> Didn’t a company called “Transmeta” try that ... something like 30 years
> ago? It didn’t work.
>
> There is no path forward for Windows on non-x86. Only open-source software
> is capable of being truly cross-platform.

That is correct, with the exception of special single-vendor platforms,
like the AS400 and several mainframes where the vendor makes sure that
all the old sw can still run with acceptable performance.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

scott@slp53.sl.home (Scott Lurndal) writes:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>There is no path forward for Windows on non-x86.
>
>That's entirely up to Microsoft.

No. Microsoft is trying to commoditize their complement (in
particular, Intel) by making Windows on ARM viable, but the ISVs don't
play along. Of course some of that is Microsoft's own doing, as they
ensured in earlier iterations of this stategy (MIPS, PowerPC, Alpha
during the 1990s, IA-64 during the 2000s; there was also Windows RT)
that all ISVs who invested in non-IA-32/x64 Windows lost their
investment by MS dropping the support for these platforms. So now
every sane ISV just sits back and waits until Microsoft has made the
Windows-on-ARM market big on their own. Of course this does not work,
and the high prices and lack of alternative OS options of the
Windows-on-ARM hardware does not help, either.

>As has been noted, they do have
>ARMv8 versions of windows 11.
>
>https://learn.microsoft.com/en-us/windows/arm/overview

Doomed.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thu, 15 Feb 2024 07:24:56 GMT, Anton Ertl wrote:

> Microsoft is trying to commoditize their complement (in
> particular, Intel) by making Windows on ARM viable, but the ISVs don't
> play along.

Can you blame them? They are not going to port their proprietary apps to
ARM until they see the customers buying lots of ARM-based machines, and
customers are staying away from buying ARM-based machines because they
don’t see lots of software that will take advantage of the hardware.

Chicken-and-egg situation, and no way to break out of it.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 15 Feb 2024 07:24:56 GMT, Anton Ertl wrote:
>
>> Microsoft is trying to commoditize their complement (in
>> particular, Intel) by making Windows on ARM viable, but the ISVs don't
>> play along.
>
>Can you blame them? They are not going to port their proprietary apps to
>ARM until they see the customers buying lots of ARM-based machines, and
>customers are staying away from buying ARM-based machines because they
>don’t see lots of software that will take advantage of the hardware.
>
>Chicken-and-egg situation, and no way to break out of it.

A possible way would be to offer the ARM-based systems much cheaper,
making the hardware attractive to users who do not use
architecture-specific ISV software. That would result in a
significant number of systems out there, and would inspire big ISVs
like Adobe to support them, increasing the appeal of the platform,
which again would result in increased sales, which would make the
platform attractive to additional ISVs, and so on.

The first part happened for Chromebooks and the Raspberry Pi, and,
e.g., VFX Forth (a proprietary Forth system, i.e., an ISV product) is
available on the Raspi, even though it does not run Windows.

But wrt Windows-on-ARM, what actually happens is that laptops with
that are rather expensive. It seems that someone (Qualcomm? The
laptop producers? MS?) wants to milk that market before it has
calved. This doesn't work.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thu, 15 Feb 2024 01:00:09 +0000, MitchAlsup1 wrote:
> Lawrence D'Oliveiro wrote:
>> On Wed, 14 Feb 2024 16:57:54 -0500, Stefan Monnier wrote:

>>>> Ah, the poor Pentium Pro, that was a bit of a joke. The problem was
>>>> that Intel expected that the majority of Windows code would be 32-bit
>>>> by that point. It wasn’t.

>>> Maybe for some segment of the Windows world, but for the
>>> workstation/unix/RISC world, the Pentium Pro was no joke at all: it was
>>> a game changer.

>> A chip with the emphasis on 32-bit performance, later replaced by the
>> Pentium II, with a greater emphasis on 16-bit performance ... only in the
>> x86 world, eh?

> This sounds remarkably like you expected sane behavior from x86 land.

A chip which had leading-edge 32-bit performance, but which performed
poorly on the existing software users already had installed, was replaced
by one which _still_ had great 32-bit performance, but which fixed the
defect of inferior support for the older software that was also in use.

How was that not eminently sane behavior on the part of Intel? And what
isn't sane about x86 users not spending money to replace software that
was doing the job perfectly well?

Only the reduced cache speed - which reduced manufacturing cost to something
sustainable in a consumer-priced product - compromised performance in general.

John Savard

On Thu, 15 Feb 2024 07:54:57 +0100, Terje Mathisen wrote:

> What did matter, a lot, was the fact that when the PPro arrived, at an
> initial speed of up to 200 MHz, it immediately took over the crown as
> the fastest specINT processor in the world.

SPECint, but not SPECfp? After all, decent workstations had to have good
floating-point performance, and x86 was still saddled with that antiquated
8087-derived joke of a floating-point architecture.

Windows NT liked to call itself a “workstation” OS, but it was really just
a “desktop” OS.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 14 Feb 2024 21:32:11 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>There is no path forward for Windows on non-x86.
>>
>> That's entirely up to Microsoft. As has been noted, they do have ARMv8
>> versions of windows 11.
>
>They’ve been trying for years: Windows Phone 8, Windows RT, that laughable
>“Windows 10 IOT Edition” for the Raspberry Pi, whatever the name is for
>the current effort ... Windows-on-ARM has always been a trainwreck.

https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>Chicken-and-egg situation, and no way to break out of it.
>
>A possible way would be to offer the ARM-based systems much cheaper,
>making the hardware attractive to users who do not use
>architecture-specific ISV software. ...

Microsoft doesn't make PCs, and it is not clear to me how they would
bribe OEMs to do that without running into competition issues.

Apple has switched CPUs on the Mac three times, from 68K to POWER to
x86 to ARM, quite successfully since they control both the hardware
and software. Each time they provided software emulation of the
previous CPU, and the new systems were enough faster that the
emulation speed was adequate. Since nobody writes anything in
assembler any more, these days building a version of software for the
new CPU needs little more than changing a few switches and
recompiling.

On my newish M2 Mac, the only thing that doesn't work is an add-in to
the calibre ebook package. Calibre is written in python, and includes
its own copy of python so you can install it as a single app. That
works fine, most add-ins work fine. The one add-in that doesn't calls
an external crypto library, but the copy of that library on my Mac is
ARM while calibre and the add-in are emulated x86. If I cared more
I could probably figure out where to get the x86 version of the library.

Someone else pointed to a press release about ARM chips in Microsoft's
cloud. Keep reading and it becomes clear that they mostly expect
people to run linux on them.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Thu, 15 Feb 2024 15:02:38 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Wed, 14 Feb 2024 21:32:11 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>>There is no path forward for Windows on non-x86.
>>>
>>> That's entirely up to Microsoft. As has been noted, they do have ARMv8
>>> versions of windows 11.
>>
>>They’ve been trying for years: Windows Phone 8, Windows RT, that laughable
>>“Windows 10 IOT Edition” for the Raspberry Pi, whatever the name is for
>>the current effort ... Windows-on-ARM has always been a trainwreck.
>
> https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/

You know that most of Microsoft’s cloud is running Linux, right?
They’ve admitted as much themselves.

On Thu, 15 Feb 2024 19:17:49 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
> >>Chicken-and-egg situation, and no way to break out of it.
> >
> >A possible way would be to offer the ARM-based systems much cheaper,
> >making the hardware attractive to users who do not use
> >architecture-specific ISV software. ...
>
> Microsoft doesn't make PCs, and it is not clear to me how they would
> bribe OEMs to do that without running into competition issues.
>

Of course, Microsoft makes PCs.
https://en.wikipedia.org/wiki/Microsoft_Surface
I think, it is one of the reasons OEMs are not enthusiastic about
Windows on Arm. They don't want to compete with their OS supplier.

I asked google "What is a market share of Microsoft Surface?"
The answer was "In the Personal Computing Devices category, Microsoft
Surface has a market share of about 2.4%."
It means that they are near #10 spot, give or take 1 or 2 places.

> Apple has switched CPUs on the Mac three times, from 68K to POWER to
> x86 to ARM, quite successfully since they control both the hardware
> and software. Each time they provided software emulation of the
> previous CPU, and the new systems were enough faster that the
> emulation speed was adequate. Since nobody writes anything in
> assembler any more, these days building a version of software for the
> new CPU needs little more than changing a few switches and
> recompiling.
>
> On my newish M2 Mac, the only thing that doesn't work is an add-in to
> the calibre ebook package. Calibre is written in python, and includes
> its own copy of python so you can install it as a single app. That
> works fine, most add-ins work fine. The one add-in that doesn't calls
> an external crypto library, but the copy of that library on my Mac is
> ARM while calibre and the add-in are emulated x86. If I cared more
> I could probably figure out where to get the x86 version of the
> library.
>
> Someone else pointed to a press release about ARM chips in Microsoft's
> cloud. Keep reading and it becomes clear that they mostly expect
> people to run linux on them.
>

That's what I expected without reading.
The only thing that I was not sure about is whether Windows is supported
at all.
May be, I should read it myself when I have no better things to read.

On Thu, 15 Feb 2024 22:58:37 +0200, Michael S wrote:

> Of course, Microsoft makes PCs.
> https://en.wikipedia.org/wiki/Microsoft_Surface
> I think, it is one of the reasons OEMs are not enthusiastic about
> Windows on Arm. They don't want to compete with their OS supplier.

And the only reason Microsoft is offering any ARM-based machines at all is
to try to promote the platform.

I don’t think they’ve made money on any ARM machine they’ve ever sold.

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>>Chicken-and-egg situation, and no way to break out of it.
>>
>>A possible way would be to offer the ARM-based systems much cheaper,
>>making the hardware attractive to users who do not use
>>architecture-specific ISV software. ...
>
>Microsoft doesn't make PCs

They make the Surface laptops and also make Surface all-in-one PCs
(but the latter have not been updated for a while).

>and it is not clear to me how they would
>bribe OEMs to do that without running into competition issues.

Anti-trust action has been much weaker in recent decades compared to
the 1970s
<https://doctorow.medium.com/an-antitrust-murder-whodunnit-49f3bd3cc69c>.

>Since nobody writes anything in
>assembler any more, these days building a version of software for the
>new CPU needs little more than changing a few switches and
>recompiling.

And yet, most ISVs generally don't provide ARM versions of their
Windows software.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thu, 15 Feb 2024 21:31:58 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Thu, 15 Feb 2024 22:58:37 +0200, Michael S wrote:
>
> > Of course, Microsoft makes PCs.
> > https://en.wikipedia.org/wiki/Microsoft_Surface
> > I think, it is one of the reasons OEMs are not enthusiastic about
> > Windows on Arm. They don't want to compete with their OS supplier.
>
> And the only reason Microsoft is offering any ARM-based machines at
> all is to try to promote the platform.
>

My theory is that Microsoft started this route because they badly wants
to be in the business of "always connected" devices. Nowadays they hate
to sell software and very much prefer SaaS. "Always connected" helps
there or at least Satya Nadella believes that it helps.
They bought Nokia's smart phones division, but it didn't work.
So, they tried something else that went not great, but at least better.

> I don’t think they’ve made money on any ARM machine they’ve ever sold.

For Surface as whole I heared, not very recently, that it was
profitable. For Arm-based Surface specifically, I'd think it is a
sectret even within Microsoft, same as for any other Surface model in
isolation.
I happen to have a co-worker that was fired from MS Surface hardware
development not long ago. He worked there many years and never ever was
told about profitability of individual models.

On 2/15/2024 2:42 AM, Anton Ertl wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Thu, 15 Feb 2024 07:24:56 GMT, Anton Ertl wrote:
>>
>>> Microsoft is trying to commoditize their complement (in
>>> particular, Intel) by making Windows on ARM viable, but the ISVs don't
>>> play along.
>>
>> Can you blame them? They are not going to port their proprietary apps to
>> ARM until they see the customers buying lots of ARM-based machines, and
>> customers are staying away from buying ARM-based machines because they
>> don’t see lots of software that will take advantage of the hardware.
>>
>> Chicken-and-egg situation, and no way to break out of it.
>
> A possible way would be to offer the ARM-based systems much cheaper,
> making the hardware attractive to users who do not use
> architecture-specific ISV software. That would result in a
> significant number of systems out there, and would inspire big ISVs
> like Adobe to support them, increasing the appeal of the platform,
> which again would result in increased sales, which would make the
> platform attractive to additional ISVs, and so on.
>
> The first part happened for Chromebooks and the Raspberry Pi, and,
> e.g., VFX Forth (a proprietary Forth system, i.e., an ISV product) is
> available on the Raspi, even though it does not run Windows.
>
> But wrt Windows-on-ARM, what actually happens is that laptops with
> that are rather expensive. It seems that someone (Qualcomm? The
> laptop producers? MS?) wants to milk that market before it has
> calved. This doesn't work.
>

Yeah.

I would be rather tempted by a many-core ARM machine...
If they were not so expensive that one may as well stick with x86...

Meanwhile, RasPi is cheap, but a RasPi is not a worthwhile alternative
to a desktop PC.

And, if one wants something they can use mainline PCIe cards with, and
can install a bunch of SATA HDDs or similar into, this is not cheap.

Though, I suspect, this may be similar to what killed the IA-64. History
might have gone quite differently if Intel, instead of targeting it at
the high-end, made it first available as a lower-cost alternative to the
Celeron line (or, maybe even, tried to make inroads into the embedded
space, but at the time would likely have been unable to compete with
MIPS and ARM in terms of being cheap enough for use in consumer
electronics, which seemed to have been mostly dominated by 32-bit
single-issue cores).

Had it survived for longer, it could have maybe been a viable option for
smartphones and tablets.

But, yeah, for PC class systems, seemingly x86 remains as both the
cheapest and most readily available options, and as long as this remains
true, x86 will hold its ground (possibly even more so than due to any
software related issues, such as reduced performance due to emulation, etc).

....

Quadibloc <quadibloc@servername.invalid> wrote:
: While this seems like a super-niche thing to some, I see it as
: something that's practically _essential_ to have a future world of
: computers that doesn't leave older code behind - so that the
: computer you already have on your desktop is truly general in its
: capabilities.

This need is very real. At my first job the payroll ran on a
360 using the hardwware emulatior to run a 1401 simulator
for the 705 which ran the actual payroll. But,,,

The only example I pay much attention to are the various PDP-10
(not to be confused with DECSystem-10) simulators that run
PDP-10 code on current hardwaare faster than any actual 10
ever could. This seems like a much cheaper soltuions.

Sarr

--
--------
Sarr Blumson sarr.blumson@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/

On Thu, 15 Feb 2024 23:57:34 +0200, Michael S wrote:

> They bought Nokia's smart phones division, but it didn't work.

They only did that as a last-ditch effort to save face, because the
company was on the verge of giving up on Windows Phone altogether and
switching to Android.