To the guy who falsely claimed MIPS fails to provide an add with carry instruction, a google search in 1 minute finds this:
stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly I defy you to find any processor not providing add with carry, (And I'm not talking about semantic bullshit. MIPS provides add with carry, even if they do not call it that, as this answer shows.) Now it might be I'm wrong and some computers now not providing it. If so, that is world damage caused by GCC. How so? Simple. Code out there is written on C. Processor designers observe real world code. "Aha!" They say. "Real word code hardly ever seems to use add-with-carry! I guess we should eliminate it!" If and when that happens it is a disaster, and the direct cause of that disaster, was the laziness of writers of such things as GCC. They cripple the programmer, then the hardware guys say "aha! programmers are crippled! That proves they like being crippled!" OK? So it is not merely that you are providing a bad product, it is worse (if you are right about this) -- actually damaging the world. Now as my critic said (it is amazing the absurd lengths people will go to to pretend fossilized crud was a "good decision") a purpose of languages like C is to provide a nice set of portable abstractions. Well, add with carry IS a nice portable abstraction. So is multiply Nwide*Nwide --> 2Nwide. And as some other critic said, languages have different purposes, and PASCAL may have had different purposes than C. As usual for my critics, again this was confused, because it was an explicit goal of C to get close to the machine. That was not so much a goal of PASCAL. It was a goal of C. That means it is absurd for C to refuse to provide packed boolean arrays while PASCAL does, and also while C already has made uintN_t types for various N. Also, I believe the original machine was a PDP-9 not PDP-11, not that it matters. Look, I could go on. But this is getting silly. Basically, what happens is 1. compiler/language guys do a bad job. 2. others point it out. 3. CLGs then pretend it was a good decision made by very very wise minds for mysterious unknown reasons nobody can explain, or just make shit up, or complain anybody pointing it out is rude, or mumble about different goals of different languages, or invent ludicrous arguments to "justify" situation, or argue anybody could implement it themselves because language is Turing complete, so no need. 4. The real reason they are doing (3) is simple: they are lazy. 5. Pointing our their laziness and incompetence is "rude." But due to the always-response of type 3 made by the CLGs to any suggestion whatever, there is no other alternative, is there? You are forcing it upon me, aren't you? 6. Years and years later eventually the CLGs do the right thing, always pretending it was their own idea and that they'd never said it was idiotic to do it. I just wish this process could be shortcut. Now look. I'm actually willing to write you code to do the things I suggested, e.g. implement packed nybble arrays in C. It will do it with cruddy syntax, but it'll work and pretty efficiently. I'd also be willing to write some assembler patches to implement, e.g. double-length multiply. These will not be a compiler. They will rather, be the sort of annoying workarounds programmers like me have to do all the time, to get around the fact that the compiler and language try to prevent you from doing them. But the thing is, I'm not willing to write that stuff for you unless you promise to actually add these things to GCC. So, will anybody make that promise? -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
