Nick Hodges

Random Thoughts on the Passing Scene #94

08 Dec

23 Responses to “Random Thoughts on the Passing Scene #94”

  1. 1
    ahmoy law Says:

    "Cross Platform Delphi is Back" but it just a net/mono application!!!

  2. 2
    Kryvich Says:

    Hello, Nick!
    How about Delphi Win32 Command Line Edition?

  3. 3
    Jan Derk Says:

    The top of Whitepaper webpage says "by Tim DelChiaro". Should that not be "by Marco Cantù"? who wrote the white paper?

  4. 4
    Confused Says:

    Cross Platform: it works on a Microsoft platform and also in a Microsoft platform.

  5. 5
    John Frew Says:

    http://www.mono-project.com/Supported_Platforms

  6. 6
    Dave Says:

    "Cross Platform Delphi" -
    A 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.

  7. 7
    joe Says:

    yeah, how about Delphi Win32 Command Line Edition?

  8. 8
    Luigi D. Sandon Says:

    For 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?

  9. 9
    JDoll Says:

    Now that Delphi is up to 2009, please reconsider the death of the Turbos and bring Turbo Delphi up to 2007.

  10. 10
    Hans-Peter Says:

    > 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

  11. 11
    David Heffernan Says:

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

  12. 12
    Luigi D. Sandon Says:

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

  13. 13
    David Heffernan Says:

    64 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!

  14. 14
    Luigi D. Sandon Says:

    No: the language guide says also it is the native CPU register size and therefore the most performant. Read carefully…

  15. 15
    David Heffernan Says:

    Luigi:

    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.

  16. 16
    Craig Peterson Says:

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

  17. 17
    David Heffernan Says:

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

  18. 18
    Luigi D. Sandon Says:

    Heffeman: "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.

  19. 19
    David Heffernan Says:

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

  20. 20
    Craig Peterson Says:

    David: 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.

  21. 21
    Luigi D. Sandon Says:

    "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."
    Look 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.

  22. 22
    Zenon Says:

    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…
    Does CodeGear have any plans to update Delphi and C++ Builder road map in the near future?

  23. 23
    chanel handbag supplier Says:

    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.

© 2014 Nick Hodges | Entries (RSS) and Comments (RSS)

Your Index Web Directorywordpress logo
Close