Windows-10/11 on a Raspberry Pi

"David Taylor" snipped-for-privacy@blueyonder.co.uk.invalid> wrote

| This is all just for fun - no serious use intended, but perhaps to see whether | any x86 programs might work. |

It's an ARM CPU. It requires ARM Windows, which is probably a simple kiosk system for running tablet trinket apps. There would be no way to adapt Win32 to that without a whole set of system files to intercept calls, with the Win32 software in some kind of sandbox. Something like WINE. But even WINE is working on the same CPU. It's just translating function calls to Linux libraries, not translating CPU instructions.

It needs something like Apple's Rosetta which they used when they went from PPC -> Intel or Rosetta 2 when they went from Intel -> ARM

...

According to this article you need Windows-11 to get x86 emulation on ARM64

More info:

Microsoft have something like that too - for windows-11

It ought to be simple to write a CISC microcode for an ARM to emulate at leats a 8086. But how fast it would run is another matter

You have to have duplicates of all the libaries and frameworks, too. All of which need testing when you make a new OS version. Which is why Apple doesn't keep Rosetta around for ever, especially as you also need duplicates of all the libaries and frameworks for 32-bit and 64-bit. It's prolly why Apple dropped 32-bit support in going from Mojave to Catalina (which I'm now on), as they knew they had the transition to ARM coming up. Not that the loss of

Arms don't use microcode. However you can write an emulator in Arm instructions, which Microsoft have done.

Well then, it's handy that Microsoft have done all that, and you can buy laptops and desktops with Windows on Arm, including x86 emulation, right now.

Theo

I think the point of a full processor emulations is that all the *86 code 'just runs' on it

But that doesn't mean it will run *fast*.

That is what I meant. Microcode is a machine code interpreter running

The world is going ARM. It doesnt match *86 for total CPU crunch, but crunch per watt is very good

First off ... Win10/11 are *huge* ... you'd likely need a large-ish external drive. Samsung sells some good USB3 external SSD drives and I've used 'em with Pi.

BEST chance ... VirtualBox or KVM ..... you are NOT gonna run Win even semi-directly on a Pi/ARM. Oh, DO buy the Pi4 with the BIG memory. By the time you're done it'd be easier to just find a used i5 board and run Win on that.

BEST chance ... VirtualBox or KVM ..... you are NOT gonna run Win even

Thanks for the suggestions.

Actually Win-11 fits on a 32 GB SD, but not much room for big programs! A 1TB SanDisk external SSD is noticeably faster, though. Transfer speed is then limited by the RPi-400 USB-3 port.

Yes, I have Win-11/64/ARM running /directly/ on an RPi-400. It runs some x86 programs too. There's no support for the RPi built-in Wi-Fi so it's either an external adapter (I used a Wi-Fi to Ethernet, but a slow one!) or a direct LAN connection.

I have no experience, but it sounds like nobody else here does either. That page is 2 years old and things change. The best resource I could find is:

Windows isn't that huge. 32GB is the minimum, 64GB is better, 128GB gives you plenty of breathing space. All of which are sub-$10 microSD cards. Granted you probably want a faster SSD, but it's not bigger than today's bottom-tier storage devices.

Sure, if you just want a Windows desktop then an x86 box is the way to go. However if you have a Pi already, or just want to run one Windows app and don't have an x86, then Windows on Arm is possible. Not recommended, but possible.

Theo

The preferred high-performance emulation strategy is object code translation, usually managed dynamically, like “throw-away compilation”. When applied to loops and other frequently recurring code, performance can approach native host performance.

Well possibly. What you are essentially describing is external microcode to turn a RISC core into a CISC machine. But a quad core i7 ot i8 has massive pipelining as well. And that needs to be on chip.

Your description is correct—in fact, I often described RISC machines as “compile to microcode” machines! I’ve mostly seen object code translation used as a “compatibility” or “migration” strategy rather than viewing it as an implementation technique for a CISC architecture.

By “native host performance” I meant that the code performance can approach the native performance of the code compiled for the RISC host. In fact, it can exceed this performance, since the object code translation is done dynamically in the presence of actual data, a benefit unavailable to source code compilers.

And RISC architectures are quite amenable to aggressive pipelining and multiple instruction dispatch—something that gets quite hairy with the x86 architecture (but of course Intel is not afraid of hairyness ;-).

On of the nice features of 32 bit ARM at least as far as human programmers of earlier ARMs, was conditional instructions, which eliminated the need for pipeline stalling branches around small sections of code.

However, with more sophisticated processors it prevents the branch predictor eliminating the instructions entirely from the pipeline (the vast majority of the time), and instead evaluates to NOPS taking up execution slots. It also makes the go faster stripes of superscalar and out of order execution more tricky and less efficient.

With a code translator the conditional 32 bit instructions can be turned into 64 bit code sections surrounded by small branches, making it look like horrible spaghetti code for humans (if anyone still eyeballs AArch64), but far more optimal to modern CPUs.

---druck

Many years back, I worked were we did conversions of games for 6502 based home computers to Z80 machines. We were able to get the source for some 6502 games as the conversion needed to be done very quickly. Large amounts of the game logic was rewritten in native Z80 but there was significant amounts of maths in the game's "real world". We used a 6502 simulator where each 6502 instruction was used to find canned chunks of Z80 code. The maths stuff typically ran at 65% of the native 6502. We added extra 6502 instructions so you could be in the 6502 emulation and execute a JSRZ80 opcode that let you run large amounts of Z80 native code and return back into the emulator. The result was the game played the same on Z80 home computers as on 6502 computers. Apple copied us and did similar stuff when it started offering PowerPC based Macs and had the Mac Toolbox code in both PowerPC and 68000 versions. Sometimes it was quicker when emulating 68000 code to emulate 68000 Toolbox code than jump back forth between PowerPC and 68000 mode. Apple never paid us royalties for the idea!

Now I work on full simulation of SoCs using ARM CPUs as well simulation of the other hardware we do dynamic JIT compilation of x86-64 code snippets based on the inputted ARM code. I'd have thought that maybe generating, executing, discarding and regenerating the code would be less efficient but commonly used sections get cached and this method also makes simulation of things like cache-coherent memory on the ARM side easier.

Yea, they're just mostly in two different universes.

PIs were meant to fit a *niche* between microcontrollers and "real PCs" ... and IMHO they oughtta stay there. It's a valuable niche. Anything much more than a Pi4 or Pi5 and you may as well just buy a low-end mini PC or use and old Win laptop. There are 'NUC's these days, and some newer "Bee"-somethings, that are reasonably small and 'inexpensive'. Could probably run Linux on some, but the Pi and Linux go together much more logically.

There ARE competitors to the PIs now. The two 'fruity' ones, Orange and Banana, are OK - but last I looked do not have onboard WiFi. I *think* I saw that newer ones were coming out that did (and had *horrible* performance from USB/WiFi adapters on the existing units). The old loved BBBs I think *do* have WiFi now - and run Linux - but not sure about the performance. The base Pi4 plus 'Motion' can handle at least two 4k cams (though it is smart to use 'cpulimit' to keep it from using up the entire capacity). For 1080p I have one dealing with SEVEN cams ... two attached, five remote wireless ... with 'Motion' and it's NOT overloaded (at 1-fps anyhow).

I bought a newer BBB but haven't had a chance to play with it yet. It, plus the relay 'cape', may be the core of my home security system if the PIs disappoint. Have one Banana + Motion serving an mjpeg stream from a security webcam (though it does have to use plug-in networking). Still cheaper, and more versatile, than many lower-end 'IP security cams'. Actually a Pi2b plus Motion can serve ONE webcam stream quite nicely.

I like the PI "niche" - it is in sync with how I like to use 'computers' - for 'devices'/'things'. Leave the other crap to M$ Winders .....

(ok, I own NO Winders computers at all - even this laptop is MX Linux ... never ran Winders for one second, which I'm proud of :-)

NUCs aren't that cheap. But Linux works fine on them (my main desktop is a NUC).

When a 16G Pi5 comes out, I'd be interested in what its cost would be with an NVME adapter. But suspect that'll be well into next year. I reckon from what I've read that the performance would be pretty close to my 16G I5 NUC with NVME SSD - and I suspect it would be a lot cheaper. And I suspect it would use less power.