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.

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.

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.

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

Are there any issues other than those mentioned in the GCC developers' status of C99 features in GCC page?

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.

Someday that might be true, but, for now, they're selling these and these business machines.

...and they also still have the IBM Power Systems line (Power Architecture boxes running IBM i, AIX, and Linux).

Yes, he is.

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 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 there are also plenty of smart scientists who do, in your words, "drink the Kool-Aid".

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.

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

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.

Seriously, what else could *possibly* motivate AT&T to announce "Austin" rather than one of the hundred other similar markets they could be moving into? Are they looking forward to making half as much revenue as they would if they entered a city with no gigabit competition? Are they proud that they'll be increasing the maximum speed available to Austinites by 0% rather than increasing the maximum speed available in another city by 9900%?

Of course not. They're showing Google, "moving in on our turf won't be profitable, because we'll try to undercut you every time you make a move, so you might as well give up and leave us with our oligopoly."

It'll be fascinating to see what Google's response (both in terms of words and actions) will be. Does "don't be evil" include "don't concede to evil"?

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.

I.e., we need to have the bubble pop? Yup, we do.