Delphi 13.2 Update

-

The Delphi 13.2 update has just been released.



Ever since the 13.1 update and the new LLVM-based Windows ARM compiler, the LLVM toolchain has entered a cycle of rapid development and improvements. 13.2 continues that trend with a completely revamped 64-bit Linux compiler, which can now be integrated with the 64-bit Delphi IDE.

The new Linux compiler is based on LLVM 20, just like the Windows ARMEC compiler, and the debugger format has been upgraded from DWARF v2 to v4, resulting in more complete debug information.

The new LLVM toolchain also brings two very important improvements: IR optimizations for better performance of compiled applications, and parallel compiling — parallel code generation — for those two newest LLVM-based compilers: Linux and Windows ARMEC.

Of course, turning on code optimization slows down the application building process, but this is where parallel code generation steps in and gives a significant performance boost.

Parallel code generation is a configurable option: You can select the desired number of worker threads, where 0 leaves that selection to automatic process (I got the best results on the Auto setting), 1 is the same as old serial code generation as it uses only a single worker, and, of course, any other number will create that many workers.

You can also enable/disable parallel code generation for each project separately through Project Options or the command line.

Speaking of compiler changes, there is one change which impacts all compilers, and it is possible that some existing code might not compile as-is and will have to be tweaked.

The change is in how the compiler treats a generic type T constrained to a class or interface. Where the compiler previously allowed automatic conversion from TObject or IInterface to T, you will now have to use variables of type T or typecast.

The change is a fix for https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-5756: IInterface argument silently accepted for TProc<T> parameter when T is constrained to IInterface — no E2010, no QueryInterface, leads to access violation

If you are now getting an E2010 Incompatible types compiler error, this fix is the reason. You should carefully inspect the code you are fixing, because that implicit conversion allowed completely incorrect conversions. In other words, it would allow using TObject or IInterface in situations where some other more specific type was expected, which could lead to runtime errors.

You can find more information about the above, and other features and enhancements, at https://docwiki.embarcadero.com/RADStudio/Florence/en/13_Florence_-_Release_2

Comments

Post a Comment

Popular posts from this blog

Delphi 13.1 Update: Windows Arm64EC compiler

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

Using atomic operations to achieve thread safety

-
Atomic operations are ones which can be executed on otherwise-unprotected shared data as a single indivisible step, where no other thread will be able to compromise the consistency of either that shared data or the operation itself. In other words, even for operation logic consisting of multiple, compound operations—steps—being atomic means that all those steps will run as an unbreakable whole on the shared data, and multiple threads will not be able to interfere with each other. Most fundamental atomic operations are actually implemented on the hardware level, and rely on specific CPU instructions to ensure atomicity, but some can also be implemented in higher level code with the help of those atomic primitives. Because hardware support is needed for the most fundamental primitives, atomic operations will be limited to simple data types commonly up to a size of a pointer. Support for atomic operations for larger data sizes—double pointers or even more—is hardware-dependent, and Del...
Read more