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

[Christian Groessler]

Ok, I'm not affiliated with gcc, nor a committer, I just
happen to work on a port to a local architecture.

Your first posts were funny to read, and you ignored the answers,
and now it's getting old.

Not talking for the gcc community, I suggest that you go
away and come back when you have code to implement what
you propose. Then we can continue that discussion.

regards,
chris






On 07/26/16 21:06, Warren D Smith wrote:
> OK, you just said you've used packed nybble arrays a couple of times.
> 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.
>
> You just said you've written your own double-length multiply.
> Same proof.
>
> Thank you for proving my point.
>
> How many deaths does it take before it is worth putting into GCC?
> And it isn't like I'm suggesting something hard, or which would be
> unattractive to users.
>
> 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?  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 --
> 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?
>
> 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.
>
> Concerning suggestions I've made that never were adopted, I would like
> C to have array-bounds checking available as a compiler option.
> Also profiling.
> I'd like elsif.  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.
> 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.
> I'd like addons to support
> multiple entry points for routines easy, so I can make coroutines and
> "iterators."
> (This can be done with present C, but it seems a much bigger pain than
> it needs to be.)
>
> 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.
>
> But hey, nearly all those ideas actually require work, meanwhile I
> think uint4_t is
> nearly trivial by comparison.
>
>
>
>