On 29/07/16 20:54, Warren D Smith wrote:
> On 7/29/16, Jonathan Wakely wrote:
>> Let's imagine we have a 4-bit type, called nibble.
>>
>> sizeof(nibble) == 1, because you can't have an object with a smaller size.
>>
>> nibble a[2];
>> sizeof(a) == 1;
>>
>> Because otherwise there isn't much benefi
On 29/07/16 18:26, Warren D Smith wrote:
Booleans are very useful - they turn up all over the place in programming.
Nibbles, on the other hand, are almost totally useless. There are very,
very few situations where you need to store a number that is within the
range 0 .. 15, and are so tightly c
On 29/07/16 20:01, Warren D Smith wrote:
> Similarly, when some twerp complained
Using terminology like this isn't acceptable on these lists. If that's
the way you want to treat people who disagree with you, please go elsewhere.
R.
On 29 July 2016 at 20:01, Warren D Smith wrote:
>> Given a pointer to an array of nibbles and a length, how do I iterate
>> through the array?
>
> for(i=0; i
> --correction, that was for an array of packed bools. For nybbles,
> bitsizeof(a)/4. There are various games one can play, and quibbles one
> Given a pointer to an array of nibbles and a length, how do I iterate
> through the array?
for(i=0; ihttp://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
On 7/29/16, Jonathan Wakely wrote:
> Let's imagine we have a 4-bit type, called nibble.
>
> sizeof(nibble) == 1, because you can't have an object with a smaller size.
>
> nibble a[2];
> sizeof(a) == 1;
>
> Because otherwise there isn't much benefit.
--bitsizeof() is required.
> So now we have a
Let's imagine we have a 4-bit type, called nibble.
sizeof(nibble) == 1, because you can't have an object with a smaller size.
nibble a[2];
sizeof(a) == 1;
Because otherwise there isn't much benefit.
So now we have a type which violates one of the core rules of the type
system. sizeof(nibble[2 *
> Booleans are very useful - they turn up all over the place in programming.
>
> Nibbles, on the other hand, are almost totally useless. There are very,
> very few situations where you need to store a number that is within the
> range 0 .. 15, and are so tightly constrained for space that you can'
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
Citerar Warren D Smith :
Also, I'm somewhat amazed how it is argued to me that a 9-bit machine
the PDP-10 is
covered by C fine, but yet, C insists on having everything a multiple
of 8 bits with padding bits disallowed, and that too is fine, and both
these facts refute me.
Wrong.
The C languag
>> But it failed to fully correct the error
>> because, at least with gcc's implementation of stdint.h, only 8,16,32,
>> and 64 are provided.
>These cover the needs of virtually everyone in virtually all cases.
--a bold claim, made with zero evidence presented. But
since we know that even 40 yea
> And hell, GCC already includes a lot of really really obscure
> builtin functions which are one hell of a lot less common & useful
> than multiply-hi&lo.
Which exactly proves the point that people are making: whether
something is "common & useful" is rarely the criteria that's used in
deciding w
> It *isn't* "putting every possible feature into every language."
> Did I ever advocate that?
Yes. When you say "X is a useful feature, therefore we should put it
into language Y", you are indeed implicitly advocating that. Because
if that were *not* the case, then saying that X is *useful* say
And hell, GCC already includes a lot of really really obscure builtin
functions which
are one hell of a lot less common & useful than multiply-hi&lo.
I merely cited div(a,b) because it was one of the least obscure among them.
How about freaking "isgraph" and "_mm_set1_epi32"?
I mean how can you ju
It *isn't* "putting every possible feature into every language."
Did I ever advocate that?
It's "putting a feature that you already put there, into the language,
just no longer
arbitrarily selecting certain integer sizes and excluding others."
Am I making syntax more complicated? No. I am if anyth
> 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.
I would suggest that you spend time learning basic principles about
language d
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
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 f
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
> On Jul 26, 2016, at 2:07 PM, 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 proc
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
> On Jul 26, 2016, at 12:50 PM, Warren D Smith wrote:
>
> ...
> Sigh. It's really hard to get compiler and language guys to do anything.
I find it puzzling that you appear to think that insulting your audience is the
best way to influence them.
> ...
> There is absolutely no good reason why
On 26/07/16 16:37, Warren D Smith wrote:
You would get on far better here if you tried a little politeness and
respect, rather than anger, accusations and confrontation.
The C standards were written by a group of very smart and experienced
people, refined over a long time based on real-world issu
On 26/07/16 16:55, Warren D Smith wrote:
> On 7/26/16, Joseph Myers wrote:
>> On Tue, 26 Jul 2016, Warren D Smith wrote:
>>
>>> (And in the case of uint4_t, it actually would not even BE an
>>> "extension" since as I said,
>>> the standard already allows providing other sizes.)
>>
>> Only sizes wh
On Tue, 26 Jul 2016, Warren D Smith wrote:
> --mind-boggling.
> So they actually intentionally made the language worse
> in the C11 TC3 revision versus the C99 standard.
There is no such thing as C11 TC3. All the relevant requirements about
being integer numbers of bytes are present in the orig
--mind-boggling.
So they actually intentionally made the language worse
in the C11 TC3 revision versus the C99 standard.
Sigh. It's really hard to get compiler and language guys to do anything.
I suggest the most stunningly obvious idea, they tell me I am an
idiot. Then years and years later, the
On Tue, 26 Jul 2016, Warren D Smith wrote:
> > Only sizes which are an integer number of bytes with no padding bits.
>
> wikipedia:
Wikipedia is not the standard (and, to be clear, C99 before TC3 had
various defects in the specification as well, so you should not
refer to pre-TC3 versions for
On Tue, 2016-07-26 at 10:37 -0400, Warren D Smith wrote:
> Also, I know on some machines to access a byte you have to get a word
> (larger than 8 bits)
> from memory, do shifts and masks. So clearly you already do that
> inside gcc.
> It therefore is trivial for you to do uint4_t also, because it
On 07/26/16 16:55, Warren D Smith wrote:
And they said "only if available in implementation" which gcc chose to
interpret as
"we're not going to make other sizes available, hahahaha."
"if available in implementation" probably means "if supported by the
underlying hardware".
So, if your hardw
On 7/26/16, Joseph Myers wrote:
> On Tue, 26 Jul 2016, Warren D Smith wrote:
>
>> (And in the case of uint4_t, it actually would not even BE an
>> "extension" since as I said,
>> the standard already allows providing other sizes.)
>
> Only sizes which are an integer number of bytes with no padding
On 26/07/16 15:37, Warren D Smith wrote:
> --the reason I am suggesting this to this forum, is I probably am not capable
> of
> recoding GCC myself.
> Why not learn from your own history, and do that again, with these two
> extensions?
> (And in the case of uint4_t, it actually would not even BE
On Tue, 26 Jul 2016, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto
On Tue, 26 Jul 2016, Warren D Smith wrote:
> (And in the case of uint4_t, it actually would not even BE an
> "extension" since as I said,
> the standard already allows providing other sizes.)
Only sizes which are an integer number of bytes with no padding bits.
--
Joseph S. Myers
jos...@codesou
On 7/26/16, Jonathan Wakely wrote:
> On 26 July 2016 at 14:31, Warren D Smith wrote:
>> 1. Gcc with stdint.h already
>> provides such nice predefined types as uint8_t.
>> Sizes provided are 8,16,32, and 64.
>> In some sense uint1_t is available too (stdbool.h)
>> but at least on my machine stdbool
On 26 July 2016 at 14:31, Warren D Smith wrote:
> 1. Gcc with stdint.h already
> provides such nice predefined types as uint8_t.
> Sizes provided are 8,16,32, and 64.
> In some sense uint1_t is available too (stdbool.h)
> but at least on my machine stdbool uses 8-bits to store a bool,
Because that
On 26/07/16 14:31, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto.
1. Gcc with stdint.h already
provides such nice predefined types as uint8_t.
Sizes provided are 8,16,32, and 64.
In some sense uint1_t is available too (stdbool.h)
but at least on my machine stdbool uses 8-bits to store a bool,
e.g. an array of 1000 bools takes 8000 bits,
which is asinine and kind
37 matches
Mail list logo
