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. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)