I am assuming you intended to post this on the mailing list, so I have
restored the addresses.
On 26/07/16 19:55, Warren D Smith wrote:
> 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.)
No, what the MIPS example shows is that you do not need an "add with
carry" instruction in order to handle multi-precision arithmetic. MIPS
does not have a carry flag, or any sort of condition code register.
This is not an unreasonable design decision - condition code registers
are often bottlenecks that make pipelining or out-of-order scheduling
significantly harder than necessary. Other RISC architectures without
flag registers include the Alpha and RISC-V. You use a similar sequence
to the one you found for MIPS for doing multi-precision addition here.
You may note that the MIPS sequence here translates directly to the
sequence:
typedef struct {
uint32_t lo;
uint32_t hi;
} pair;
pair addPairs(pair a, pair b) {
pair r;
r.lo = a.lo + b.lo;
r.hi = (r.lo < b.lo);
r.hi += a.hi;
r.hi += b.hi;
return r;
}
I don't have a MIPS target gcc conveniently on hand, but I suspect this
C code would generate pretty much the same sequence of instructions.
And note that the C code here is generic - it is not MIPS specific.
>
> Now it might be I'm wrong and some computers now not providing it. If
> so, that is world
> damage caused by GCC.
gcc is an influential project - but not /that/ influential!
Back in the real world, people who design highly successful processor
architectures do so using good, solid technical reasons for their key
design decisions.
> 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!"
Processor designers take their target audience into account. And most
targets use C (either directly, or indirectly via libraries, VMs, etc.)
for a good deal of critical programs. So yes, processor designers
consider "how well does this design fit C?". They don't typically think
of gcc exclusively, but C in general.
> 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.
But the example you posted showed that there is no need to have access
to the carry flag in C - there is no need to have a carry flag at all.
And when I compiled that code on x86, gcc used the carry flag in order
to generate optimal code with an add and an adc instruction. It really
is hard to do better.
>
> 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.
I have to wonder - why are you using C at all? And why are you using gcc?
>
> 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.
Your first post was silly, and you have gone downhill since then.
> 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.
Can you give a concrete example of this?
>
> 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.
I have been a C programmer for over twenty years, and have only had to
use packed-nibble arrays a couple of times. It was not particularly
hard. I don't remember ever having to write double-length
multiplication since C99 "long long" came out, and before that it was
not hard either. And it certainly was not something I had to do all the
time. And I work with very low level embedded systems.
What sort of coding do you do that requires these "annoying workarounds"
"all the time", and why can't you just write it once and re-use the code?
>
> 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?
>
>
