Coffeehouse Thread

9 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Idea for video: 64bit explained

Back to Forum: Coffeehouse
  • User profile image
    ZippyV

    Now that we have 64-bit processing available, where is Windows XP 64 or Windows Server 2067? Why does it take so long for Microsoft to bring out an operating system that is 64 bit enabled?
    What does it mean from a programming point of view: does everything has to be rewritten? (I don't think so) But why does it take that long?
    What are the advantages of running programs on 64-bit?

  • User profile image
    SharpDog

    There are 4 levels of 'compatibility' in this case:

    1. Compatibility mode: The software is still 32 bit software but the hardware runs it anyway. This is the present situation with 32-bit windows on 64-bit processors.

    2. Recompilation: Vendors recompile their source code with 64-bit compiler targets and no other changes. This gets you the raw speed increases (64-bit data paths, larger registers, etc.) but no additional capability.

    3. The low hanging fruit: vendors rewrite small portions of critical systems such as memory and heap managers, garbage collectors, file systems, compiler internals, image processing applications to take advantage of the larger address space and increased floating point capability but do not re-architect their applications. This is where you can realistically hope to be in 6-12 months. It takes a lot of effort and money to test changes in these critical systems but changes in these (relatively) few systems have great leverage.

    4. Global rewrite: Most (if not all) software is re-architected for the new processors. This will not happen for (at least) several years when all of the major applications undergo a major version revision.  For many applications, it may never occur at all  until they are replaced by their competition.

  • User profile image
    eagle

    Speed, you can add up to 16gigs of RAM so you can "live" in memory.

    WindowsXP 64 Edition is OVERDUE, people I trust at Microsoft have told me it was because everybody was working on XP SP2, well thats out the door so... 

  • User profile image
    Manip

    eagle wrote:
    Speed, you can add up to 16gigs of RAM so you can "live" in memory.

    WindowsXP 64 Edition is OVERDUE, people I trust at Microsoft have told me it was because everybody was working on XP SP2, well thats out the door so... 


    I'm surprised they haven't just scrapped the concept and moved on to a 64bit longhorn. Or even ONLY a 64bit release of longhorn.. by then most computers fast enough to run longhorn will be cross 32/64bit anyway.

  • User profile image
    eagle

    I think they will...but we can't talk about that...

    ALL THE oem COMPUTERS in two years will be 64bit and most people will get Longhorn with a new computer.

  • User profile image
    Mike Dimmick

    Microsoft did most of the work for porting the OS to 64-bit platforms in general back in the Windows 2000 timeframe. I heard somewhere that a lot of it was done on 64-bit Alpha processors. That's for the code that isn't processor- or platform-specific, which is actually the great majority of the OS. Producing the binaries requires a correct C++ compiler back-end. Windows XP 64-bit editions for Itanium-family processors have been around since late 2002, IIRC.

    However, when you port an OS to a new processor architecture, you need to port many pieces of code which touch low-level platform details. In the case of x64, the page table structure is the same as x86's Physical Address Extensions mode, but I believe that's about it. Making sure WOW64 (Win32-on-Win64, running x86 Win32 binaries on a 64-bit OS) works properly is a large part of it too.

    Microsoft also took this opportunity to change some of the conventions between x64 and x86. Yes, they could have used the old x86 calling conventions and exception implementation (widening some fields to 64-bit), but it was widely recognised that these are actually really inefficient on modern processors. Windows on x64 follows the RISC style of passing arguments in registers and using exception handler tables rather than using the stack (bringing it into line with the MIPS, Alpha, PowerPC and Itanium specifications). This essentially requires a whole new C++ compiler back-end to be built before the portable code can be rebuilt.

    Windows on x64 has taken a lot longer than Linux on x64, but if you'll forgive me for saying it, Microsoft actually has an interest in QA, ensuring it'll work and be supportable.

  • User profile image
    Mike Dimmick

    Jeez, you expect an answer in 12 minutes?

    Ahem. Details of AMD64 calling conventions at http://blogs.msdn.com/oldnewthing/archive/2004/01/14/58579.aspx.

    MS support: yes, you get a relatively non-knowledgable person to start with. This person collects the basics of your problem, asks the common-sense questions and IIRC does a simple trawl of KB articles to see if there's a solution. If your call passes this initial screen, it gets raised up to more technical staff. I think this initial screen may be outsourced if you're not quoting a support contract number.

    Depending on the product involved there may be three or four levels of escalation involving more technically skilled people at each level before you get anywhere near the development team.

    (Disclaimer: a family member works in Exchange PSS in the UK as a Critical Problem Resolution engineer, which I think is three levels removed from the person who initially answers the phones. Don't ask me to pass on messages, I won't.)

  • User profile image
    jonathanh

    Beer28 wrote:
    I searched the new msdn for asm 64 and nothing really came up on the subject.


    "Your search fu is weak, young one".

    I found this with my first search on msdn.microsoft.com: "Calling Convention for AMD 64-Bit Environments"

  • User profile image
    Mike Dimmick

    Beer28 wrote:
    but it still doesn't answer my question.
    What about struct type values that are larger than 64 bits passed by value?

    Say the first param to a function is struct { int foo[50]; }; and it's passed by value?

    Is that value now going to be passed by address, unbeknownst(sp?) to the coder? On 32 bit, it's all on the stack, so it can be popped off no matter how big it is as long as you don't overflow the stack address range.


    Copied on the stack, a pointer is passed to the routine using whatever convention is in place. IIRC, the 32-bit compilers often do this. You can check what the Microsoft compiler actually generated by turning on the /FA command line option. I usually use /FAs (generate assembly interspersed with source). In VC6, go to Project Settings, C/C++ tab, select Listing Files from the Category drop-down, and select Assembly with Source Code from Listing file type.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.