It appears your reviewer spoke about Delphi XE3 instead of Delphi XE2.
Your reviewer was gazing too much into the future and went 2 or 3 years ahead of time.
From educated guessing, Embarcadero will ship with 64-bit compiler preview in 30-60 days* (worse case: 80+ days) from now with time-frame to be around April/May 2011 time. This is evident with a big Embarcadero promotion (presumably to get rid of old stock) currently on right now.
How will the Delphi 64-bit preview fare? Your reviewer looks at all the VCL64 evidence and it looks grim. Unless they do good QA testing, it feels like similar experience to Delphi 2 (read: full of bugs) and took 2+ years to stabilize. (hint: Delphi 5/6/7-era)
They would probably change the Integer size:
Integer = +/- 2^63
LongInt = 2^64;
UInt64 = 2^63;
Correction:
There is no change in Integer size, just pointer size -->
64 bit compiling will not change for certain integer sizes, but only Win32 APIs that integer map pointers. Pointers will be 64 bit.
Correction #2:
There is no i386 FPU levels, masks, op-codes in 64-bit mode.
Piecing the 64-bit jigsaw
Dcc32.exe does a "one-pass compile". That means, many of the symbols are ready-made and resolve at link-time (see: rlink32.dll) immediately.
Dcc32 consists of two parts: dcc120.dll (called from the IDE) and dcc32.exe (called from command-line). The DCU files are intermediate machine language (usually i386 with few optimizations) with preamble (like basic checks, i.e., before a maths operation is called, it calls the overflow check, those that you find on the compiler tab) and restores the CS:EIP (Counter Stack, Instruction Pointer), Data Segment and Stack.
For dcc64, looking at the current integration (assuming they are going with a 32-bit IDE with 64-bit debugger bridge), then they would need to write a debugger bridge that translates __debugbreak() (previously known as Int3) into 32-bit equivalents with to and from 64-bits.
Assuming they did write a VCL/64, they (those at Embarcadero) writing the 64-bit VCL, they would need to roll-back to older versions of the same code (such as IntToStr before it became all-assembly) and translate that to 64-bit equivalents. They could do it both ways: For example, write to SSE2 registers or use NEON (Android/IPhone) registers.
How your reviewer would do 64-bits.If your reviewer was doing a compiler, your reviewer would use the Edison Design Group front-end compiler with back-end Dinkumware for the RTL x64, instead of hacking and slashing through MMX or older assembly optimizations.
Troublesome Console Application?Your reviewer looked at the tiny or very little information about VCL64, DCC64, RLINK64, DCC1xxx64.DLL and other files and wondered what's taking Embarcadero so long?
The trouble seems to be the bridge between 32-bits and 64-bits. In Visual Studio, they use a smaller version of the Visual Studio remote debugger to host the 64-bit EXE and Visual Studio "talks" to the remote debugger interface.
For Embarcadero, either they missed the boat or didn't bother to update TDEBUG32 to TDEBUG64 equivalent for very long time.
For example, if you write "array of [1..65536] of widestring" in your code in Delphi 2005, 2006, this would cause a DCC failure when "Include Remote Debugging Symbols" is turned on -- because array of widestring is not clearly defined in TDBUG32 information.
Who uses TDEBUG32 information? The former TurboPower SysTools, the former MemProof on Automated QA website before it was removed, AQTime, AQ(whatever) products.
Before you can write a debugger, you need to have properly working symbol generation working. Suppose you have to build a remote debugger bridge to bridge between 32/64-bit EXE debugging.
Hence, your reviewer guesses:
1) Delphi 64-bit compiler is missing the debugger when it comes out... or if Embarcadero releases it, it would be half baked or have so many bugs and issues, it becomes impossible to debug a large app.
2) Delphi XE was released on 30th August 2010. Assuming that Delphi XE2 would be released usually 365 + 30 days later (to annoy Delphi developers to update their SA subscription)
3) Delphi x64 compiler preview would disappoint many people. They think it's complete product ready to recompile their favorite app into x64 but it's not -- the next group of people who need to get rid of all the old 32-bit assembly and check their product to work with x64 are the component vendors. The larger vendors (DevExpress) do not even have any Delphi x64 news.
That means, give or take a year to make Delphi x64 stable, it could drag on to 2012 or 2013 more to get a stable compiler... by that time, most of the Delphi developers would have been out-foxed, beaten by their 64-bit competitors, without house, without any way to make more money... making 32-bit EXEs is no longer a marketable asset.
The people who still use Delphi will have to make hard choices when the 64-bit preview comes out...
The less information Embarcadero gives on the compiler development status (other than just being very silent) the more people will start to wonder WTF is happening?
:)
Article notes:
- For non-English speakers: "Tea Leaves" means predicting the future based on known available information.
- Spelling mistakes corrected.
- Pointer information corrected.
Your reviewer was gazing too much into the future and went 2 or 3 years ahead of time.
From educated guessing, Embarcadero will ship with 64-bit compiler preview in 30-60 days* (worse case: 80+ days) from now with time-frame to be around April/May 2011 time. This is evident with a big Embarcadero promotion (presumably to get rid of old stock) currently on right now.
How will the Delphi 64-bit preview fare? Your reviewer looks at all the VCL64 evidence and it looks grim. Unless they do good QA testing, it feels like similar experience to Delphi 2 (read: full of bugs) and took 2+ years to stabilize. (hint: Delphi 5/6/7-era)
Correction:
There is no change in Integer size, just pointer size -->
64 bit compiling will not change for certain integer sizes, but only Win32 APIs that integer map pointers. Pointers will be 64 bit.
Correction #2:
There is no i386 FPU levels, masks, op-codes in 64-bit mode.
Piecing the 64-bit jigsaw
Dcc32.exe does a "one-pass compile". That means, many of the symbols are ready-made and resolve at link-time (see: rlink32.dll) immediately.
Dcc32 consists of two parts: dcc120.dll (called from the IDE) and dcc32.exe (called from command-line). The DCU files are intermediate machine language (usually i386 with few optimizations) with preamble (like basic checks, i.e., before a maths operation is called, it calls the overflow check, those that you find on the compiler tab) and restores the CS:EIP (Counter Stack, Instruction Pointer), Data Segment and Stack.
For dcc64, looking at the current integration (assuming they are going with a 32-bit IDE with 64-bit debugger bridge), then they would need to write a debugger bridge that translates __debugbreak() (previously known as Int3) into 32-bit equivalents with to and from 64-bits.
Assuming they did write a VCL/64, they (those at Embarcadero) writing the 64-bit VCL, they would need to roll-back to older versions of the same code (such as IntToStr before it became all-assembly) and translate that to 64-bit equivalents. They could do it both ways: For example, write to SSE2 registers or use NEON (Android/IPhone) registers.
How your reviewer would do 64-bits.If your reviewer was doing a compiler, your reviewer would use the Edison Design Group front-end compiler with back-end Dinkumware for the RTL x64, instead of hacking and slashing through MMX or older assembly optimizations.
Troublesome Console Application?Your reviewer looked at the tiny or very little information about VCL64, DCC64, RLINK64, DCC1xxx64.DLL and other files and wondered what's taking Embarcadero so long?
The trouble seems to be the bridge between 32-bits and 64-bits. In Visual Studio, they use a smaller version of the Visual Studio remote debugger to host the 64-bit EXE and Visual Studio "talks" to the remote debugger interface.
For Embarcadero, either they missed the boat or didn't bother to update TDEBUG32 to TDEBUG64 equivalent for very long time.
For example, if you write "array of [1..65536] of widestring" in your code in Delphi 2005, 2006, this would cause a DCC failure when "Include Remote Debugging Symbols" is turned on -- because array of widestring is not clearly defined in TDBUG32 information.
Who uses TDEBUG32 information? The former TurboPower SysTools, the former MemProof on Automated QA website before it was removed, AQTime, AQ(whatever) products.
Before you can write a debugger, you need to have properly working symbol generation working. Suppose you have to build a remote debugger bridge to bridge between 32/64-bit EXE debugging.
Hence, your reviewer guesses:
1) Delphi 64-bit compiler is missing the debugger when it comes out... or if Embarcadero releases it, it would be half baked or have so many bugs and issues, it becomes impossible to debug a large app.
2) Delphi XE was released on 30th August 2010. Assuming that Delphi XE2 would be released usually 365 + 30 days later (to annoy Delphi developers to update their SA subscription)
3) Delphi x64 compiler preview would disappoint many people. They think it's complete product ready to recompile their favorite app into x64 but it's not -- the next group of people who need to get rid of all the old 32-bit assembly and check their product to work with x64 are the component vendors. The larger vendors (DevExpress) do not even have any Delphi x64 news.
That means, give or take a year to make Delphi x64 stable, it could drag on to 2012 or 2013 more to get a stable compiler... by that time, most of the Delphi developers would have been out-foxed, beaten by their 64-bit competitors, without house, without any way to make more money... making 32-bit EXEs is no longer a marketable asset.
The people who still use Delphi will have to make hard choices when the 64-bit preview comes out...
The less information Embarcadero gives on the compiler development status (other than just being very silent) the more people will start to wonder WTF is happening?
:)
Article notes:
- For non-English speakers: "Tea Leaves" means predicting the future based on known available information.
- Spelling mistakes corrected.
- Pointer information corrected.
8 comments:
Dcc32, editor, debugger are written in C/C ++ they (Embarcadero) do not have 64-bit C/C++ compiler .... So Delphi IDE will be 99.99% 32-bit for sure...
We should not forget the Client Data Set / MIDAS a key component also written in C/C++ :-)
They should have first to do C/C++ 64-bit, nah ... Or eat others dog food?
I think the XE2 will be half baked product (regarding 64-bit) and excelent 32-bit product with shiny UCL...That simply isn't enough...
It seams some of your "predictions" already've been invalidated/addressed by Allen (@kylix_rd on Twitter: http://twitter.com/#!/kylix_rd/status/42815058610368512)
As for the debugger & co limitations ... they (Nick ?) mentioned a migration toward ELF to avoid DCU issues.
As a side note .. just wondering, if Delphi is "dying so badly" .. what will you blog about next ?
The whole topic was striked-out. I re-wrote the whole article again.
Really... I rewrote the whole article. This time, it is more accurate.
David I is going to Australia at the end of the month.
He will speak about:
# Delphi for 64-bit Windows
# Delphi Native Code for cross platform development
and other things.
He won't be talking about vaporware.
Article updated with several corrections.
It looks to me you're mixing remote debug symbol and TD (TurboDebugger)32 debug info.
The idea they could release a commercial compiler without a debugger is really silly. Even AQTime is a 32 bit app that can track 64 bit code. If they were forced to improve the remote debugger the better.
BTW: "reading tea leaves" means try predicting the future using useless informations (the patterns made by the tea leaves in the cup after you drink your tea). More or less what you and "Bunny" did (and, again BTW, Apple uses Objective-C, not C).
NEON registers?? You'd need an ARM to use them... did you fail to notice Delphi runs on AMD/Intel architecture still? Or would you prefer an ARM emulator inside the Delphi RTL? (LOL!). But it looks you like Frankenstein products, as your compiler suggestion tell - but AFAIK Dinkumware writes libraries, not code generators. Or you have not clear what a front-end is and what a back-end is. Also Edison has not Pascal front-end, so what?
Sure they have to rewrite part of the RTL, what's the problem? Do you believe they can't rewrite an IntToStr() function?
Drink less tea and more chamomile, it will help you ;)
> NEON registers?? You'd need an ARM to use them...
Do you develop on an iPad? You know, that nice tablet most Delphi developers don't know anything about.
It's a nice little development platform that brings lots of carrots (excuse the pun) or lots of money.
Post a Comment