Officially, BCB6 is not supported on AMD 64-bit systems. That having been said, it seems that some customers have been using the two together successfully.
Early on, some customers did encounter freezing issues on their Opteron and Athlon 64 machines. The few instances that I'm personally aware of were fixed by applying the errata 109 BIOS update.
-- YH --
-- Please confine your posts to the newsgroups and DO NOT reply to this e-mail account unless asked. Any unsolicted e-mail will be ignored.
Note, you still won't be able to build 64 bit apps. If you're interested in developing 64 bits, I shudder to say, Microsoft is your only choice, despite the fact that they haven't released a Platform SDK that supports 64 bit development yet. If you're interested in this, I posted a writeup on how to develop 64 bit apps with Visual Studio.NET at the following link:
> Note, you still won't be able to build 64 bit apps. If you're interested in > developing 64 bits, I shudder to say, Microsoft is your only choice, despite > the fact that they haven't released a Platform SDK that supports 64 bit > development yet. If you're interested in this, I posted a writeup on how to > develop 64 bit apps with Visual Studio.NET at the following link:
> Note, you still won't be able to build 64 bit apps. If you're interested in > developing 64 bits, I shudder to say, Microsoft is your only choice,
Intel C++ V8.1 is capable of compiling 64 bit applications. Since Intel and AMD x86-64 processors are compatible it should work - although I haven't tried.
I stand corrected once again, though I'd be a little nervous about running anything built with Intel C++ on and AMD system unless I'd examined the assembly output to verify nothing funky was going on.
"Mogens Hansen" <mogen...@dk-online.dk> wrote in message
<snip> > Intel C++ V8.1 is capable of compiling 64 bit applications. > Since Intel and AMD x86-64 processors are compatible it should work - > although I haven't tried.
"Sean Hoffman" <seandontspammehoff@austintxDOTcom> writes: > I stand corrected once again, though I'd be a little nervous about > running anything built with Intel C++ on and AMD system unless I'd > examined the assembly output to verify nothing funky was going on.
From what I understand, Intel has one of the best--if not THE best--optimizers available. Even without processor-specific codegen optimizations (obviously not available for AMD), the non-platform-specific optimizations are still have supposedly very good results, even for AMD platforms.
As for 64-bits, though, I'm not sure if their compiler will target an Opteron. Anyone know any deatils here?
It wasn't their optimizations I was worried about, as I too have heard wonderful things about their compiler.. But worried me was the potential de-optimizations. I'm not saying there are any, and I'm not saying there aren't. I'm just saying I'd want to know for sure before I built a product on it. Intel doesn't exactly have a history of making things easy on their competition, especially when that competition is managing to beat them in some way...
> From what I understand, Intel has one of the best--if not THE > best--optimizers available. Even without processor-specific codegen > optimizations (obviously not available for AMD), the > non-platform-specific optimizations are still have supposedly very > good results, even for AMD platforms.
> As for 64-bits, though, I'm not sure if their compiler will target an > Opteron. Anyone know any deatils here?
"Sean Hoffman" <seandontspammehoff@austintxDOTcom> writes: > It wasn't their optimizations I was worried about, as I too have heard > wonderful things about their compiler.. But worried me was the potential > de-optimizations. I'm not saying there are any, and I'm not saying there > aren't. I'm just saying I'd want to know for sure before I built a product > on it. Intel doesn't exactly have a history of making things easy on their > competition, especially when that competition is managing to beat them in > some way...
My workstation is an Athlon and I use Intel as my main C++ compiler. It beats all other compilers I tried (MSVC++, g++, Metrowerks)
OTOH, I'm not aware of Intel support for AMD64. What I get is a compiler for x86, other for Itanium and other for "Extended Memory 64", which I think is not the same as AMD64.
Actually, I think the "extended memory 64" is EMT64, which is Intel's marketing name for AMD64. There were a couple of minor differences relating to the fact that Intel did their reverse engineering based on an earlier opcode doc, but the implementations are very close..
"Oscar Fuentes" <o...@wanadoo.es> wrote in message
> My workstation is an Athlon and I use Intel as my main C++ > compiler. It beats all other compilers I tried (MSVC++, g++, > Metrowerks)
> OTOH, I'm not aware of Intel support for AMD64. What I get is a > compiler for x86, other for Itanium and other for "Extended Memory > 64", which I think is not the same as AMD64.
Sean Hoffman wrote: > I stand corrected once again, though I'd be a little nervous about running > anything built with Intel C++ on and AMD system unless I'd examined the > assembly output to verify nothing funky was going on.
I've been using the Intel C++ compilers for years through many versions on both Intel and AMD CPU's and both on MS-Windows and Linux, without noticing any problems.
I don't know anything about gcc 64bit for Opteron on Windows 64, but I had a lot of experience with gcc for Opteron on 64bit Linux. There are basically two problems that make it less than optimal choice. First, there are occasions when gcc simply hangs when compiling certain code; sometimes it's random hanging, as I see our build machines hanging from time to time. The other problem is with code optimization. VC produces so much better code (we use a lot of tight template stuff), so that gcc executable on 2GHz opteron runs approximately with the same speed as VC7.1 executable on my Pentium M 1.7GHz. So unless you absolutely need a lot of memory, gcc/Opteron64 is not a very attractive solution.
J
"Sebastian Ledesma" <labo_no_sp@m_solidyne1.com> wrote in message
> As I know the GCC also supports AMD64 for Win64 and Linux, but never > tested > (I expect to buy my > AMD64 by december/january 05).
> Saludos > Sebastian
> "Sean Hoffman" <seandontspammehoff@austintxDOTcom> escribió en el mensaje > news:4163c223@newsgroups.borland.com... >> Note, you still won't be able to build 64 bit apps. If you're interested > in >> developing 64 bits, I shudder to say, Microsoft is your only choice, > despite >> the fact that they haven't released a Platform SDK that supports 64 bit >> development yet. If you're interested in this, I posted a writeup on how > to >> develop 64 bit apps with Visual Studio.NET at the following link:
<seandontspammehoff@austintxDOTcom> wrote: >Note, you still won't be able to build 64 bit apps. If you're interested in >developing 64 bits, I shudder to say, Microsoft is your only choice, despite >the fact that they haven't released a Platform SDK that supports 64 bit >development yet.
BTW, for those without MSDN access to the DDK, MS will ship you the DDK containing their AMD64 compiler on DVD for a S&H fee.
MS does seem to be dragging their feet on 64-bit development tools. The Platform SDK (at least the public one) has been extremely slow to update. The XP SP2 PSDK wasn't made available until after SP2! The AMD64 Win64 OS itself is in public beta, but not the development tools. It's as if MS doesn't want developers working on SP2 compatible or 64-bit applications. It doesn't make much sense.
Visual Studio has also been slow to add full support for 64-bit platform build configurations, despite the fact that the IA64 verison of Windows has been shipping since XP originally shipped.
> MS does seem to be dragging their feet on 64-bit development tools. > The Platform SDK (at least the public one) has been extremely slow to > update. The XP SP2 PSDK wasn't made available until after SP2! The > AMD64 Win64 OS itself is in public beta, but not the development > tools. It's as if MS doesn't want developers working on SP2 > compatible or 64-bit applications. It doesn't make much sense.
> Visual Studio has also been slow to add full support for 64-bit > platform build configurations, despite the fact that the IA64 verison > of Windows has been shipping since XP originally shipped.
<snip>
COMPLETELY agree. I spent about 5 hours last week just trying to find the SP2 Platform SDK download so I could interface with their firewall API. Don't believe me? Try looking for the firewall API header (netfw.h), or even the .idl file. It's like you said; it's almost as if Microsoft doesn't want people developing for the new platforms..
"Sean Hoffman" wrote: > It's like you said; it's almost as if Microsoft doesn't want people > developing for the new platforms..
Not almost. They just don't want you to develop using the platform SDK. They want you to use the .NET framework. Unfortunately Borland hasn't finished the integration of C++ into BDS yet ;-)
> Applying the update for it has helped other BCB6 customers avoid the > freezing issue in the past.
I just hit exactly this with a brand-new Shuttle SN85G4 system I've built. Upgrading the Shuttle BIOS to the latest rev fixed the hang. All other suggestions I tried (RAM voltage, drivers) had no effect.
>>MS does seem to be dragging their feet on 64-bit development tools. >>The Platform SDK (at least the public one) has been extremely slow to >>update. The XP SP2 PSDK wasn't made available until after SP2! The >>AMD64 Win64 OS itself is in public beta, but not the development >>tools. It's as if MS doesn't want developers working on SP2 >>compatible or 64-bit applications. It doesn't make much sense.
>>Visual Studio has also been slow to add full support for 64-bit >>platform build configurations, despite the fact that the IA64 verison >>of Windows has been shipping since XP originally shipped.
><snip>
>COMPLETELY agree. I spent about 5 hours last week just trying to find the >SP2 Platform SDK download so I could interface with their firewall API. >Don't believe me? Try looking for the firewall API header (netfw.h), or >even the .idl file. It's like you said; it's almost as if Microsoft doesn't >want people developing for the new platforms..
Security by OBSCURITY.....just another part of Microsoft 3E's policy.....embrace, extend, extinguish.....next up..FireWalls.
"Marcelo R. Lopez, Jr." <mlo...@voicerite.com> writes:
> Security by OBSCURITY.....just another part of Microsoft 3E's > policy.....embrace, extend, extinguish.....
You forgot: communication,timely releases and enhancements.
Microsoft have done a far better job than Borland in communicating with customers, timely releases of development tools and worthwhile enhancements of those tools.
I R T wrote: >"Marcelo R. Lopez, Jr." <mlo...@voicerite.com> writes:
>>Security by OBSCURITY.....just another part of Microsoft 3E's >>policy.....embrace, extend, extinguish.....
>You forgot: >communication,timely releases and enhancements.
>Microsoft have done a far better job than Borland in communicating with >customers, timely releases of development tools and worthwhile enhancements >of those tools.
Like I've said before....even a nut-job like Steve Ballmer can be right every so often.
|
