Delphi 13.1 Update: Windows Arm64EC compiler

-

The Delphi 13.1 update has just been released.

One of the most significant new features in this update is the new 64-bit Windows ARM EC compiler.



With ARM taking a strong foothold in desktop, laptop, and tablet computers, this is an additional Windows platform which can no longer be ignored. Now, if there is one thing that Microsoft does well, it is compatibility support for existing applications. Which means even your existing 32-bit and 64-bit Intel-based Windows applications will run on the Windows ARM OS.

With that in mind, having a Windows ARM compiler at this time may not seem like a mission-critical feature, but this compiler still represents an extremely important milestone in Delphi's evolution. There are several reasons for that.

First of all, Delphi developers are primarily Windows developers. Even if we support other platforms, Windows is and will always be our turf. Because Windows ARM EC supports both the VCL and FMX visual frameworks, no matter what kind of Delphi Windows applications you are developing, you will be able to compile that code with the new Windows ARM EC compiler. It is a feature that basically all Delphi developers can use.

Next, this compiler is supported only in the 64-bit Delphi IDE. Now, this is certainly a downside because the 64-bit IDE only supports the 64-bit Windows platform (and now new 64-bit Windows ARM). So for all other platforms you still need to use the 32-bit IDE. This means juggling between two IDEs, which is far from ideal.

Because of that, the 64-bit IDE is still primarily used only by developers with large projects targeting 64-bit Windows which cannot be efficiently developed in the 32-bit IDE due to memory restrictions, or is occasionally used for debugging 64-bit Windows applications with the slower, but significantly more stable 64-bit debugger.

Having a new Windows platform only supported by a 64-bit IDE means that more and more developers will start using the 64-bit IDE, either partially or fully, and this will definitely help find any remaining issues and polish it to the point where it can become the IDE of choice for most Delphi developers.

Another extremely important aspect of the new Windows ARM compiler is that unlike existing Windows compilers, this one is LLVM-based, and also uses a LLDB-based debugger.

Again, this is a double edged sword. LLVM-based compilers, as well as LLDB-based debuggers, are much slower than the old compilers and debuggers. LLVM optimization passes are also not fully utilized, and the resulting application will not run as fast as it could.

Another bad feature of LLVM-based compilers is their exception handling, where non-call hardware exceptions will not be caught and handled by immediate try..except and try..finally blocks. See: Catch Me If You Can - Part II and Catch Me If You Can

Some of the deficiencies of the LLVM/LLDB-based toolchain and its integration with the Delphi ecosystem can and will be resolved with time, and eventually those compilers and debuggers can become a solid foundation for the future evolution of Delphi as a language and a toolset, where the old non-LLVM-based compiler will become deprecated.

Of course, this is just a distant future at this moment, and I am certainly not advocating for the abandonment of the existing Windows toolchain, but whether we like it or not, this is the direction Delphi must eventually take in order to survive and grow. Maintaining and supporting two different ecosystems requires more effort and is slowing down future progress.

An LLVM-based Windows compiler brings focus back to the platform used and targeted by the majority of Delphi developers, which will certainly bring more eyes to the already known and unknown problems, and more incentive for Embarcadero to fix those faster.

Having a Windows-based LLVM compiler also means that finding and solving bugs in our own cross-platform code is now not too different from finding bugs in other Windows code. Provided that you have a computer which runs the Windows ARM OS, you will be able to install and run the Delphi IDE on such a computer, and subsequently run and debug your application directly on that device and its OS.

Considering that finding bugs in code caused by differences in behavior between different compiler architectures was a rather painful process, this is also exceptionally good news for all Delphi developers writing and maintaining cross-platform code.

This will also drastically simplify testing workflows, because you will no longer have to run all tests for non-platform specific code outside the Windows platform. The differences in ABI between Windows ARM and other platforms still exist and will require additional testing, but vast majority of otherwise cross-platform code can now be properly tested using only different Windows targets.

For all Delphi developers who are currently only developing Windows applications, this compiler also makes it easier to gradually step into cross-platform development, transitioning their code to the LLVM-based toolchain under the familiar Windows platform and making that code work well, before facing the other challenges and requirements those different operating systems impose.

You can find what else is new at RAD Studio 13 Florence - Release 1

Comments

Post a Comment

Popular posts from this blog

Universal storage for Delphi procedural types

-
Delphi's procedural types fall into three categories: standalone procedures and functions, methods, and anonymous methods. The variables that can store those types are all different, both in their memory size and their nature. Further differences between various procedural types come from the number of parameters they have and their types, as well as whether they return some result—whether they are functions. Those differences have an impact on how they are invoked, but not on their storage—the variables and their memory layout. Two procedural types will be compatible with each other, if they are of the same category, have the same calling convention, have the same number of parameters (including the return value or lack of it). and those parameters and return value are of the same types and declared in the same order. The declared parameter names can be different, and don't affect this compatibility. Declaring any of those procedural types has some common parts: a type iden...
Read more

Delphi 13 Florence: 64-bit IDE debugging experience

-
Image
Anyone who has ever debugged a 64-bit application in Delphi, especially one that involves multiple threads, has probably experienced disconnected session issues, or the IDE not showing watch values, or simply getting non-responsive in the middle of a debugging session. The new 64-bit IDE and its LLDB-based debugger provide a solution to such problems. You may no longer have to sprinkle your code with logging code that is otherwise not needed; nor will you have to waste hours trying to catch some error, only for Delphi to die on you when you are two lines of code away from discovering the problem. However, it is not all that peachy. Namely, LLDB has its own quirks. First of all, it is dog slow. It is slow when evaluating breakpoints, it is slow when handling exceptions (even ignored ones), it is slow when it stops at a breakpoint and shows local variable values. The more powerful computer you have, the better the experience will be. While there is still plenty of room for improveme...
Read more

Delphi 12.3 Update

-
Image
The Delphi 12.3 update has just been released. The most exciting part of this release is the long-awaited 64-bit IDE. Now, this is only an Initial Release of the IDE, and it is not yet a full replacement for the 32-bit IDE and its functionality. The main advantage of the 64-bit IDE is that the available memory is no longer constrained by the 32-bit address space, and the upper limit is now the available system memory. The more you have, the more you can use. This is a great news for all developers with large projects, where the 32-bit IDE would easily hit the memory wall. To start with, the 64-bit IDE only supports the 64-bit Windows platform. The primary purpose of such a release with only partial functionality is to allow all component developers to update their design-time packages, and prepare them to support the 64-bit IDE. And to do that, you only need the 64-bit Windows platform anyway. For all other platforms, there is no immediate advantage of using a 64-bit IDE. As we all...
Read more