On 26/07/16 21:06, Warren D Smith wrote:
> OK, you just said you've used packed nybble arrays a couple of times.
Yes, a couple of times in 20+ years. And I work with the kind of
programming where something like nibble arrays could conceivably be
useful. For most C programmers, "int" is the only integer type they
ever need or use, and they will probably not even have heard of a
"nibble". It is absolutely a non-issue.
> Multiplying you by 100,000 that proves if you put it in GCC,
> you'd save 200,000 programmer hours, which is equivalent to saving
> over 2 lives.
That claim is absurd in every way imaginable.
>
> You just said you've written your own double-length multiply.
> Same proof.
Again, you are completely wrong. Double-length multiplies are very
rarely necessary, so there is no point in having extra compiler features
in order to make them simpler. In the rare cases where they /are/
needed, it is not hard to implement them yourself. And gcc has already
made the process easier and more efficient over the years, by making
real and beneficial advances that have the side-effect of making
double-length multiplies easier and more efficient (general optimisation
improvements make the code more efficient, the C99 long long removed
almost all use-cases for manual extended integer arithmetic, and the
__builtin_XXX_overflow instructions are available).
It is hard to imagine how you could be more wrong in what you write. I
don't know whether you are just ignorant and angry at something, or
trolling.
>
> Thank you for proving my point.
>
> How many deaths does it take before it is worth putting into GCC?
You are now claiming that adding a double-length "mul" builtin to gcc
would save lives? Seriously?
> And it isn't like I'm suggesting something hard, or which would be
> unattractive to users.
Making a double-length multiply built-in would not be very hard - but it
is far easier to write it in C source code than to add it to the
compiler. And yes, it would be unattractive to users - for almost
everybody, it would be useless but use an identifier "mul" that could
conflict with their own code.
And of course there is the key point that the gcc developers are not
lazy, despite your claims - they are extremely dedicated and hard
working, often in their free time. There are large numbers of /useful/
features (and occasional bug fixes!) that are on their "todo" lists.
Any time spent on meaningless ideas that can be handled perfectly well
at the moment is time they cannot spend on something the people actually
want.
>
> And thanks for the tip on how to do add-with-carry.
> That's nice. Now I have to ask, now you've helpfully demonstrated
> how nice it can be, why not put that niceness inside GCC?
gcc /has/ that "niceness" - the code I wrote works fine with gcc. (And
gcc has the __builtin_XXX_overflow functions - I suspect you did not
bother looking at the documentation about the features gcc supports,
before ranting about what's missing.)
> I mean, if
> GCC already is going to
> provide div(a,b) -- it was not me who asked for that, it was GCC that
> decided to provide it --
"div" was specified in the earliest versions of the C standards, before
gcc was conceived.
> which I could have just got in plain C using q=a/b; r=a%b; and depended on
> optimizer, zero thought required -- then how can just justify GCC
> *not* providing addc(a,b) when it is trickier for the programmer, so
> you are clearly providing something more helpful since was more
> tricky?
"div" is documented in the standards - the compiler or library has no
option but to support it, even if people can now get at least as good
code (in most cases) by writing the operations individually.
It is true that it was the gcc folks that made the decision to have a
builtin version as an alternative to a library call. They have tried to
do that for many simple or commonly used standard library functions,
because that is useful for a lot of code.
>
> Why am I bothering? You prove my point then act as though you proved
> opposite.
>
> Concrete examples? Hell, I suggested stdint.h years and years before
> it came along, and I was told I was an idiot. I suggested making a
> lot of library functions be builtins, told I was an idiot, and now lo
> and behold, years and years later, gcc makes many library functions be
> builtins. I complained the stdio library was a disaster waiting to
> happen with
> buffer overflows, told I was an idiot, and lo and behold, years and
> years later people keep trying to work around that, with at least two
> people having written nonstandard replacement libraries to try for
> safety, and huge billions of dollars estimated to be lost due to this
> bad design.
Judging by your writing here, you were told that you were an idiot
because you are an idiot. There may be the occasional good idea hidden
behind the piles of nonsense, insults, rants, accusations and
complaints, but they would be hard to see. And none of these examples
are remotely innovative - every experienced C programmer who thought
"how could C and/or gcc be improved?" had the same ideas. The challenge
has always been finding ways to implement such ideas in a manner that is
consistent, useful across a range of systems and programs, efficient,
safe, implementable, etc. It does not take a genius to say "it would be
useful to have integer types with known sizes" - but it takes a lot of
geniuses working together to turn that into a reality in a programming
language like C.
>
> Concerning suggestions I've made that never were adopted, I would like
> C to have array-bounds checking available as a compiler option.
Again, you haven't read the gcc documentation, have you? For processors
that can do this efficiently, bounds checking is available. (Static
bounds checking is also done when possible.)
And for any other use where array bounds checking would be costly at
run-time, you have to implement it yourself in C. C arrays maximise
efficiency and simplicity at the cost of safety. C is a low-level
language - that's the way it works. But you are free to write access
functions in any way you want, or use a higher level language with more
features.
> Also profiling.
gcc has supported profiling for decades, I believe.
> I'd like elsif.
#define elsif else if
> I'd like more sophisticated compile time stuff, like right now
> they have #if, #elsif, #endif. Ok, why not #for? That way we could unroll
> loops by "doing the loop at compile time" not runtime. (Need to make
> a language subset intentionally weakened to not be turing complete, i.e. we
> want to know for sure the compile always will terminate, but still
> precompiler language could be a good deal more powerful than now.) I
> could discuss that.
> I'd like a compile-time language giving you a fair amount of power, but
> below turing-power, and
> acting as though it were sensibly designed in from start with similar syntax
> (within reason) to the actual runtime language -- not intentionally
> different syntax for no reason aside from trying to annoy people, and
> not an obvious crude add-on.
You'll find C++ next door. It is a marvellous language, and includes
all of the features you ask for here. And with a little practice (or
googling for libraries) you can also get your 128 bit integers, safe
strings, and everything else you are keen on.
C is a simple, stable, low-level language which specifically gives you
only limited features but with the control and flexibility to implement
anything you want. If you want a higher level language with more
features, then C is not for you. C++ would be a fine choice.
> I'd like different parts of my program to be optimized for space, or
> for speed -- I get to say for which parts I want which using pragmas.
Do you mean this?
#pragma GCC optimize ("Os")
#pragma GCC optimize ("O2")
It turns out - like many of your moans - that gcc already supports this.
It does so in several ways, including pragmas, function attributes, and
(best of all) automatic analysis of hot and cold functions so that you
don't have to do this manually.
> I'd like addons to support
> multiple entry points for routines easy, so I can make coroutines and
> "iterators."
Proper support for coroutines is /well/ outside the scope of C. That
would not be an "addon" - it would be a redesign of the entire
programming language for a feature that has little use in real
programming tasks but a massive negative impact on efficiency and
simplicity. And for modern systems, most problems that are well suited
to coroutines are better implemented with threads (and C, C++, and gcc
all have steadily improving support for threads).
Iterators are easily implemented in C - there is no need for any addons.
They are even neater in C++.
> (This can be done with present C, but it seems a much bigger pain than
> it needs to be.)
Google for "protothreads".
>
> Pointer arithmetic is a well known disaster-waiting-to-happen in C,
> but of course there are compensating performance benefits... but
> you could get the best of both worlds with ability to declare "safe"
> pointers e.g. with bounds checking of them added by compiler and the bounds
> created when the pointer is. Such safety could be turned off with a
> compiler option for more speed. Point is, C arrays and pointers are
> very unsafe for a few reasons, but by
> adding some compiler options and/or language extensions to allow
> adding safe versions
> of that stuff, GCC could make it a lot easier on programmers to get a
> lot safer with
> near zero effort.
Try C++.
>
> But hey, nearly all those ideas actually require work, meanwhile I
> think uint4_t is
> nearly trivial by comparison.
>
Your uint4_t may be trivial in comparison to some of your other ideas,
but it is certainly not trivial. However, until you understand C or how
cpus actually work, you are not in a position to judge.
