Parallels tech preview for M1

[jdb8167]

Most of the store apps of that time where available as ARM32 binaries and they are still available in the store today. I have more than 20 apps personally, which are ARM32 from third parties, which still work today.
In fact apps for AArch32 execution state do have some advantages when it comes to memory footprint, when they are compiled for T32 - which all Windows ARM32 Apps are.

Those will stop working in the future when AArch64 Arm cores stop supporting AArch32 and Thumb. This will probably happen pretty quickly since Arm has already said they are going to stop themselves.

Edit: Do you also doubt Arm Press Releases?

Arm Pushing the Boundaries of Performance

 

[Gerdi]

Those will stop working in the future when AArch64 Arm cores stop supporting AArch32 and Thumb. This will probably happen pretty quickly since Arm has already said they are going to stop themselves.

Edit: Do you also doubt Arm Press Releases?

Arm Pushing the Boundaries of Performance

Sure, they will stop working - so unfortunate for the users i guess.

I have no doubt that ARM might release some Aarch64 only core in 2022. The question was, if AArch32 is optional in ARMv8-A - it turns out it is not. That is unless i missed the chapter where this is defined as optional - so i was asking. So linking websites and power point slides is not the answer.

Also regarding the press release, and i am speculating here - it could very well be, that the referenced Aarch64 only cores are in fact ARMv9-A compliant. You see, there was no reference to ARMv8-A in the press release.

 

[jdb8167]

Sure, they will stop working - so unfortunate for the users i guess.

I have no doubt that ARM might release some Aarch64 only core in 2022. The question was, if AArch32 is optional in ARMv8-A - it turns out it is not. That is unless i missed the chapter where this is defined as optional - so i was asking. So linking websites and power point slides is not the answer.

Also regarding the press release, and i am speculating here - it could very well be, that the referenced Aarch64 only cores are in fact ARMv9-A compliant. You see, there was no reference to ARMv8-A in the press release.

I already posted a developer overview from the Arm website that shows that you can have AArch64 only cores. I'm not sure what else you want. If Arm's official documentation isn't enough then I guess nothing will be.

 

[Gerdi]

I already posted a developer overview from the Arm website that shows that you can have AArch64 only cores. I'm not sure what else you want. If Arm's official documentation isn't enough then I guess nothing will be.

Again, websites are no architecture reference. The only reference is the ARMv8-A architecture reference manual. I sincerely hope that we do not need to discuss if a website, even if it is from ARM, takes precedence over the ARMv8-A architecture reference manual.

 

[dmccloud]

To my understanding, they can directly use the Windows RT era stuff, which is pre-ARMv8, and save some work to rewrite code.

Same applies to 3rd party apps, there are tons of Window RT era apps in the store, which is arm32 exclusive.
This is also a big difference between Apple and Microsoft: Apple will remove the app from App store if it is not 64-bit.

Microsoft is beholden to backwards compatibility, both in terms of the OS and the x86 (and now ARM) architectures. They should make a clean break like Apple did with Catalina, but nobody in Redmond will ever say that out loud lets they incur the wrath of PC manufacturers and developers...

 

[jdb8167]

Microsoft is beholden to backwards compatibility, both in terms of the OS and the x86 (and now ARM) architectures. They should make a clean break like Apple did with Catalina, but nobody in Redmond will ever say that out loud lets they incur the wrath of PC manufacturers and developers...

They are just delaying the inevitable. It would be better to deprecate AArch32 while adoption is very low. I guess the odds of WoA adoption increasing rapidly is pretty low so not much risk. If they introduce a new Arm Surface notebook/tablet after 2023 they will have to bite the bullet and obsolete existing applications.

 

[dmccloud]

Again, websites are no architecture reference. The only reference is the ARMv8-A architecture reference manual. I sincerely hope that we do not need to discuss if a website, even if it is from ARM, takes precedence over the ARMv8-A architecture reference manual.

The 8000+ page architecture reference manual has over 30 references to "AArch64 Only" in the first 100 pages alone. That is consistent with jdb's points made regarding 64-bit only designs. I do find it hilarious that you tried to say that ARM's website was somehow less accurate then ARM's architecture manual, when they both say the same thing.

They are just delaying the inevitable. It would be better to deprecate AArch32 while adoption is very low. I guess the odds of WoA adoption increasing rapidly is pretty low so not much risk. If they introduce a new Arm Surface notebook/tablet after 2023 they will have to bite the bullet and obsolete existing applications.

Redmond's decision to just reuse the Surface RT libraries for WoA is insane to me. I had one of those RT machines, and it was a steaming pile of crap on its best days. It feels like Microsoft hasn't even been trying, and is only now really looking at ARM seriously because of Apple and the M1.

 

[tdar]

To my understanding, they can directly use the Windows RT era stuff, which is pre-ARMv8, and save some work to rewrite code.

Same applies to 3rd party apps, there are tons of Window RT era apps in the store, which is arm32 exclusive.
This is also a big difference between Apple and Microsoft: Apple will remove the app from App store if it is not 64-bit.

Most of the Microsoft apps that are Arm32 are in the process of being rewritten for a new look and feel update that is coming. I'd expect the new apps will be 64 bit.

 

[Gnattu]

Again, websites are no architecture reference. The only reference is the ARMv8-A architecture reference manual

I don't know what to say now, because ARM having bunch of aarch64 only ARMv8-A processors themselves. What you are impling is that ARM is not obeying the standard themselves and it does not make any sense to me. There might be other documentation specifically for core implementations but not available to the public, only the licensees. What the architecture supports has nothing to do with the design. The Cortex-A34, Cortex-A65 and Cortex-A65AE are all aarch64 only designs and they are out one year earlier than the M1.

 

[Gnattu]

Those will stop working in the future when AArch64 Arm cores stop supporting AArch32 and Thumb. This will probably happen pretty quickly since Arm has already said they are going to stop themselves.

Edit: Do you also doubt Arm Press Releases?

Arm Pushing the Boundaries of Performance

ARM launched aarch64 only designs back in 2019, it is already happed, not "going to".

 

[jdb8167]

ARM launched aarch64 only designs back in 2019, it is already happed, not "going to".

Right but after 2022 all new Cortex-A “big” cores will only support 64-bit.

 

[Gerdi]

ARM launched aarch64 only designs back in 2019, it is already happed, not "going to".

You need to read more carefully. It is totally correct that they do have the Cortex-A65 core, which implements only the AArch64 execution state of the ARMv8 architecture. Nothing inherently wrong with this - in particular since Cortex-A65 is targeting embedded systems. They also have the Cortex-A32, which implements only the AArch32 execution state of the ARMv8 architecture. You could conclude from this, that also AArch64 is optional, just because such a core exists.

The question was however, if the implementation of AArch32 is optional in the ARMv8 spec. So an implementation compliant with the ARMv8 spec cannot drop AArch32 (and neither can it drop AArch64) - as both are not declared optional - at least to my knowledge. This holds in particular, since the ARMv8-A reference manual explicitly says that optional features are explicitly declared optional in the document. (i already did cite this part of the spec earlier).

The 8000+ page architecture reference manual has over 30 references to "AArch64 Only" in the first 100 pages alone.

Thats a good one. The term "AArch64 only" are used in the spec, whenever there is a feature, that is only available in AArch64 execution state. Surely there are some features only available in AArch64 state and others are only available in AArch32 execution state.

 

[Gnattu]

Nothing inherently wrong with this - in particular since Cortex-A65 is targeting embedded systems.

So an implementation compliant with the ARMv8 spec cannot drop AArch32 (and neither can it drop AArch64)

So you mean that, Cortex-A65 is NOT an ARMv8-A compliant design ?

 

[Gnattu]

whenever there is a feature

To your own words. AArch32 is not a feature, it's an execution state. The statement "optional features are explicitly declared optional" does not apply to this.

 

[Gnattu]

Anyway, the debate on words is way off topic here. My point is clear: unlike the x86 world, a 64-bit arm processor does not necessarily have the 32-bit execution state. The guys at Linux Foundation knew that back in 2012, the devs of arm platform knew that more than 6 years ago, and ARM themselves is making processors that is aarch64 only. This is the FACT, that will not changed by whatever paper saying. Include 32-bit apps in a 64-bit only OS(WOA is 64-bit exclusive) and assume all processors capable of running the OS can run those 32-bit apps is a bad and wrong choice due to the FACT that

1. 32bit apps on 64bit only OS makes no sense in the first place
2. 64bit only processor exists and this is well-known for years, such decision will break functionality on those processors

 

[bobcomer]

UTM actually works, running x64 Windows 10. A Macbook Air really isn't suitable for running it though. You really need an active cooling system if you want to use it a lot. It'll do in a pinch though, so thanks for mentioning it! I'll probably end up installing an older OS for emergency use...

I can't get networking to work at all in UTM on my MBA. It runs OS's, but that's all I can test without networking...

 

[bobcomer]

My current issue with the M1 and Java is that Eclipse doesn't run. I might have to pay for and learn IntelliJ IDEA.

The IBM Notes (Domino) client doesn't run in either the Windows VM or on MacOS. It's based on Eclipse I'm pretty sure. And that's something I really need. There's other things that don't run too, but I am making some headway.

 

[KingOfPain]

I can't get networking to work at all in UTM on my MBA. It runs OS's, but that's all I can test without networking...

You could try to install a driver for the virtio network device (which is available on an ISO) as described for ACVM:

GitHub - ubenmackin/ACVM: GUI frontend for qemu for Apple Silicon based Macs

GUI frontend for qemu for Apple Silicon based Macs - ubenmackin/ACVM

github.com

Caveat, I haven‘t tested this for x86 Windows only for ARM Windows, but I don‘t see why it shouldn‘t work.

 

[bobcomer]

You could try to install a driver for the virtio network device (which is available on an ISO) as described for ACVM:

GitHub - ubenmackin/ACVM: GUI frontend for qemu for Apple Silicon based Macs

GUI frontend for qemu for Apple Silicon based Macs - ubenmackin/ACVM

github.com

Caveat, I haven‘t tested this for x86 Windows only for ARM Windows, but I don‘t see why it shouldn‘t work.

Thanks, I'll take a look at it.

 

[SquealingCustard]

I found the network to be very intermittent sometimes it does not work at all other times it randomly kicks in for about an hour or so then disappears again.

 

[pldelisle]

Has anyone tried running ARM Linux with Parallels Tech Preview on M1 ? Like Ubuntu, CentOS, Red Hat or Debian ?

Thanks.

 

[gank41]

Has anyone tried running ARM Linux with Parallels Tech Preview on M1 ? Like Ubuntu, CentOS, Red Hat or Debian ?

Thanks.

Ubuntu for ARM is running fine on my end, although there’s still no Parallels Tools support. I would assume that’d be coming soon, though.

 

[pldelisle]

Ubuntu for ARM is running fine on my end, although there’s still no Parallels Tools support. I would assume that’d be coming soon, though.

Thanks !

 

[bobcomer]

Has anyone tried running ARM Linux with Parallels Tech Preview on M1 ? Like Ubuntu, CentOS, Red Hat or Debian ?

Thanks.

I'm running Ubuntu here too, seems to work well, though like the other guy said, no tools, so video isn't great.

 

[bobcomer]

A new build of Windows on Arm came out and I must say it's actually working well for the testing I've done. It even ran the VB app that used ODBC correctly. (if a bit slow). I haven't tested everything yet.

So maybe Microsoft will eventually make WOA viable to run an x86(64) workload in a VM. Now all they have to do is license it. I don't really like how they're handling the emulation, but I'm a results guy more than anything, if it works, it works.

fwiw, my MBA got to 70C running that VM, but performance was good. (running the Parallels beta)