Do you need an ARM64 compiler for Windows?

[JonRobertson 72]

42 minutes ago, Vandrovnik said:

can you imagine how many broken versions we would have to suffer if they now moved .bpls to another process

I still have problems using the "integrated" (sort of) debugger with Win64 projects.

[Anders Melander 1782]

8 hours ago, A.M. Hoornweg said:

COM was used by IDE's such as Visual Basic to host (in-process) VBX controls but it works across processes as well.

With in-process COM you'd have all the same problems without any of the benefits of the BPL/DLL packages.

 

With out-of-process COM you'd have the benefit of process separation but you would have to surface the whole TControl and design-time API bidirectionally. It would be a nightmare. Also each process would contain their own linked-in copy of the RTL/VCL.

And forget about shoehorning this into the existing IDE; It would have to be rewritten from scratch.

 

No thanks.

[David Heffernan 2345]

14 hours ago, JonRobertson said:

I still have problems using the "integrated" (sort of) debugger with Win64 projects.

Win64 debugger is known to be terrible. Perhaps slightly less so with more recent versions. I always debug 32 bit if at all possible. But sometimes you have a scenario where that's not possible. Unlucky if you do.

[David Heffernan 2345]

20 hours ago, A.M. Hoornweg said:

If you'd ask me to attempt a thing like that, I'd first look for a suitable bidirectional RPC framework. Something having capabilities like COM.  COM was used by IDE's such as Visual Basic to host (in-process) VBX controls but it works across processes as well. The "helper processes" would only need to contain the designtime part of the components, at runtime they do nothing.  Such an approach would move the design time components out of the address space of the IDE.  Also, the "bitness" of the helper processes and the IDE would be independent from each other.

How are you going to have the components paint themselves on the design surface?

[Lars Fosdal 1792]

There are ways to do that - but none of them are easy or backwards compatible.
 

[A.M. Hoornweg 144]

1 hour ago, David Heffernan said:

How are you going to have the components paint themselves on the design surface?

There are ways to achieve that (passing an EMF cross-process) but yes, it would be ugly.  It would be like re-inventing the RDP protocol.

[shineworld 73]

In my case would be amazing to have a valid Delphi compiler for ARM64 Linux + FMX.
A lot is moving in the embedded world based on ARM architectures + Linux and I've also tried FPC + Lazarus (a nightmare...).

Dreams are dreams 🙂

[David Heffernan 2345]

I think all in all, it's clear that the current in-process design is the right one

[JonRobertson 72]

2 hours ago, David Heffernan said:

I always debug 32 bit if at all possible.

I do as well.

 

2 hours ago, David Heffernan said:

But sometimes you have a scenario where that's not possible.

Such as weird UI issues that do not occur in 32-bit but do occur in 64-bit, which I've encountered more than once. 

[David Heffernan 2345]

6 minutes ago, JonRobertson said:

Such as weird UI issues that do not occur in 32-bit but do occur in 64-bit, which I've encountered more than once

Unlucky for you. I've so far never encountered such a problem.

 

The type of thing that forces me to debug 64 bit is when it's my DLL hosted in a 64 bit process, and I don't have a 32 bit version of the host.

[Sherlock 663]

Well, considering Windows on ARM will be gaining momentum as soon as some of these https://www.windowscentral.com/hardware/laptops/here-are-the-9-pc-makers-supporting-qualcomms-game-changing-snapdragon-x-elite the streets, it might be a smart move to get the compiler running. But that's just my totally unprofessional opinion. On the other hand, MS themselves are increasing the pressure. Just look at the agenda for this years "Build": https://build.microsoft.com/en-US/sessions/9d806202-be61-4b5d-ba0d-59ecfcaf0482?source=sessions

[Brandon Staggs 277]

5 hours ago, Sherlock said:

Well, considering Windows on ARM will be gaining momentum as soon as some of these https://www.windowscentral.com/hardware/laptops/here-are-the-9-pc-makers-supporting-qualcomms-game-changing-snapdragon-x-elite the streets, it might be a smart move to get the compiler running. But that's just my totally unprofessional opinion. On the other hand, MS themselves are increasing the pressure. Just look at the agenda for this years "Build": https://build.microsoft.com/en-US/sessions/9d806202-be61-4b5d-ba0d-59ecfcaf0482?source=sessions

Microsoft has been "increasing the pressure" on non-WinTel32 development for a decade. I remember thinking Embarcadero needed to hurry up and give me an option to target Windows Phone. Then to get serious about WinRT for Windows 8. Etc.

 

Windows on ARM may indeed eventually matter, but I can hardly fault Embarcadero for taking a "wait and see" approach to the latest-and-greatest non-Win32 "pressure increase" from Microsoft.

[shineworld 73]

A Windows ARM compiler could be interesting because W10/W11 can run in low-cost devices as like as Raspberry overall for kiosk or embedded user panels projects.

[Anders Melander 1782]

57 minutes ago, shineworld said:

W10/W11 can run in low-cost devices as like as Raspberry

That sounds like a horrible idea. Why on earth would you run a desktop/server OS on an embedded device?

[shineworld 73]

I've already made 😉

RPI 4b running W10 which execute intel 64 bit native code. A very low cost operator interface for a CNC. Also Open GL works but remain the price of intel to arm just in time conversion. 

All for lees than 90€...

All made with Delphi.

 

An early video of first experiments but well working. 

 

https://youtu.be/3u0L4uaigV8?si=H5mApXT-ryQ3EbGc

Edited April 12 by shineworld

[Anders Melander 1782]

I think you forgot the price of a Windows license...

 

I know it's possible to run Windows on a Raspberry Pi, I just don't think it makes sense from a business or performance POW.

[shineworld 73]

38 minutes ago, Anders Melander said:

I think you forgot the price of a Windows license...

 

I know it's possible to run Windows on a Raspberry Pi, I just don't think it makes sense from a business or performance POW.

We bought industrial Iot licence version for 45 to 89€ depending by number an type of cores. W10 1908 version. It works very fine. I in will prepare a video next week.

Edited April 12 by shineworld

[Chief 0]

Do we really need ARM64 for windows?

Not in the first place.

 

Windows ARM can run Win applications through an emulation layer.

This way, users can run our applications with some performance penalty.

 

Much worse situation with Linux ARM64, absolutely no way to use Delphi.

Check out the video below, it was posted 7 years ago, it suggested installing Android on PI. LOL.

 

 

Bringing Win ARM64 before Linux ARM64 is purely a marketing ploy greatly in line with AI things.
Guess what, IDERA seems to be doing just that.

Here's some leaked information (as far as I can tell) that confirms that Win ARM64 is on the way.

Quote

Fixed extension not showing in Windows 11 for ARM64 "Show More Options" menu. Supporting the top-level menu is still a goal, but we're waiting on Delphi's ARM64 compiler.

 

[Anders Melander 1782]

2 minutes ago, Chief said:

Here's some leaked information (as far as I can tell) that confirms that Win ARM64 is on the way.

You are going to own that claim yourself because the quoted changelog doesn't confirm anything of the sort. They just mean that they need a Delphi ARM64 compiler before they can implement top-level menus.

[Lars Fosdal 1792]

Less hearsay/leaks - more acknowledged facts, please.

[Rollo62 536]

My 5 ct:

 

Either CISC Intel/AMD manage the complete U-turn to achieve CPU/GPU/NPU at lowest power consumption with highest performance at best economic cost, or RISC will win the race in the long run.

Microsoft on ARM just shows that not everything has to be locked to x86, but also Android/iOS clearly show where the performance can be with ARM.

For me, the question is not if, but only when the ‘ARM singularity’ will happen.
If you believe in the CISC U-turn, then maybe it won't happen, but what magic wand would Intel/AMD have against Qualcom, Apple M1, Samsung, NVIDIA, TSMC and so on?
You have to bury your head very, very deep in the sand to believe in x86's sole dominance.

 

Edited October 28 by Rollo62

[Brandon Staggs 277]

On 10/26/2024 at 3:39 PM, Chief said:

Do we really need ARM64 for windows?

Not in the first place.

 

Windows ARM can run Win applications through an emulation layer.

This way, users can run our applications with some performance penalty.

 

Much worse situation with Linux ARM64, absolutely no way to use Delphi.

Bringing Win ARM64 before Linux ARM64 is purely a marketing ploy greatly in line with AI things.
Guess what, IDERA seems to be doing just that.

Here's some leaked information (as far as I can tell) that confirms that Win ARM64 is on the way.

 

Yes, we need an ARM64 Windows compiler, unless you think all of these Windows ARM64 machines are just a passing fad. Emulation is only intended to bridge the gap until applications can be rebuilt for native architecture.

 

Whether or not Linux is more urgent depends on what you are building, I suppose. For me, Linux is irrelevant and I would rather have a Windows ARM64 compiler than Linux features.

 

Also, that is not leaked information and does not confirm anything. You're making a big assumption about what that sentence means to the person writing it.

 

It's a safe bet we will eventually get an ARM64 compiler for Windows, but I suspect it is going to come with some caveats. Unless Embarcadero wants to write their own, we are going to have to settle for an LLVM compiler which means our Windows builds will not work exactly as they have for the last 30 years, particularly when it comes to exception handling.

[Brandon Staggs 277]

7 hours ago, Rollo62 said:

If you believe in the CISC U-turn, then maybe it won't happen, but what magic wand would Intel/AMD have against Qualcom, Apple M1, Samsung, NVIDIA, TSMC and so on?

Right now it's obviously a question of whether you want performance or efficiency. If you want to prognosticate you're going to decide if you think ARM will catch up and surpass on performance or if x64 will catch up on efficiency (it doesn't need to surpass on performance).

 

Regardless, it seems clear ARM is here to stay even on Windows machines.

Edited October 28 by Brandon Staggs

[Dalija Prasnikar 1396]

On 4/2/2024 at 5:02 PM, Brandon Staggs said:

This is not a trivial difference and this is likely only scratching the surface of the problems that would have to be resolved.

 

Since there is already plenty of low level RTL code that runs with LLVM based compilers, the only part where those exceptions could cause issues is VCL. I would say that this is probably less of a problem than it may look like on the first sight. 

 

On 4/2/2024 at 5:02 PM, Brandon Staggs said:

They haven't even given us a 64-bit Intel IDE yet. I doubt ARM64 is anywhere near.

Developing Windows ARM compiler is much simpler than 64-bit IDE

[RonaldK 18]

49 minutes ago, Brandon Staggs said:

Yes, we need an ARM64 Windows compiler, unless you think all of these Windows ARM64 machines are just a passing fad. Emulation is only intended to bridge the gap until applications can be rebuilt for native architecture.

Intel-based applications already run on Windows ARM. I fear that Delphi ARM64 applications are much slower than x64 applications, even though they run in the emulator.
What is the advantage for native ARM64 applications?

 

Code gen of LLVM:
https://quality.embarcadero.com/browse/RSP-17724

Edited October 28 by RonaldK