This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Two suggestions for gcc C compiler to extend C language (by WD Smith)


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]