Opteron ought to be compared to POWER, not PowerPC, given the target markets.
Presumably referring to, as per the distinction I drew in "Both POWER (all-caps) and PowerPC refer both to instruction set architectures and brand names used on processors that implemented them.", POWER and PowerPC the brand names used on processors, not POWER and PowerPC the instruction set architectures.
Also, in the Windows world itself, you had 64-bit MIPS and Alpha based workstations that ran NT...
...which was a 32-bit OS, so it didn't provide 64-bit computing on those 64-bit processors.
Seeing as the PowerPC 970 ("G5") was the first 64-bit PowerPC (not POWER, though) processor, even the Opteron came out before the first 64-bit PowerPC.
As I said in an earlier post in this thread, "Both POWER (all-caps) and PowerPC refer both to instruction set architectures and brand names used on processors that implemented them."
If "the first 64-bit PowerPC" refers to PowerPC-the-brand, yes, the first one (other than the 620, which wasn't made in large quantities) was the 970.
If it refers to PowerPC-the-instruction-set, the first one was the POWER3 - it implemented the full PowerPC instruction set (as well as the POWER2 version of the POWER instruction set).
I suppose it depends on how you look at it. If you view the page directory as a bank select then it is a sort of segmentation.
If you view the page directory as a bank select then any form of paging with more than two levels of page table is a sort of segmentation, including x86 paging without PAE (all the way back to the 80386), and the form of paging on just about every modern processor.
And how many people actually owned a SPARC, POWER, or Itanic for that matter?
Well, some of the masses might have had G5 iMacs (PowerPC 970, 64-bit), but, yes, it took AMD to bring 64-bit to most of the masses.
At least one comment claims that the original title of the article was "64-bit Computing Reaches 10th Anniversary", which, if true, means the article came out with a bogus headline (there's more to "Computing" than stuff that runs on a mainstream desktop or laptop machine, and DEC OSF/1 came out in 1993, so it's been at least 20 years); if the original comment was posted before that, I can see his complaint (and the complaint of the person who pointed out that the MIPS R4000 came out before the first 64-bit PowerPC processor). Complaining about "64-bit x86 Computing Reaches 10th Anniversary" neglecting other 64-bit architectures, however, is silly.
PAE isn't segmentation at all. It's a mode that changes the page table entry format to support more physical memory. Maybe you're thinking of something else as being "PAE", but Intel's (and AMD's and...) idea of PAE is a Physical Address Extension.
64-bit binaries are larger and might run 103% at the speed of 32-bit if you're lucky.
Maybe there is a lot of software written in C that uses int or unsigned when it should have typedef'd a size appropriate for its needs.
Software that's written in C, in all of the environments I know of for x86, has 32-bit ints (signed or unsigned) whether compiled 32-bit or 64-bit, so you're presumably not saying that those programs suddenly get 64-bit ints when compiled 64-bit. They will get 64-bit longs on UN*X (but not on Windows), and will get 64-bit pointers in either case.
but PAE is nothing but a spec on top of the other mess of bullshit known as segmentation.
Actually, no, it's a mode that changes the page table format to allow larger physical addresses in page table entries. Nothing to do with segmentation.
The fact that they are, maybe? ints become twice as big,
If you're talking about C-language ints, on very few 64-bit platforms are they 64-bit. Most UN*Xes are LP64, not ILP64, and Windows is LLP64 (they didn't even make long 64-bit, unlike most UN*Xes).
Both POWER (all-caps) and PowerPC refer both to instruction set architectures and brand names used on processors that implemented them.
The PowerPC ISA took the POWER ISA, added some stuff such as general-register-based multiply and divide instructions, and removed a few instructions (and didn't add in the ones used in the POWER2 processor).
POWER3 was a 64-bit processor that implemented the union of 64-bit PowerPC and POWER; I don't know whether any subsequent POWERn processors implemented the POWER ISA-only instructions or just the current version of the PowerPC/Power (not all-caps) ISA.
A 32-bit x86 app has access to 8 32-bit "general purpose" registers - they ain't really all general purpose because three of them are the stack pointer, frame pointer, and program counter.
You appear to have confused x86 with the PDP-11; the program counter ("instruction pointer" in x86land) is not one of the GPRs.
As for the frame pointer, GCC, for example, has a -fomit-frame-pointer flag that generates code that doesn't use EBP as a frame pointer, so it's available as a GPR. That might make debugging more difficult. If you're not just overlapping the data and stack segments, references through EBP implicitly go to the stack segment, so you'd have to use a segment-override prefix if it has a pointer to a location in a segment other than the stack segment, but if you're just overlapping them, that's not an issue. If you're using the ENTER or LEAVE instructions, EBP is a stack pointer; I don't know whether any current compilers bother with them.
What is so damn evil about making money? WHat is so evil about feeding your family?
Nothing. However, if making money to feed your family means using somebody else's GPLed code and not making the source to your project available, or using somebody else's GPLed or LGPLed code, with your own modifications, and not making the source to the modifications available, you should consider finding some other way to make money to feed your family. The author of the GPLed or LGPLed code is under no obligation to make it easier for you to do so.
Sure you can use GNU but who do these people are to prevent businesses to streamline their processes with software or to tell us we can't have dreams of a better life by writting the next killer app?
You can do both. Just don't, in the process, use other people's code in ways that they don't wish it to be used.
Clang supports every backend that llvm does. What it doesn't do is automaticity find all the libraries and header files that are standard for a plat form. But you can specify any target that llvm supports.
GCC doesn't support all those targets because they need to be explicitly included in at compile time.
By "targets" do you mean "instruction set architectures" or "ISA version + OS"?
And by "support" do you mean "if you build GCC it automatically includes support for all those targets without having to configure them in" or do you mean "allows support for that target to be compiled in"? If you mean the former of those two definitions of "support", that's not generally what "support" means in this context; if you mean the latter, well, which of "X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore" aren't supported? On the host/target specific installation notes for GCC page, I don't see any explicit mention of Thumb, CellSPU, MSP430, or XCore ("SystemZ", i.e. z/Architecture or "64-bit System/3x0", is called "s390x" on that page), although the ARM options page for GCC mentions Thumb; I see references on the Web to an "mspgcc" project for the MSP430, but it's not part of the GCC release, and I see mentions of an "spu-gcc", but nothing about Xcore.
By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.
The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").
So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)
So then you admit that reputable scientists disagree with AGW and at the same time are not shills for this or that industry, etc. eh?
I'd have to study more of what they say to see whether that's the case or not. Even if they're reputable in their field and not shills for fossil fuel industries, that doesn't mean they're actually right.
And please, realclimate? A hotbed of political activism and environmental wackos.
And the reason why I should believe you when you make that assertion is? Are you reputable, or are you just an anti-AGW wacko?
And maybe because there are plenty of educated people here who don't drink the Kool Aid like you. If you'd bother to pay attention, there are plenty of scientists, who are uniformly smarter that your sorry ass, who also don't drink the Kool Aid.
Hrmph, now you're being dense just to hold your side of the debate. Buddy, if you truly believe manufacturing smartphones, plastic bottles et al do nothing more than deplete resources, you're just as much in denial as those others you like to call "conservative."
Presumably, then, if you're (also? same AC or different?) arguing that "climate change is not just CO2 emissions", what you mean by that is "climate change is emissions of various greenhouse gases, including but not limited to CO2", and are arguing that manufacturing smartphones, plastic bottles et al cause the emission of greenhouse gases other than CO2.
The remarkably strong anti-gun sentiment that dominates nearly every thread
Statistics, please? I see both strong anti-gun and strong pro-gun comments (when I bother to look at all - the SNR is pretty low on most gun discussions - so maybe I just don't look at enough threads).
how can you predict the average of 100 dice rolls, when you can't even predict what the next dice roll will give?
If you can't predict the next dice roll, how come the house always wins?
Assuming you're not just trolling, the answer is "the house always wins on average". Somebody might luck out and Win Big, but enough people don't win at all that the big wins and the small wins are more than cancelled out.
I am praying this happens. I do not enjoy the many "Would you like to download our free forum app? Press cancel to continue to the web site" popups I get on my phone. Even if this does happen though, do you really think it means that the app market will not be a thriving place?
I think that there will still be a good market for application programs running on smartphones and a good market for application programs running on tablets, just as there will still be a good market for application programs running on notebook computers and a good market for application programs running on desktop computers (some of those programs might work well on more than one form factor).
Whether any of those markets will be as big, in terms of how many developers those markets can support, as they were before that happens is another matter.
The quality of apps would go up for sure, but isn't that exactly what we need?
Most if not all Linux distributions are Un*xes, in that the non-GUI APIs and shells and shell tools they offer are Un*x-flavored.
They're not "derived, however remotely, from AT&T code" Un*xes, nor are any distributions I know of "passed the Single UNIX Specification test suite and thus entitled to use the Unix trademark" Unixes.
What matters to most developers and command-line users is probably the first of those, so, for them, it's no less a Un*x than *BSD or OS X or Solaris or HP-UX or AIX or....
Slashdot Mirror
Opteron ought to be compared to POWER, not PowerPC, given the target markets.
Presumably referring to, as per the distinction I drew in "Both POWER (all-caps) and PowerPC refer both to instruction set architectures and brand names used on processors that implemented them.", POWER and PowerPC the brand names used on processors, not POWER and PowerPC the instruction set architectures.
Also, in the Windows world itself, you had 64-bit MIPS and Alpha based workstations that ran NT...
...which was a 32-bit OS, so it didn't provide 64-bit computing on those 64-bit processors.
Seeing as the PowerPC 970 ("G5") was the first 64-bit PowerPC (not POWER, though) processor, even the Opteron came out before the first 64-bit PowerPC.
As I said in an earlier post in this thread, "Both POWER (all-caps) and PowerPC refer both to instruction set architectures and brand names used on processors that implemented them."
If "the first 64-bit PowerPC" refers to PowerPC-the-brand, yes, the first one (other than the 620, which wasn't made in large quantities) was the 970.
If it refers to PowerPC-the-instruction-set, the first one was the POWER3 - it implemented the full PowerPC instruction set (as well as the POWER2 version of the POWER instruction set).
I suppose it depends on how you look at it. If you view the page directory as a bank select then it is a sort of segmentation.
If you view the page directory as a bank select then any form of paging with more than two levels of page table is a sort of segmentation, including x86 paging without PAE (all the way back to the 80386), and the form of paging on just about every modern processor.
And how many people actually owned a SPARC, POWER, or Itanic for that matter?
Well, some of the masses might have had G5 iMacs (PowerPC 970, 64-bit), but, yes, it took AMD to bring 64-bit to most of the masses.
At least one comment claims that the original title of the article was "64-bit Computing Reaches 10th Anniversary", which, if true, means the article came out with a bogus headline (there's more to "Computing" than stuff that runs on a mainstream desktop or laptop machine, and DEC OSF/1 came out in 1993, so it's been at least 20 years); if the original comment was posted before that, I can see his complaint (and the complaint of the person who pointed out that the MIPS R4000 came out before the first 64-bit PowerPC processor). Complaining about "64-bit x86 Computing Reaches 10th Anniversary" neglecting other 64-bit architectures, however, is silly.
PAE is more or less old school segmentation.
PAE isn't segmentation at all. It's a mode that changes the page table entry format to support more physical memory. Maybe you're thinking of something else as being "PAE", but Intel's (and AMD's and...) idea of PAE is a Physical Address Extension.
64-bit binaries are larger and might run 103% at the speed of 32-bit if you're lucky.
Maybe there is a lot of software written in C that uses int or unsigned when it should have typedef'd a size appropriate for its needs.
Software that's written in C, in all of the environments I know of for x86, has 32-bit ints (signed or unsigned) whether compiled 32-bit or 64-bit, so you're presumably not saying that those programs suddenly get 64-bit ints when compiled 64-bit. They will get 64-bit longs on UN*X (but not on Windows), and will get 64-bit pointers in either case.
but PAE is nothing but a spec on top of the other mess of bullshit known as segmentation.
Actually, no, it's a mode that changes the page table format to allow larger physical addresses in page table entries. Nothing to do with segmentation.
Only if it's a fat binary, but thankfully these never needed to catch on with the x86 to x86-64 transition.
...although they did anyway, in OS X (even though the vast majority of Macs had x86-64 processors).
The fact that they are, maybe? ints become twice as big,
If you're talking about C-language ints, on very few 64-bit platforms are they 64-bit. Most UN*Xes are LP64, not ILP64, and Windows is LLP64 (they didn't even make long 64-bit, unlike most UN*Xes).
so do pointers.
POWER != PowerPC
Both POWER (all-caps) and PowerPC refer both to instruction set architectures and brand names used on processors that implemented them.
The PowerPC ISA took the POWER ISA, added some stuff such as general-register-based multiply and divide instructions, and removed a few instructions (and didn't add in the ones used in the POWER2 processor).
POWER3 was a 64-bit processor that implemented the union of 64-bit PowerPC and POWER; I don't know whether any subsequent POWERn processors implemented the POWER ISA-only instructions or just the current version of the PowerPC/Power (not all-caps) ISA.
A 32-bit x86 app has access to 8 32-bit "general purpose" registers - they ain't really all general purpose because three of them are the stack pointer, frame pointer, and program counter.
You appear to have confused x86 with the PDP-11; the program counter ("instruction pointer" in x86land) is not one of the GPRs.
As for the frame pointer, GCC, for example, has a -fomit-frame-pointer flag that generates code that doesn't use EBP as a frame pointer, so it's available as a GPR. That might make debugging more difficult. If you're not just overlapping the data and stack segments, references through EBP implicitly go to the stack segment, so you'd have to use a segment-override prefix if it has a pointer to a location in a segment other than the stack segment, but if you're just overlapping them, that's not an issue. If you're using the ENTER or LEAVE instructions, EBP is a stack pointer; I don't know whether any current compilers bother with them.
What is so damn evil about making money? WHat is so evil about feeding your family?
Nothing. However, if making money to feed your family means using somebody else's GPLed code and not making the source to your project available, or using somebody else's GPLed or LGPLed code, with your own modifications, and not making the source to the modifications available, you should consider finding some other way to make money to feed your family. The author of the GPLed or LGPLed code is under no obligation to make it easier for you to do so.
Sure you can use GNU but who do these people are to prevent businesses to streamline their processes with software or to tell us we can't have dreams of a better life by writting the next killer app?
You can do both. Just don't, in the process, use other people's code in ways that they don't wish it to be used.
Clang supports every backend that llvm does. What it doesn't do is automaticity find all the libraries and header files that are standard for a plat form. But you can specify any target that llvm supports.
GCC doesn't support all those targets because they need to be explicitly included in at compile time.
By "targets" do you mean "instruction set architectures" or "ISA version + OS"?
And by "support" do you mean "if you build GCC it automatically includes support for all those targets without having to configure them in" or do you mean "allows support for that target to be compiled in"? If you mean the former of those two definitions of "support", that's not generally what "support" means in this context; if you mean the latter, well, which of "X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore" aren't supported? On the host/target specific installation notes for GCC page, I don't see any explicit mention of Thumb, CellSPU, MSP430, or XCore ("SystemZ", i.e. z/Architecture or "64-bit System/3x0", is called "s390x" on that page), although the ARM options page for GCC mentions Thumb; I see references on the Web to an "mspgcc" project for the MSP430, but it's not part of the GCC release, and I see mentions of an "spu-gcc", but nothing about Xcore.
In my benchmarks llvm is universally faster.
And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp
By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.
The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").
So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)
eh, gcc doesn't even follow C99, it's a half-assed C89
Are there any issues other than those mentioned in the GCC developers' status of C99 features in GCC page?
with all kinds of weird extension
Well, yes, if you specify --std=c99, "When a base standard is specified, the compiler accepts all programs following that standard plus those using GNU extensions that do not contradict it." You'd need -Wpedantic to get warnings about all GNU extensions and -pedantic-errors to get them as errors.
...will no longer sell any business machines. Interesting.
Someday that might be true, but, for now, they're selling these and these business machines.
They've still got System Z mainframe line, and I can't see them selling that business unit off
...and they also still have the IBM Power Systems line (Power Architecture boxes running IBM i, AIX, and Linux).
Schmidt is remarkably technical for a CEO (former Sun CTO with a T) which is really rare.
Yes, he is.
So then you admit that reputable scientists disagree with AGW and at the same time are not shills for this or that industry, etc. eh?
I'd have to study more of what they say to see whether that's the case or not. Even if they're reputable in their field and not shills for fossil fuel industries, that doesn't mean they're actually right.
And please, realclimate? A hotbed of political activism and environmental wackos.
And the reason why I should believe you when you make that assertion is? Are you reputable, or are you just an anti-AGW wacko?
And maybe because there are plenty of educated people here who don't drink the Kool Aid like you. If you'd bother to pay attention, there are plenty of scientists, who are uniformly smarter that your sorry ass, who also don't drink the Kool Aid.
And there are also plenty of smart scientists who do, in your words, "drink the Kool-Aid".
Hrmph, now you're being dense just to hold your side of the debate. Buddy, if you truly believe manufacturing smartphones, plastic bottles et al do nothing more than deplete resources, you're just as much in denial as those others you like to call "conservative."
Presumably, then, if you're (also? same AC or different?) arguing that "climate change is not just CO2 emissions", what you mean by that is "climate change is emissions of various greenhouse gases, including but not limited to CO2", and are arguing that manufacturing smartphones, plastic bottles et al cause the emission of greenhouse gases other than CO2.
The remarkably strong anti-gun sentiment that dominates nearly every thread
Statistics, please? I see both strong anti-gun and strong pro-gun comments (when I bother to look at all - the SNR is pretty low on most gun discussions - so maybe I just don't look at enough threads).
how can you predict the average of 100 dice rolls, when you can't even predict what the next dice roll will give?
If you can't predict the next dice roll, how come the house always wins?
Assuming you're not just trolling, the answer is "the house always wins on average". Somebody might luck out and Win Big, but enough people don't win at all that the big wins and the small wins are more than cancelled out.
I am praying this happens. I do not enjoy the many "Would you like to download our free forum app? Press cancel to continue to the web site" popups I get on my phone. Even if this does happen though, do you really think it means that the app market will not be a thriving place?
I think that there will still be a good market for application programs running on smartphones and a good market for application programs running on tablets, just as there will still be a good market for application programs running on notebook computers and a good market for application programs running on desktop computers (some of those programs might work well on more than one form factor).
Whether any of those markets will be as big, in terms of how many developers those markets can support, as they were before that happens is another matter.
The quality of apps would go up for sure, but isn't that exactly what we need?
I.e., we need to have the bubble pop? Yup, we do.
is Linux Unix?
Most if not all Linux distributions are Un*xes, in that the non-GUI APIs and shells and shell tools they offer are Un*x-flavored.
They're not "derived, however remotely, from AT&T code" Un*xes, nor are any distributions I know of "passed the Single UNIX Specification test suite and thus entitled to use the Unix trademark" Unixes.
What matters to most developers and command-line users is probably the first of those, so, for them, it's no less a Un*x than *BSD or OS X or Solaris or HP-UX or AIX or....