Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The Attack of the Killer Micros

304 views
Skip to first unread message

Quadibloc

unread,
Feb 14, 2024, 12:50:46 AMFeb 14
to
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

John Dallman

unread,
Feb 14, 2024, 4:56:35 AMFeb 14
to
In article <uqhkbh$2grub$2...@dont-email.me>, quad...@servername.invalid
(Quadibloc) wrote:

> 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.

If this had been available in the 1970s, as the IBM 700/7000 series and
others of their generation faded out of use, it would have been quite
useful.

All that code has been re-written for newer architectures or abandoned by
now; it ran on expensive systems for expensive purposes, so if it was
going to have continued uses there was usually budget to re-write it.

Now that there's general alignment on 32-bit or 64-bit addressing, 8-bit
bytes, and IEEE floating-point, portability is not such a big problem.

John

MitchAlsup1

unread,
Feb 14, 2024, 12:50:47 PMFeb 14
to
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 ??

Lawrence D'Oliveiro

unread,
Feb 14, 2024, 3:33:52 PMFeb 14
to
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.

Scott Lurndal

unread,
Feb 14, 2024, 4:32:15 PMFeb 14
to
Lawrence D'Oliveiro <l...@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

Stefan Monnier

unread,
Feb 14, 2024, 4:59:34 PMFeb 14
to
> 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

MitchAlsup1

unread,
Feb 14, 2024, 5:30:54 PMFeb 14
to
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.

Lawrence D'Oliveiro

unread,
Feb 14, 2024, 7:50:13 PMFeb 14
to
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.

Lawrence D'Oliveiro

unread,
Feb 14, 2024, 7:51:07 PMFeb 14
to
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?

MitchAlsup1

unread,
Feb 14, 2024, 8:00:47 PMFeb 14
to
This sounds remarkably like you expected sane behavior from x86 land.

Terje Mathisen

unread,
Feb 15, 2024, 1:55:02 AMFeb 15
to
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"

Anton Ertl

unread,
Feb 15, 2024, 2:34:38 AMFeb 15
to
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...@googlegroups.com>

Lawrence D'Oliveiro

unread,
Feb 15, 2024, 3:18:21 AMFeb 15
to
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.

Anton Ertl

unread,
Feb 15, 2024, 4:11:47 AMFeb 15
to
Lawrence D'Oliveiro <l...@nz.invalid> writes:
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.

Quadibloc

unread,
Feb 15, 2024, 6:27:25 AMFeb 15
to
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

Lawrence D'Oliveiro

unread,
Feb 15, 2024, 9:25:38 AMFeb 15
to
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.

Scott Lurndal

unread,
Feb 15, 2024, 10:02:44 AMFeb 15
to
Lawrence D'Oliveiro <l...@nz.invalid> writes:
>On Wed, 14 Feb 2024 21:32:11 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <l...@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/

John Levine

unread,
Feb 15, 2024, 2:17:54 PMFeb 15
to
According to Anton Ertl <an...@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, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Lawrence D'Oliveiro

unread,
Feb 15, 2024, 3:19:34 PMFeb 15
to
On Thu, 15 Feb 2024 15:02:38 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <l...@nz.invalid> writes:
>>On Wed, 14 Feb 2024 21:32:11 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <l...@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.

Michael S

unread,
Feb 15, 2024, 3:58:44 PMFeb 15
to
On Thu, 15 Feb 2024 19:17:49 -0000 (UTC)
John Levine <jo...@taugh.com> wrote:

> According to Anton Ertl <an...@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.




Lawrence D'Oliveiro

unread,
Feb 15, 2024, 4:32:02 PMFeb 15
to
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.

Anton Ertl

unread,
Feb 15, 2024, 4:44:17 PMFeb 15
to
John Levine <jo...@taugh.com> writes:
>According to Anton Ertl <an...@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.

Michael S

unread,
Feb 15, 2024, 4:57:41 PMFeb 15
to
On Thu, 15 Feb 2024 21:31:58 -0000 (UTC)
Lawrence D'Oliveiro <l...@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.


BGB

unread,
Feb 15, 2024, 5:21:02 PMFeb 15
to
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).

...

sarr.b...@alum.dartmouth.org

unread,
Feb 15, 2024, 5:43:26 PMFeb 15
to
Quadibloc <quad...@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.b...@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/

Lawrence D'Oliveiro

unread,
Feb 15, 2024, 6:25:04 PMFeb 15
to
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.

Lawrence D'Oliveiro

unread,
Feb 15, 2024, 6:25:54 PMFeb 15
to
On Thu, 15 Feb 2024 20:58:21 GMT, Anton Ertl wrote:

> John Levine <jo...@taugh.com> writes:
>
>>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.

For some reason, it’s hard (i.e. expensive) for proprietary software to be
cross-platform.

John Dallman

unread,
Feb 16, 2024, 3:55:11 AMFeb 16
to
In article <vjazN.324759$Wp_8....@fx17.iad>, sc...@slp53.sl.home
Their attitude to it has evolved quite a bit. At first, there was WinRT,
a cut-down version of Windows for 32-bit ARM, which was unsuccessful.
Then they produced full Windows for 64-bit ARM, which initially came with
a simplified GUI that was very limiting, although it could be turned off
to get the full OS.

That was viewed by MS as an "iPad killer", since it had a keyboard and
the "vastly superior Windows GUI" which did seem to be missing the point
quite badly. Development for it was supposed to be done on x64 Windows,
with the ARM Windows device being used via a USB connection, like iPad
development.

However, I found that was hopelessly inconvenient, and installed
compilers /on/ ARM Windows, using the built-in emulator, which was much
easier to work with, although a bit slow. It appears that plenty of other
people did the same thing, because MS now produce a native ARM64 Visual
Studio, after not producing non-x86 versions since NT4 days.

The available hardware has also evolved. At fist, there was only tablets
and laptops, but now Microsoft and Qualcomm sell various mini-desktop
systems for development, which are cheaper and faster than the laptops.

The ecosystem is gradually growing, and ARM Windows is available on Azure.
Qualcomm claim their Snapdragon X Elite CPUs will compete with Apple's
CPUs, although proof will have to wait for them to be available.

John

Terje Mathisen

unread,
Feb 16, 2024, 4:42:10 AMFeb 16
to
I have found the Surface machines to be very dependable, I have bought 3
of them over the years, starting with the original (?) Surface Pro which
was the first real PC model. I have since given the first two to my
kids, both are still working along with my newish (3-5 years?) night
table/travel machine.

John Dallman

unread,
Feb 16, 2024, 9:32:31 AMFeb 16
to
In article <uqm2o9$3gha2$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:

> 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

Selling it to the Celeron market would have been impossible: the games
producers would not have wanted to support it, or found it too hard, much
like Cell a few years later. The x86 emulation would not have saved it:
that was slow by the standards of the time.

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

IA-64 ran way too hot for portable devices. HP, who'd devised the
architecture, wanted it for large servers, and that was what it was
designed for. In the late 1990s, when those decisions were made, smart
mobile devices didn't exist.

John

Lawrence D'Oliveiro

unread,
Feb 16, 2024, 4:49:56 PMFeb 16
to
On Fri, 16 Feb 2024 08:55 +0000 (GMT Standard Time), John Dallman wrote:

> That was viewed by MS as an "iPad killer", since it had a keyboard and
> the "vastly superior Windows GUI" which did seem to be missing the point
> quite badly.

A similar thing is happening again, with Valve’s Linux-based Steam Deck,
that offers a handheld gaming platform with a purpose-built UI. Even
though WINE/Proton offers less-than-perfect compatibility with Windows-
only games, it still seems to have found a sustainable niche in the
market.

Microsoft has been showing off a “Handheld Mode” for Windows, in an
attempt to compete, but so far that’s just vapourware.

> Development for it was supposed to be done on x64 Windows,
> with the ARM Windows device being used via a USB connection, like iPad
> development.

Which is such a dumb thing to do, given the Linux alternatives offer self-
hosted development and deployment stacks. Even the humble Raspberry Pi
could manage that from Day 1.

> Qualcomm claim their Snapdragon X Elite CPUs will compete with Apple's
> CPUs, although proof will have to wait for them to be available.

The other thing is: why is Windows-on-ARM so heavily tied to Qualcomm
chips? ARM Linux can run on a whole range of ARM chips from a whole range
of different vendors.

Lawrence D'Oliveiro

unread,
Feb 16, 2024, 4:51:35 PMFeb 16
to
On Fri, 16 Feb 2024 14:32 +0000 (GMT Standard Time), John Dallman wrote:

> In the late 1990s, when those decisions were made, smart
> mobile devices didn't exist.

Actually, they did. PDAs, remember?

MitchAlsup

unread,
Feb 16, 2024, 6:40:59 PMFeb 16
to
Qualcomm paid for the port ?!?

John Dallman

unread,
Feb 16, 2024, 7:10:42 PMFeb 16
to
In article <uqold3$1ha3$4...@dont-email.me>, l...@nz.invalid (Lawrence
D'Oliveiro) wrote:
> > In the late 1990s, when those decisions were made, smart
> > mobile devices didn't exist.
> Actually, they did. PDAs, remember?

True, but batteries of the period could not have supported Itanium's 100W+
power consumption for any useful time.

John

John Dallman

unread,
Feb 16, 2024, 7:10:42 PMFeb 16
to
In article <uqm6gb$3h32u$1...@dont-email.me>, l...@nz.invalid (Lawrence
Yup. The Nokia decision to switch to Windows Phone looked unwise when it
was made, and that was amply proven in practice.

Microsoft made various attempts to persuade my employers to support
Windows Phone, WinRT, and Windows Store Apps. They never seemed to
understand that we were in the technical computing business, not the
personal app business. They could not, or would not, grasp that this was
a different sector, and we were confident that we'd do very badly if we
tried to switch.

John

John Dallman

unread,
Feb 16, 2024, 7:10:42 PMFeb 16
to
In article <uqola0$1ha3$3...@dont-email.me>, l...@nz.invalid (Lawrence
D'Oliveiro) wrote:

> > Development for it was supposed to be done on x64 Windows,
> > with the ARM Windows device being used via a USB connection, like
> > iPad development.
>
> Which is such a dumb thing to do, given the Linux alternatives
> offer self-hosted development and deployment stacks. Even the
> humble Raspberry Pi could manage that from Day 1.

As I said, Microsoft's approach was widely rejected and they've abandoned
it.

> The other thing is: why is Windows-on-ARM so heavily tied to
> Qualcomm chips? ARM Linux can run on a whole range of ARM chips
> from a whole range of different vendors.

My knowledge of that story is under NDA at present.

John

Lawrence D'Oliveiro

unread,
Feb 16, 2024, 7:38:18 PMFeb 16
to
On Fri, 16 Feb 2024 23:38:03 +0000, MitchAlsup wrote:

> Lawrence D'Oliveiro wrote:
>
>> The other thing is: why is Windows-on-ARM so heavily tied to Qualcomm
>> chips? ARM Linux can run on a whole range of ARM chips from a whole
>> range of different vendors.
>
> Qualcomm paid for the port ?!?

Can’t Microsoft afford to port Windows to anything else?

Lawrence D'Oliveiro

unread,
Feb 16, 2024, 7:39:26 PMFeb 16
to
On Sat, 17 Feb 2024 00:10 +0000 (GMT Standard Time), John Dallman wrote:

> In article <uqold3$1ha3$4...@dont-email.me>, l...@nz.invalid (Lawrence
> D'Oliveiro) wrote:
>>
>> On Fri, 16 Feb 2024 14:32 +0000 (GMT Standard Time), John Dallman
>> wrote:
>
>>> In the late 1990s, when those decisions were made, smart mobile
>>> devices didn't exist.
>>
>> Actually, they did. PDAs, remember?
>
> True, but batteries of the period could not have supported Itanium's
> 100W+ power consumption for any useful time.

Nevertheless, smart mobile devices did exist.

Lawrence D'Oliveiro

unread,
Feb 16, 2024, 7:42:18 PMFeb 16
to
On Sat, 17 Feb 2024 00:10 +0000 (GMT Standard Time), John Dallman wrote:

> The Nokia decision to switch to Windows Phone looked unwise when it
> was made, and that was amply proven in practice.

All the blame could very much be laid at the door of then-CEO and ex-
Microsoftie Stephen Elop.

The irony is that Nokia were already working on a decent Debian-based
phone by the time he was appointed, called the N9. He was too late to kill
it off completely, but he did see to it that it only underwent limited
release and that there were no followup models.

As I recall, it received rave reviews in the markets where it was
released. Then once stocks ran out, that was the end of it. And Nokia went
back to losing money.

John Levine

unread,
Feb 16, 2024, 9:40:33 PMFeb 16
to
According to Lawrence D'Oliveiro <l...@nz.invalid>:
>The other thing is: why is Windows-on-ARM so heavily tied to Qualcomm
>chips? ARM Linux can run on a whole range of ARM chips from a whole range
>of different vendors.

More likely the Qualcomm chips have some peripherals that Windows wants.

BGB

unread,
Feb 16, 2024, 10:04:09 PMFeb 16
to
Presumably they could have scaled it down, while still keeping the core
ISA design intact?...

Like, presumably they had wanted to use the design for things big and
small, which would not have made sense if it could only be used in big
server chips.


Granted...
It would still probably have been unable to compete directly with, say,
32-bit ARM, in the low-power parts of the market.

But, maybe, say, as a CPU for home game-consoles or set-top boxes?...


Or those thin clients that did little other than dial into the internet
and run a web-browser?...

Saw a video about one of these ("i-Opener" IIRC): Where apparently at
the time, they were sticking a full-fledged PC MOBO in the things (with
a laptop style LCD), sold on a loss, with the idea to make the money
back by people using a particular ISP.

But then people ended up realizing they could plug a normal IDE HDD into
the things and use them as low-cost computers (running whatever OS they
wanted), resulting in the company trying to disable HDD booting and
de-solder the IDE connectors, before then going out of business entirely...


Then again, the IA-64 might still not have survived even if it did
manage to entirely take hold over the set-top-box and internet appliance
market... (And, this area had seemingly now morphed into the whole
"Internet of Things" thing, and effectively shoving the internet
appliance into the front-door of a refrigerator or similar, for a "Web
Enabled" refrigerator...).


Well, I guess also there are things like "smart bulbs", which can be
programmed to turn on/off or have various RGB colors, but seemingly
lacking the feature to be able to tell them to use Quake's "fluorescent
flicker" effect as a sort of "mood lighting"... (bonus points if it can
also have the associated buzz and sparking ambient sound effect).

...


Lawrence D'Oliveiro

unread,
Feb 17, 2024, 12:20:51 AMFeb 17
to
On Sat, 17 Feb 2024 02:40:29 -0000 (UTC), John Levine wrote:

> According to Lawrence D'Oliveiro <l...@nz.invalid>:
>
>>The other thing is: why is Windows-on-ARM so heavily tied to Qualcomm
>>chips? ARM Linux can run on a whole range of ARM chips from a whole
>>range of different vendors.
>
> More likely the Qualcomm chips have some peripherals that Windows wants.

I wonder what they could be?

What’s so special about Qualcomm chips, that is so specific to Windows?
Because the products themselves don’t seem to reflect anything special.

John Dallman

unread,
Feb 17, 2024, 6:41:42 AMFeb 17
to
In article <uqp7n4$87oj$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:

> Presumably they could have scaled [IA-64] down, while still keeping the

> core ISA design intact?...
>
> Like, presumably they had wanted to use the design for things big
> and small, which would not have made sense if it could only be used
> in big server chips.

Intel and HP showed no desire at the time to use IA-64 in anything
smaller than a workstation.

The huge number of architectural registers (128 64-bit integer, 128
82-bit floating point) would have made shrinks hard. But most of all, the
design is based on the compilers being able to solve a problem that can't
be solved in practice: static scheduling of memory loads in a system with
multiple levels of cache.

> But, maybe, say, as a CPU for home game-consoles or set-top
> boxes?...
>
> Or those thin clients that did little other than dial into the
> internet and run a web-browser?...

It doesn't have any advantages for these roles over simpler, cheaper and
faster RISC or x86 designs.

John

Scott Lurndal

unread,
Feb 17, 2024, 10:36:06 AMFeb 17
to
I was happy with my linux-based Sharp Zaurus SL-5000 when it first came out
in 2001.


Scott Lurndal

unread,
Feb 17, 2024, 11:45:53 AMFeb 17
to
John Levine <jo...@taugh.com> writes:
>According to Lawrence D'Oliveiro <l...@nz.invalid>:
>>The other thing is: why is Windows-on-ARM so heavily tied to Qualcomm
>>chips? ARM Linux can run on a whole range of ARM chips from a whole range
>>of different vendors.
>
>More likely the Qualcomm chips have some peripherals that Windows wants.

Unlikely. More likely they fit the power curves required for the portable
devices like the Surface and the Lenovo Thinkpad.

https://github.com/AmpereComputing/Windows-11-On-Ampere

Michael S

unread,
Feb 17, 2024, 12:22:33 PMFeb 17
to
On Sat, 17 Feb 2024 00:10 +0000 (GMT Standard Time)
I don't know about you, but I personally find well implemented
cross-development far more convenient than 'native' development.
I never developed for Win-ARM64, so don't know how well-implemented it
was.
Many years ago I wrote few programs for Win-CE on ARM32. Those were
relatively simple programs. So simple that I didn't bother to setup the
link between Visual Studio and my target platform. I just compiled on
my PC, copied to target (originally via Windows sharing, but later on
it was founded to be limiting, so we quickly switched to FTP) and then
run them there via telnet.

I case of CE, native development was not an option, but even if it would
be an option I would not use it. First, because probably there would
not be my preferred programmer's editor installed. Second and far more
important, because it would be too much trouble keeping all sources
synchronized with company's source control servers. There is
approximately zero chance that the target would be allowed to be
connected into corporate network. And it does not matter if the target
is WinArm32, WinArm64 or LinArm32 that I developed for couple of years
ago and likely to touch again in the next couple of weeks. I would not
do it natively, even despite the absence of well-implemented
integration of cross-compiler and the target.

May be, if my apps were order of magnitude more complicated than they
actually are, I'd feel differently. May be, in this case I would prefer
good native development environment over non-integrated cross. But I
am sure that even in this case I'd prefer well-integrated cross over
any native.




Michael S

unread,
Feb 17, 2024, 12:34:12 PMFeb 17
to
On Sat, 17 Feb 2024 16:45:48 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> John Levine <jo...@taugh.com> writes:
> >According to Lawrence D'Oliveiro <l...@nz.invalid>:
> >>The other thing is: why is Windows-on-ARM so heavily tied to
> >>Qualcomm chips? ARM Linux can run on a whole range of ARM chips
> >>from a whole range of different vendors.
> >
> >More likely the Qualcomm chips have some peripherals that Windows
> >wants.
>
> Unlikely. More likely they fit the power curves required for the
> portable devices like the Surface and the Lenovo Thinkpad.
>

So do Mediatek chips.
And HiSilicon chips as well, but those, of course, are not the option in
the current political climate.

> https://github.com/AmpereComputing/Windows-11-On-Ampere

Anton Ertl

unread,
Feb 17, 2024, 1:19:38 PMFeb 17
to
Lawrence D'Oliveiro <l...@nz.invalid> writes:
Given what I read about the woes of running Linux (Android) on various
ARM-based SoCs, and the way that Windows deals with driver variations,
MS would have to pay additional SoC manufacturers to produce Windows
drivers, something that these SoC manufacturers are not set up to do.
So I guess that, indeed, MS does not want to afford the substantial
expense for porting Windows to additional SoCs, for now. I expect
that Qualcomm asked for money or other benefits to do that work for
MS, and likewise, the laptop manufacturer also had to be subsidized by
MS.

One solution would be if MS finally switched to using Linux as the
basis for Windows. Then they would automatically get all the stuff
that is done for Android and for the SBCs, although that is a sad
story, too.

Given the choice of an ARM-based system with some SoC-specific kernel
that is only supported for a few years, or some AMD64-based system,
which is supported by the Linux mainline for decades, I go for the
AMD64 system.

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

John Dallman

unread,
Feb 17, 2024, 1:22:59 PMFeb 17
to
In article <20240217192...@yahoo.com>, already...@yahoo.com
(Michael S) wrote:

> I don't know about you, but I personally find well implemented
> cross-development far more convenient than 'native' development.
> I never developed for Win-ARM64, so don't know how well-implemented
> it was.

Not well, for my uses. I don't do applications; I do porting and
performance work for mathematical modelling libraries. These are tested
in a command-line harness, which reads test data from a network server
(there's a lot of test data).

The Microsoft cross-development setup required doing everything in their
IDE. I find that very hard to use, because I'm partially sighted, and it
also doesn't understand our domain-specific programming language. That
compiles to C, but editing the C is a very poor idea: it's used as a
high-level assembly language and regenerated on every compile. Any
changes you make in it have to be back-translated into the DSL by hand
and edited into that, so nobody works that way, and the IDE is only
useful as a debugger.

The cross-development setup also required that all your test data be
bundled with the app and pushed onto the device via USB, controlled by
the IDE. There's enough test data to make that very slow indeed, and it
didn't appear possible to operate the device through the IDE. Instead,
you had to physically operate it. Somebody had apparently been told to
make it just like developing for iOS, and had given it most of those
disadvantages.

We'd killed all of those dragons in supporting iOS, and we really didn't
want to do it all again for a different platform. It was far easier to
put the devices on Ethernet, unlock the GUI and use them as ordinary
Windows machines, with our custom-written development environment.

> In case of CE, native development was not an option, but even if it
> would be an option I would not use it. First, because probably there
> would not be my preferred programmer's editor installed.

My favoured editor and tools ran straight away on ARM Windows 10, in the
x86 emulator. That made all of this practical. The difference from CE was
that ARM Windows 10 is real, full-fat Windows: the same kernel