Random Thoughts on the Passing Scene #94
08 Dec
- The Delphi Prism Command Line Edition download is now live at http://cc.codegear.com/Free.aspx?id=26256. It’s free as in beer.
- And be sure to get your RAD Studio 2009 Trial if you haven’t already had a look.
- Cross Platform Delphi is Back.
- Don’t miss our new white paper called "Using New Delphi Coding Styles and Architectures: A Review of the Language Features in Delphi 2009".
"Cross Platform Delphi is Back" but it just a net/mono application!!!
December 8th, 2008 at 11:06 pmHello, Nick!
December 9th, 2008 at 12:17 amHow about Delphi Win32 Command Line Edition?
The top of Whitepaper webpage says "by Tim DelChiaro". Should that not be "by Marco Cantù"? who wrote the white paper?
December 9th, 2008 at 1:22 amCross Platform: it works on a Microsoft platform and also in a Microsoft platform.
December 9th, 2008 at 4:49 amhttp://www.mono-project.com/Supported_Platforms
December 9th, 2008 at 6:22 am"Cross Platform Delphi" -
December 9th, 2008 at 1:13 pmA marketing solution to a technical problem :-). But like all marketing solutions when you look under the covers, there is a giant can of worms. Please tell me this is a joke.
yeah, how about Delphi Win32 Command Line Edition?
December 9th, 2008 at 1:53 pmFor the matter, any Delphi Win32 application running in a VM is "cross platform"…
Stop this "multi-platform" nonsense about Mono, please, it is just a lame attempt to tell people .NET is like Java, WINE works better, if needed.
And please, rethink the size of Integer and Cardinal in 64 bit Delphi. You’re going to create a lot of issues IMHO. And it would be nice to clarify *now* what will happen - i.e. what about TComponent.Tag? Will it be "Integer" still and 32 bit? Will become a NativeInt (breaking a lot of casts)? What about many "Integer" properties? Which one will become NativeInt and which one will stay Integer?
December 9th, 2008 at 2:52 pmNow that Delphi is up to 2009, please reconsider the death of the Turbos and bring Turbo Delphi up to 2007.
December 9th, 2008 at 9:45 pm> Cross Platform Delphi is Back.
marketing speech. you do quite well lately and imho don’t need such lame statements.
I’d prefer you’d say that Prism supports mono (well) and thus will run on several platforms. For me you can reserve the cross platform moniker for native Delphi.
Hans-Peter
December 10th, 2008 at 1:27 amSince no announcements have been made about 64 bit native Delphi I don’t believe that the decision to keep Integer/Cardinal at 32 bit is officially known. However, it’s the only sensible choice.
Those of you complaining about it need to take a read of the 64 bit programming guide in MSDN. Since native Delphi will run on Windows it will use Win32 which is the 64 bit native Windows interface. Consequently it makes a huge amount of sense for Delphi to have the same strategy for dealing with integer/pointer variable sizes as the underlying platform.
Casting pointers and objects to Integer/Cardinal was always dangerous. The addition of some special integer types which are the same size as pointers would be great. So TComponent.Tag would change from Integer to the new pointer sized integer type and so on.
The compiler can tell you when you are truncating a 64 pointer to a 32 bit integer so it will be easy to fix all the problems.
December 10th, 2008 at 3:06 amCasting pointers to Integer/Cardinal was the only way to accomplish some tasks. Anyway, feel free to (re)read the *language guide* and what *it tells* about fundamentals and generic types in Object Pascal - there is no need to change the rules now and introduce new types - just use LongInt/LongWord tyepes whenever you need fixed size 32 bit integers. And if properties change types *a lot* of code changes will be needed - something that IMHO should be avoided at all cost when not necessary - Codegear should change proeprties that should stay 32 bit long to LongInt/Longword types and let those who can become 64 bit long stay Integer/Cardinal. That’s the only sensible choice, IMHO, and won’t break OP own rules.
December 10th, 2008 at 6:03 am64 bit integers consume more memory, more cache and are slower. The Integer/Cardinal thing was introduced many many years ago before AMD64 was invented and before memory access became such a performance bottleneck. It’s easy therefore to see how the decision looks different now.
Anyway, my recollection of the language guide is that it says that the size of Integer/Cardinal is platform dependent. It doesn’t say that they map to values with the pointer word size. In other words there are no rules, only that you can’t rely on the physical size of Integer/Cardinal.
Luigi, please feel free to (re)read the language guide!
December 10th, 2008 at 6:30 amNo: the language guide says also it is the native CPU register size and therefore the most performant. Read carefully…
December 10th, 2008 at 7:13 amLuigi:
Perhaps you’ve got a more recent version than me. Mine says "The generic integer types are Integer and Cardinal; use these whenever possible, since they result in the best performance for the underlying CPU and operating system."
Nothing about native register size. In any case on x64 I think you will find that 32 bit integers give the best performance because they consume half as space as 64 bit and memory access / cache size is usually the determining factor these days. Most performance critical apps are memory bound rather than CPU bound.
December 10th, 2008 at 8:11 amCross platform Delphi is *not* back. Cross-platform Object Pascal is "back" if you ignore the fact that Free Pascal has had it for ages. Those of us clamoring for cross-platform Delphi want a cross-platform VCL and native development so we have the same advantages we have on Windows. Prism doesn’t help with that at all, so please stop patting yourselves on the back for it.
December 10th, 2008 at 8:22 amNative cross-platform Delphi? We had that with Kylix but it turned out that the market for commercial desktop apps on Linux doesn’t exist. Even though Kylix/CLX was a tremendous engineering success the lack of a market killed the product.
Targeting native OSX might be more tenable because there are actually a reasonable number of people out there with both (1) OSX and (2) the inclination to buy software. That said I imagine that the Kylix experience has led to CodeGear being wary about making the same mistake again.
December 10th, 2008 at 8:59 amHeffeman: "I think you will find that 32 bit integers give the best performance because they consume half as space as 64 bit and memory access / cache size is usually the determining factor these days". You think. The CPU may think differently. CPU needs aligned data to speed up memory access and PUSH/POP operation usually works on the CPU native size - you won’t gain anything keeping on using 32 bit data in a 64 bit world.
Craig: a "cross platform VCL" is an oxymoron. VCL is a great library because it is a native windows library. Make it "cross-platform" and it would become a so-so library as most cross-platform library out there. I’d prefer a "native" VCL for each supported platform, or I don’t care about a cross-platform Delphi at all - I’ll stick using each platform native tools.
December 10th, 2008 at 10:05 amLuigi. There are multitudinous articles accessible from simple web searches that talk about the trade offs between 32 and 64 bit integer size on x64. Remember that one of the key goals when AMD developed x64 was that 32 bit code would not suffer performance penalties when run on an x64 chip.
For a simple example take a look at: http://arstechnica.com/articles/paedia/cpu/x86-64.ars/4
Extract from this is: "Integer instructions, on the other hand, are a different matter. You don’t always need to use 64-bit integers, and there’s no need to take up cache space and memory bandwidth with 64-bit integers if your application needs only smaller 32- or 16-bit ones. So it’s not in the programmer’s best interest to have the default integer size be 64 bits. Hence the default data size for integer instructions is 32 bits, and if you want to use a larger or smaller integer then you must add an optional prefix to the instruction that overrides the default. This prefix, which AMD calls the REX prefix (presumably for "register extension"), is one byte in length. This means that 64-bit instructions are one byte longer, a fact that makes for slightly increased code sizes."
It’s also well worth reading what you can find on MSDN. The programming guide for 64 bits is at: http://msdn.microsoft.com/en-us/library/bb427430(VS.85).aspx and the data types article is at: http://msdn.microsoft.com/en-us/library/aa384264(VS.85).aspx.
The key thing to note is that the native integer on WIN32 running on 64 bit Windows (x64 and IA64) is 32 bits wide. So if you really do "prefer a native VCL for each supported platform" then you ought to be in favour of 32 bit integer.
My other suggestion is that you get Visual Studio and write some 64 bit apps to get some real experience. I have found that extremely valuable.
Nick, sorry to take over this thread. I think I’ll shut up now ‘cos there’s nothing more to say! But you could take the message that 64 bit is very important to me at least and I hope that the delays you Twittered about aren’t too long. Looking forward to the updated roadmaps.
December 10th, 2008 at 11:00 amDavid: There are lots of reasons why Kylix didn’t sell, but there not being any market for commercial software is not one of them. It might not have been big enough to support Kylix, but Beyond Compare’s Linux port is doing just fine.
Luigi: I’m not asking that they muck with the VCL, but that they provide an alternate implementation that roughly maps to the same API so we don’t have to rewrite our entire application. We’re use the VCL on Windows and CLX on Linux with a single code-base and it’s much easier than you’d think, especially with some patches to CLX to reduce unnecessary incompatibilities. I’d like the same thing on OS X. If they had kept the Kylix compiler up to date and managed FreeCLX properly I’d be happy as a clam. I don’t know who this Prism-based cross-platform vision is for, but given it isn’t an upgrade path for either VCL/Win32 or VCL.NET, it’s certainly not their existing customers.
December 10th, 2008 at 12:06 pm"Remember that one of the key goals when AMD developed x64 was that 32 bit code would not suffer performance penalties when run on an x64 chip."
December 10th, 2008 at 12:45 pmLook at how many piece of code already use extended instructions to manipulate more than 32 bit at once. Anytime code manipulates data structure larger than 32 bit it will move them with the larger chunk allowed, and 64 bits arithmetic can be very handy to get rid of BCD arithmetics in many cases - please spare me the size/bandwith issues that looks to much the same already listened to when going 32 bit fourteen years ago. Frankly who cares about one byte extension?
Also note that at http://msdn.microsoft.com/en-us/library/aa384264 MS is introducing types that "floats" with the pointer size (INT_PRT and LONG_PTR) like Cardinal and Integer *already did*. And those types are the ones to be used to cast pointers - and we always used Cardinal for such tasks because it should have been safe even under a new architecture - now it is not - while MS does what CodeGear already did, Codegear could go the other way round and introduce new types just to make porting more complex. Wuat are Longword and Longint for, then? It looks MS had taken away all the great minds already.
What about data like WParam, LParam and the like? They become 64 bits long even if AMD likes prefixes - what would happen to casts?
"My other suggestion is that you get Visual Studio and write some 64 bit". Sorry, alredy doing it with GCC for a while… and even on non-x86 architectures. That’s why I think it’s far better Cardinal and Integer go 64 bits.
But feel free to think small, like Codegear has been doing in the past five-six year.
Delphi used to have superior IDE but these days even that is not true anymore.
These days CodeGear is seems to be advertising the ugly VS IDE trying to convice
us that it is actually smart move (save money in the short term) to rely on
CodeGear’s own most important competitor as the provider of such a fundamental
thing like an IDE.
I do not really understand that strategy?
What is the advantage of using Delphi Prism instead of VS C# for .Net development?
I would really like to know the advantages of that approach both in the short term
also as a long term solution.
And one more question…
December 13th, 2008 at 4:29 pmDoes CodeGear have any plans to update Delphi and C++ Builder road map in the near future?
Coding an interface to hide the form border??? I assume you do know that it should not be there in the first place, so why not hide it (and add the interface) in the VCL?
Sorry Nick: My third thought was about the Vista glass feature. I forgot to add the word glass. I did not mean to say that D2007 is useless because it is not. What I meant is:
The glass feature in D2007 is useless because of all the painting issues. Anyone who has dropped some components on the glass area can confirm that. Hopefully you guys fixed them.
"Tiburon is /not/ all about Unicode"
Well it is my #1 feature request with generics being a very distant second. So I don’t mind if is not all about Unicode as long as Unicode is part of the package.
January 3rd, 2009 at 9:08 am