«

On 11/28/2012 07:29 PM, Tim Wescott wrote:
....
> Grant did not include all of the context, so you need to read back a bit.
>
> The original statement was that (a) int16_t * int16_t coughs up a 16-bit
> result, unless (b) one of the int16_t numbers is cast to 32 bit.
>
> Then I pointed out that (c) there are some older, non-compliant compilers
> where you have to cast _both_ 16-bit operands to 32 bits to get a 32 bit
> result, and (d) that I trusted that the gcc compiler was ANSI C
> compliant. Statement (c) is important for the embedded space (which is
> the group that I am replying from -- you must be from comp.lang.c)
> because one does not always have the luxury of using a compliant tool
> chain in embedded.
>
> Then Grant came in, and if I'm correctly reading what he said, stated
> that (e) the gnu-avr compiler is not ANSI-C compliant because it has 16
> bit integers.

Sort-of, but not quite. When he said "Nope", he wasn't referring to your
expectation that gcc-avr was ANSI compliant. He was referring to your
expectation that it would promote 16-bit integers to 32 bits. On a
conforming implementation of C with 16-bit ints, promotion of integer
types halts at 16 bits, and goes no further.

> So you are correcting statement -- uh, (0), because no one made it (the
> first quote from me refers to statement (b), and appears in its native
> habitat two or three posts up in the thread).

It was that first quote from you that I'm correcting. Not any other
statement. Specifically:

> I would expect that gcc would be ANSI compliant, and would therefore
> promote both 16-bit integers to 32-bit before doing the multiply.
--
James Kuyper

On 11/28/2012 08:19 PM, Tim Wescott wrote:
....
> Just for clarification, since what I said above seems to be easy to
> misread unless you pay close attention to context: take "promote both 16-
> bit integers to 32-bit" and add in the context (about casting one or more
> of the 16 bit values); the result reads "promote both 16-bit integers to
> 32-bit _if you cast just one 16-bit integer to 32 bit_".

There is a conversion to 32-bits, but it is NOT a promotion. See
6.3.1.1p2 for a definition of the integer promotions.
--
James Kuyper

James Kuyper <> writes:
> On 11/28/2012 07:29 PM, Tim Wescott wrote:
> ...
> > Grant did not include all of the context, so you need to read back a bit.
> >
> > The original statement was that (a) int16_t * int16_t coughs up a 16-bit
> > result, unless (b) one of the int16_t numbers is cast to 32 bit.
> >
> > Then I pointed out that (c) there are some older, non-compliant compilers
> > where you have to cast _both_ 16-bit operands to 32 bits to get a 32 bit
> > result, and (d) that I trusted that the gcc compiler was ANSI C
> > compliant. Statement (c) is important for the embedded space (which is
> > the group that I am replying from -- you must be from comp.lang.c)
> > because one does not always have the luxury of using a compliant tool
> > chain in embedded.
> >
> > Then Grant came in, and if I'm correctly reading what he said, stated
> > that (e) the gnu-avr compiler is not ANSI-C compliant because it has 16
> > bit integers.
>
> Sort-of, but not quite. When he said "Nope", he wasn't referring to your
> expectation that gcc-avr was ANSI compliant. He was referring to your
> expectation that it would promote 16-bit integers to 32 bits. On a
> conforming implementation of C with 16-bit ints, promotion of integer
> types halts at 16 bits, and goes no further.

The context was

>>> Shouldn't casting just one of the 16 bit values work the same as
>>> casting both of them?

i.e. that there was one cast to 32 bits already. Therefore ANSI C
says that there would be a second conversion to 32 bits of the other operand.
Or at least the resulting code should behave *as if* that had happened.
(I'm pretty sure I've seen an architecture with shorter*longer->longer
opcodes.)

Initially I thought what Tim wrote was in error, but upon unravelling
the thread, I worked out that he had gone forward from the premises
correctly, and others hadn't. Without those premises - confusion ensues.

Phil
--
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

In comp.lang.c Phil Carmody <> wrote:

(snip, someone wrote)

>>>> Shouldn't casting just one of the 16 bit values work the same as
>>>> casting both of them?

> i.e. that there was one cast to 32 bits already. Therefore ANSI C
> says that there would be a second conversion to 32 bits of the other operand.
> Or at least the resulting code should behave *as if* that had happened.
> (I'm pretty sure I've seen an architecture with shorter*longer->longer
> opcodes.)

Maybe, but many have N*N-->2N multiply. Some compilers figure out
that if you cast one (or both) from a shorter length that they can use
such a multiply on the shorter length. This especially important when
the size is large enough that the hardware doesn't support it.

Many 32 bit machines have a 32*32 --> 64 multiply, and a 64 bit
(long long) type. If you cast one (or both) 32 bit int to 64 bit
(long long), the compiler knows to use the 32 bit multiply.

> Initially I thought what Tim wrote was in error, but upon unravelling
> the thread, I worked out that he had gone forward from the premises
> correctly, and others hadn't. Without those premises - confusion ensues.

-- glen

On 11/29/2012 01:59 AM, Tim Wescott wrote:
> On Wed, 28 Nov 2012 23:39:52 -0500, James Kuyper wrote:
>
>> On 11/28/2012 07:29 PM, Tim Wescott wrote:
....
>> Sort-of, but not quite. When he said "Nope", he wasn't referring to your
>> expectation that gcc-avr was ANSI compliant. He was referring to your
>> expectation that it would promote 16-bit integers to 32 bits. On a
>> conforming implementation of C with 16-bit ints, promotion of integer
>> types halts at 16 bits, and goes no further.
>
> How can you possibly know? Do you read his mind? Have an uncited
> conversation with him? Is he your sock-puppet?

I can read and understand English, and in particular, the specialized
dialect of it which is sometimes called "standardese". I understood
precisely what he was talking about. In particular, I understand what
"promotion" means in the context of the C standard, and know that you
used the term incorrectly, something which you still do not seem to have
understood - nothing in your comments indicates any awareness that this
is the issue we're both talking about.

>> It was that first quote from you that I'm correcting. Not any other
>> statement. Specifically:
>>
>>> I would expect that gcc would be ANSI compliant, and would therefore
>>> promote both 16-bit integers to 32-bit before doing the multiply.
>
> Oh Christ. READ THE CONTEXT. That statement was made in reply to a
> question asking about what would happen if you cast one of the operands
> to 32 bit! And you're replying to a post that told you that it was
> misleading without its context, and again taking it out of context.

A conforming implementation of C will promote integer values to 32 bits
only if 'int' is exactly 32-bits. Do you believe that the context I've
missed changed 'int' to a 32-bit type? If not, your use of "promote" to
describe that conversion is incorrect, though your expectation that
there would be such a conversion is accurate.
--
James Kuyper

On 11/29/2012 05:03 AM, Phil Carmody wrote:
> James Kuyper <> writes:
....
>> Sort-of, but not quite. When he said "Nope", he wasn't referring to your
>> expectation that gcc-avr was ANSI compliant. He was referring to your
>> expectation that it would promote 16-bit integers to 32 bits. On a
>> conforming implementation of C with 16-bit ints, promotion of integer
>> types halts at 16 bits, and goes no further.
>
> The context was
>
>>>> Shouldn't casting just one of the 16 bit values work the same as
>>>> casting both of them?
>
> i.e. that there was one cast to 32 bits already. Therefore ANSI C
> says that there would be a second conversion to 32 bits of the other operand.

Of course. I knew that context, and knew that the conclusion you
describe was the correct result. However, that's not the conclusion Tim
Wescott reached - the conversion you describe is part of the usual
arithmetic conversions (6.3.1.8p1) but is NOT an integer promotion
(6.3.1.1p2).

> Initially I thought what Tim wrote was in error, but upon unravelling
> the thread, I worked out that he had gone forward from the premises
> correctly, and others hadn't. Without those premises - confusion ensues.

Those premises had nothing to do with the confusion, which is about the
meaning of the word "promote" in the context of the C standard.
--
James Kuyper

On 2012-11-29, Tim Wescott <> wrote:

> Grant did not include all of the context, so you need to read back a bit.
>
> The original statement was that (a) int16_t * int16_t coughs up a 16-bit
> result, unless (b) one of the int16_t numbers is cast to 32 bit.
>
> Then I pointed out that (c) there are some older, non-compliant compilers
> where you have to cast _both_ 16-bit operands to 32 bits to get a 32 bit
> result, and (d) that I trusted that the gcc compiler was ANSI C
> compliant. Statement (c) is important for the embedded space (which is
> the group that I am replying from -- you must be from comp.lang.c)
> because one does not always have the luxury of using a compliant tool
> chain in embedded.

I misread part of your post as claiming that even without casts a
compliant compiler would promote both 16-bit operands to 32-bits. I
was attempting to point out that isn't true if an "int" is 16-bits
(it's a not-uncommon misapprehension that gcc is only available with
32 or 64 bit ints).


> Then Grant came in, and if I'm correctly reading what he said, stated
> that (e) the gnu-avr compiler is not ANSI-C compliant because it has 16
> bit integers.

Ah, that's not what I intended to write. AFAICT, everybody agrees
with everybody else, we just aren't managing to express that clearly.

--
Grant Edwards grant.b.edwards Yow! People humiliating
at a salami!
gmail.com

On 2012-11-29, Tim Wescott <> wrote:
> On Wed, 28 Nov 2012 23:39:52 -0500, James Kuyper wrote:
>
>> On 11/28/2012 07:29 PM, Tim Wescott wrote:
>> ...
>>> Grant did not include all of the context, so you need to read back a
>>> bit.
>>>
>>> The original statement was that (a) int16_t * int16_t coughs up a
>>> 16-bit result, unless (b) one of the int16_t numbers is cast to 32 bit.
>>>
>>> Then I pointed out that (c) there are some older, non-compliant
>>> compilers where you have to cast _both_ 16-bit operands to 32 bits to
>>> get a 32 bit result, and (d) that I trusted that the gcc compiler was
>>> ANSI C compliant. Statement (c) is important for the embedded space
>>> (which is the group that I am replying from -- you must be from
>>> comp.lang.c) because one does not always have the luxury of using a
>>> compliant tool chain in embedded.
>>>
>>> Then Grant came in, and if I'm correctly reading what he said, stated
>>> that (e) the gnu-avr compiler is not ANSI-C compliant because it has 16
>>> bit integers.
>>
>> Sort-of, but not quite. When he said "Nope", he wasn't referring to your
>> expectation that gcc-avr was ANSI compliant. He was referring to your
>> expectation that it would promote 16-bit integers to 32 bits. On a
>> conforming implementation of C with 16-bit ints, promotion of integer
>> types halts at 16 bits, and goes no further.
>
> How can you possibly know? Do you read his mind? Have an uncited
> conversation with him? Is he your sock-puppet?

That is indeed what I meant.

--
Grant Edwards grant.b.edwards Yow! Now KEN and BARBIE
at are PERMANENTLY ADDICTED to
gmail.com MIND-ALTERING DRUGS ...

On 2012-11-29, Tim Wescott <> wrote:
> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:

> Me, I just try to remember that x, y or z went wrong on some compiler
> some time, so that if I see symptoms again those problems are on my short
> list, and maybe even a fix or two.
>
> Like Texas Instrument's Code Composter for the TMS320F2812, which has a
> 32-bit "double". #$%@.

Or on the TMS320C40, where char, int, long, long long, float and
double are all 32 bits and all have a sizeof() 1. Trying to impliment
any sort of communications protocol with that was fun.

--
Grant Edwards grant.b.edwards Yow! Is it NOUVELLE
at CUISINE when 3 olives are
gmail.com struggling with a scallop
in a plate of SAUCE MORNAY?

On 2012-11-29, Tim Wescott <> wrote:

> It's certainly what I would expect from gcc-avr. There's no reason you
> can't make a beautifully compliant, reasonably efficient compiler that
> works well on the AVR.

avr-gcc does indeed work very nicely as long as you don't look at the
code generated when you use pointers. You'll go blind -- especially
if you're used to something like the msp430. It's easy to forget that
the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
16-bit pointers on the AVR requires a lot of overhead.

--
Grant Edwards grant.b.edwards Yow! I wonder if I could
at ever get started in the
gmail.com credit world?