On Thu, 15 Feb 2024 20:58:21 GMT, Anton Ertl wrote:

> John Levine <johnl@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.

Michael S wrote:
> 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.

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.

Terje

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

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.

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?

Lawrence D'Oliveiro wrote:

> On Fri, 16 Feb 2024 08:55 +0000 (GMT Standard Time), John Dallman 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 ?!?

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?

On Sat, 17 Feb 2024 00:10 +0000 (GMT Standard Time), John Dallman wrote:

> In article <uqold3$1ha3$4@dont-email.me>, ldo@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.

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.

According to Lawrence D'Oliveiro <ldo@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.

--
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 2/16/2024 6:39 PM, Lawrence D'Oliveiro wrote:
> On Sat, 17 Feb 2024 00:10 +0000 (GMT Standard Time), John Dallman wrote:
>
>> In article <uqold3$1ha3$4@dont-email.me>, ldo@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.

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

....

On Sat, 17 Feb 2024 02:40:29 -0000 (UTC), John Levine wrote:

> According to Lawrence D'Oliveiro <ldo@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.

jgd@cix.co.uk (John Dallman) writes:
>In article <uqold3$1ha3$4@dont-email.me>, ldo@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.

I was happy with my linux-based Sharp Zaurus SL-5000 when it first came out
in 2001.

John Levine <johnl@taugh.com> writes:
>According to Lawrence D'Oliveiro <ldo@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

On Sat, 17 Feb 2024 00:10 +0000 (GMT Standard Time)
jgd@cix.co.uk (John Dallman) wrote:

> In article <uqola0$1ha3$3@dont-email.me>, ldo@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

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.

On Sat, 17 Feb 2024 16:45:48 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> John Levine <johnl@taugh.com> writes:
> >According to Lawrence D'Oliveiro <ldo@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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>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?

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-a594-88a85ac10d20o@googlegroups.com>

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Fri, 16 Feb 2024 23:38:03 +0000, MitchAlsup wrote:

>Given the choice of an ARM-based system with some SoC-specific kernel
>that is only supported for a few years

That's a false choice. See ARM BSA and SBSA.

Lawrence D'Oliveiro wrote:

> On Sat, 17 Feb 2024 02:40:29 -0000 (UTC), John Levine wrote:

>> According to Lawrence D'Oliveiro <ldo@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?

WiFi radio transceivers, bluetooth, ...

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

On Sat, 17 Feb 2024 20:05:05 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Lawrence D'Oliveiro wrote:
>
> > On Sat, 17 Feb 2024 02:40:29 -0000 (UTC), John Levine wrote:
>
> >> According to Lawrence D'Oliveiro <ldo@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?
>
> WiFi radio transceivers, bluetooth, ...
>

Those are trivial parts.
Much more importantly, they all have celular modems.
MS wants their WinARM customers to be connected to Internet all the
time, preferably even when big aplication processor is put to sleep.

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

On Sat, 17 Feb 2024 18:22 +0000 (GMT Standard Time)
jgd@cix.co.uk (John Dallman) wrote:
>
>
> The Microsoft cross-development setup required doing everything in
> their IDE.

That's very strange. I know for sure that in Vs2019 they have fully
functioning command line tools for aarch64. Was under impression that
VS2017 also has them.
It is typically more convenient to prepare the setup (project file) in
IDE, but after that you don't have to touch IDE at all if you don't
want to. Just type 'msbuild' from command prompt and everything is
compiled exactly the same as from IDE. At worst, sometimes you need to
add few magic compilation options like 'msbuild
-p:Configuration=Release'.

On 2/17/2024 5:41 AM, John Dallman wrote:
> In article <uqp7n4$87oj$1@dont-email.me>, cr88192@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.
>

( Seems my post got posted, ironically, I don't see my own post here... )

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

AFAIK:
I think the idea was that they already had 100+ registers internally
with their x86 chips (due to register renaming). And, the idea of having
128 GPRs in the IA-64, was to eliminate the register renaming?...

In my case, I have 64 registers on an FPGA, so 128 doesn't seem like too
huge of a stretch, and the FPGA can run this at around 1W.

Also, FWIW, a RV64G chip, with the privileged spec, would need 192
registers internally.

I wouldn't expect early 2000s ASIC's to be that much worse than a modern
FPGA, when by all accounts the affordable/"consumer grade" FPGA lines
are still considerably more limited than a 20 year old ASIC.

It seems like, they probably could have made it work.
Granted, whether or not that would have made IA-64 "not suck", is to be
seen.

Granted, I took a different approach from IA-64, as I realized fairly
early on that I didn't have the compiler technology to make things work
as IA-64 had intended, but could do a "cheaper" alternative to in-order
superscalar.

Though, at present, it seems things are pretty close, and it could have
made sense to also try to prioritize ease of superscalar as well.

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

Except, if they could have made the chip both cheaper and faster than a
corresponding OoO x86 chip.

As I understand it, this was the promise of IA-64.

It is like, if one looks at a Xeon, and then concludes that the Atom
would have been impossible, because of how expensive and power hungry
the Xeon is.

They could have made a chip, say, with only a tiny fraction as much
cache, ...

But, as noted, competing against the ARM chips that existed at the time
probably would have been no go.

Say:
16x 32-bit GPRs, fixed-length 32-bit instructions (say, ARMv5),
partial dual-issue, ...

Would likely have been pretty hard to beat in terms of cost, with
something like an IA-64.

> John

On Sat, 17 Feb 2024 19:22:25 +0200, Michael S wrote:

> First, because probably there would not be my preferred programmer's
> editor installed.

A commonality of OS distribution would fix that. Seems a lot of
development is moving to Linux now, which is why Microsoft is putting so
much effort in WSL. The Raspberry Pi, in particular, runs the same sort of
Debian distro widely available on x86 and over half a dozen other
architectures.

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

But the target is connected to your main PC, so it could pull indirectly
from there. Or alternatively your main PC could push to it.

On Sat, 17 Feb 2024 11:41 +0000 (GMT Standard Time), John Dallman wrote:

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

That seems insane. Since when did architectural specs dictate the levels
of cache you could have? Normally, that is an implementation detail, that
can vary between different instances of the same architecture.

On Sat, 17 Feb 2024 18:08:36 GMT, Anton Ertl wrote:

> One solution would be if MS finally switched to using Linux as the basis
> for Windows.

Once they brought a Linux kernel into Windows with WSL2, it seemed
inevitable that they would rely on it more and more, until it became a
mandatory part of a Windows install.

I would call this
<https://www.theregister.com/2023/12/14/windows_ai_studio_preview/>
the first step.

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>On Sat, 17 Feb 2024 11:41 +0000 (GMT Standard Time), John Dallman wrote:
>
>> 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.
>
>That seems insane. Since when did architectural specs dictate the levels
>of cache you could have? Normally, that is an implementation detail, that
>can vary between different instances of the same architecture.

The point of VLIW was to schedule this stuff statically at compile
time to make the best use of the memory architecture. It more or less
worked in the 1980s but as memory architectures got more complex, and
dynamic hardware scheduling got better, VLIW performance could never
keep up.

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