Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visual Studio 2013

blogs.msdn.com

Post reply on HN
Print view View original

131–140 of 201 posts

Re: Visual Studio 2013

#131

Post by ryanmolden »

yuhong wrote: post #127
ryanmolden wrote: post #117

Earlier quoted context omitted.

I am a bit confused. That thread seems to claim that Microsoft isn't producing a 64 bit linker, my install seems to disagree with them (vc\bin\amd64). Then you claim that the linker won't produce 32 bit code, but /machine:x86 seems to disagree with that. I tested this by building as 32 bit, then just repeating the link using the 64 bit linker and /machine:x86, worked fine. So what are their problems exactly? That the…

The problem is cl.exe for x86 is only 32-bit, and the design of most build systems don't make it easy, especially as Mozilla was using PGO.

You mean it only produces 32 bit code? This disagrees (http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as...) going back to at least 2005.

The following list describes the various versions of cl.exe (the Visual C++ compiler):

...

x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit Widows operating system.

Re: Visual Studio 2013

#132

Post by Dylan16807 »

jlarocco wrote: post #108
stephencanon wrote: post #102

Earlier quoted context omitted.

I prefer to think of it as "Microsoft tooling is dead", since C continues to work just fine.

Either way, C99 in Visual C++ isn't happening, so why beat a dead horse?

Because they're so close to having C99 support.

Re: Visual Studio 2013

#133

Post by marshray »

cpeterso wrote: post #82
sriramk wrote: post #31

Earlier quoted context omitted.

ex-VS person here (from 5 years ago though). It is never an either-or. It is always a complex mix of what customers ask for, what the strategic priorities/market realities are. Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. On promotions - I think it's the reverse problem. People…

Mozilla has been fighting the MSVC linker's 3GB virtual address space limit for years. Mozilla has asked Microsoft for a 64-bit linker that can produce 32-bit code, but Microsoft apparently has no plans for such a configuration. https://groups.google.com/forum/?fromgroups#!topic/mozilla.d...

Disclosure: I'm a new guy at Microsoft, not in the VS team, just speaking from prior experience as a Win32 developer.

There are still internal limits in the PE32 format which mean parts of the output as a whole will be limited to 2 GiB or so, regardless of the address space available to the linker.

I too have hit internal linker limits from time-to-time, but the span of computing history in which it makes sense to have a 64-bit linker building a load module output with 32-bit internal limits to run on 64-bit processors doesn't seem like the place to be in the great scheme of things. Just my personal observation.

Re: Visual Studio 2013

#134

Post by jlgreco »

ryanmolden wrote: post #131
yuhong wrote: post #127

Earlier quoted context omitted.

The problem is cl.exe for x86 is only 32-bit, and the design of most build systems don't make it easy, especially as Mozilla was using PGO.

You mean it only produces 32 bit code? This disagrees ( http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as... ) going back to at least 2005. The following list describes the various versions of cl.exe (the Visual C++ compiler): ... x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit W…

What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows.

This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output.

      OS  Linker  Output  Mem
  1   32  32      32      3GB
  2   32  32      64      3GB
  3   64  32      32      4GB
  4   64  64      32      8TB
They use to be doing 1, now they are doing 3. They need to do 4, but apparently cannot. My understanding of this may be wrong, or they may be wrong, I don't know.

Re: Visual Studio 2013

#135

Post by yuhong »

ryanmolden wrote: post #131
yuhong wrote: post #127

Earlier quoted context omitted.

The problem is cl.exe for x86 is only 32-bit, and the design of most build systems don't make it easy, especially as Mozilla was using PGO.

You mean it only produces 32 bit code? This disagrees ( http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as... ) going back to at least 2005. The following list describes the various versions of cl.exe (the Visual C++ compiler): ... x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit W…

I am talking about the cl.exe executable that output x86-32 code itself, not the code it produces. You can use a 32-bit cl.exe to cross compile 64-bit code, but not the other way round.

Re: Visual Studio 2013

#136

Post by yuhong »

jlgreco wrote: post #134
ryanmolden wrote: post #131

Earlier quoted context omitted.

You mean it only produces 32 bit code? This disagrees ( http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as... ) going back to at least 2005. The following list describes the various versions of cl.exe (the Visual C++ compiler): ... x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit W…

What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows. This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output. OS Linker Output Mem 1 32 32 32 3GB 2 32 32 64 3GB 3 64 32 32…

You need to add cl.exe to the table.

Re: Visual Studio 2013

#137

Post by jlgreco »

yuhong wrote: post #136
jlgreco wrote: post #134

Earlier quoted context omitted.

What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows. This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output. OS Linker Output Mem 1 32 32 32 3GB 2 32 32 64 3GB 3 64 32 32…

You need to add cl.exe to the table.

I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use?

I am baaarely familiar with Microsoft-world development.

Re: Visual Studio 2013

#138

Post by [deleted] »

angersock wrote: post #54

And yet, still no formalized C99 support. I know everybody is hot and bothered about C++11, but honestly I'd suggest just getting proper support for things we've needed for a decade or so before chasing the new shiny.

[deleted]

Re: Visual Studio 2013

#139

Post by yuhong »

jlgreco wrote: post #137
yuhong wrote: post #136

Earlier quoted context omitted.

You need to add cl.exe to the table.

I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use? I am baaarely familiar with Microsoft-world development.

Yes, they can use a 32-bit cl.exe and 64-bit linker, but most build systems don't make it easy.

Re: Visual Studio 2013

#140

Post by mbrubeck »

dthunt wrote: post #103
cpeterso wrote: post #82

Earlier quoted context omitted.

Mozilla has been fighting the MSVC linker's 3GB virtual address space limit for years. Mozilla has asked Microsoft for a 64-bit linker that can produce 32-bit code, but Microsoft apparently has no plans for such a configuration. https://groups.google.com/forum/?fromgroups#!topic/mozilla.d...

What I want to know is how someone can see that their software project has become unlinkable on a 32-bit OS and somehow think that this is purely a compiler problem.

It's not just Firefox; other large projects like Chromium also exceed this limit when using MSVC's profile-guided optimization (PGO) on 32-bit Windows. (Chrome's solution is to build without PGO; Firefox's is to limit PGO to only a portion of source directories.)
Post reply on HN