Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28629 > unrolled thread

Re: Getting started with AVR and C

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 04:18 +0700
    Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-24 17:09 -0500
    Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-24 22:12 +0000
      statement / expression contexts in C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 12:54 +0700
      Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 13:37 +0700
        Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-28 14:49 +0000
        Re: Getting started with AVR and C Frank Miles <fpm@u.washington.edu> - 2012-11-28 17:53 +0000
          Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 18:05 +0000
            Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 12:56 -0600
              Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 21:45 +0000
                Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 15:55 -0600
                Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-29 01:35 +0100
                  Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 01:47 +0100
                    Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:24 +0100
                  Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 01:18 +0000
                    Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 20:07 -0600
                      Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:23 +0000
                        Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 11:01 -0500
                          Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 19:19 +0000
                            Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 14:32 -0500
                          Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 11:44 -0800
                            Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 21:23 +0000
                              Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:15 -0800
                          Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:17 +0200
                            Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 12:36 -0800
                              Re: Getting started with AVR and C Stephen Sprunk <stephen@sprunk.org> - 2012-11-29 16:22 -0600
                                Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:36 -0800
                              Re: Getting started with AVR and C "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2012-12-11 10:53 +0100
                                Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-11 14:53 +0000
                                  Unicode Ivan Shmakov <oneingray@gmail.com> - 2012-12-14 23:25 +0700
                                  Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 14:30 -0500
                                    Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 12:24 -0800
                                      Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 18:02 -0500
                                        Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 15:45 -0800
                                          Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-16 22:55 -0500
                                            Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-16 23:20 -0800
                                        Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:27 +0200
                                      Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-17 11:17 +0000
                                        Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 14:07 +0000
                                    Re: Getting started with AVR and C Nobody <nobody@nowhere.com> - 2012-12-16 03:28 +0000
                                    Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-16 10:40 +0200
                  Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 02:31 +0000
                    Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 03:36 +0000
                      Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 03:55 +0000
                    Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:37 +0100
                      Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:31 +0000
                        Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:44 +0100
                      Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 13:22 +0100
                        Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:32 +0000
                          Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:28 -0800
                      Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:20 +0000
                      Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:07 -0500
                        Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:17 -0500
                          Re: Getting started with AVR and C pete <pfiland@mindspring.com> - 2012-11-29 18:25 -0500
                            Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 22:46 -0500
                              Re: Getting started with AVR and C lawrence.jones@siemens.com - 2012-11-30 11:47 -0500
                            Re: Getting started with AVR and C Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 03:53 -0800
                        Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:38 -0800
                          Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 15:21 -0500
              Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 22:26 +0000
                Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 17:32 -0600
                  Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 19:02 -0500
                    Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 18:29 -0600
                      Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:39 -0500
                        Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-29 00:59 -0600
                          Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 07:57 -0500
                            Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-29 13:02 -0600
                          Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:19 +0000
                        Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-29 12:03 +0200
                          Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:39 +0000
                          Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 08:04 -0500
                      Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:17 +0000
              Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:19 -0600
                Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:44 -0500
          Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 13:15 -0500
            Re: Getting started with AVR and C Arlet Ottens <usenet+5@c-scape.nl> - 2012-11-28 19:17 +0100
              Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:30 -0600
                Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:29 +0000
                  Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-29 16:36 +0000
                    Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:40 +0200
                      Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 13:55 -0800
                        Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 22:06 +0000
                          Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 14:22 -0800
                      Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 21:59 +0000
                        Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-30 08:29 +0000
    Re: Getting started with AVR and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-25 05:41 -0800
    Re: Getting started with AVR and C Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 10:21 +0100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#29317

On Sat, 15 Dec 2012 14:30:44 -0500, Richard Damon
<news.x.richarddamon@xoxy.net> wrote:

>On 12/11/12 9:53 AM, John Devereux wrote:
>> 
>> UTF-8 is the way forward isn't it?
>> 
>
>As with most compression systems it depends on what the usage pattern of
>characters is. If the text base is mostly the 7 bit ASCII character set,
>with some of the other lower valued characters and only a few bigger
>valued characters, UTF-8 makes sense. If most of the characters are in
>the larger values (like using a non-Latin based character set) then
>UTF-16 may make much more sense.

For any given non-Latin based language, there are only a few possible
bit combinations in the first byte(s) of the UTF-8 sequence, thus it
should compress quite well.

For use inside a program, UTF-32 would be the natural choice with 1
array element/character.

Compressing a UTF-32 file using some form of Huffman coding, should
not take more space than compressed UTF-8/UTF-16 files, since the
actually used (and stored) symbol table would reflect the actual usage
of sequences in the whole file. Doing the compression on the fly in a
communication link would be less effective, since only a part of the
data would be available at a time, in order to keep the latencies
acceptable. 

[toc] | [prev] | [next] | [standalone]

#28770

In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote:

(snip, someone wrote)
>>> I would expect that gcc would be ANSI compliant, and would therefore
>>> promote both 16-bit integers to 32-bit before doing the multiply.

(snip, then I wrote)
>> Maybe I am missing something here, but are there versions of gcc for 16
>> bit processors, with 16 bit int? If so, then promotion to int won't
>> promote to 32 bits without a cast.
 
> The correct behaviour for C standards compliance is that when you 
> multiply two operands of different int size, the smaller one is promoted 
> to the size of the larger one.  Then the multiply is carried out modulo 
> the size of the larger one.  Then the result is truncated or extended as 
> needed to fit the target variable.

I haven't read the standard so recently, but I thought that was only
after the default promotions. Values smaller than int would be promoted
to int, then the size of the multiply (and product) determined.

If you multiply two 8 bit unsigned char values, is the product 
modulo 256? I don't think so.
 
> So the bit-size of the processor, and the bit-size of "int" on that 
> particular target, is irrelevant.  And the size of the result variable 
> is also irrelevant (this catches out some newbies).
 
> Given:
 
> int16_t a, b;
> int32_t c
 
> c = (int32_t)a * b;
 
> Then b is cast to int32_t, the 32-bit multiplication is carried out, and 
> the result assigned to c.

Maybe not completely irrelevent, consider a system with a 64 bit int.
 
> If you write just "c = a * b", then the multiplication is carried it at 
> 16-bit, then promoted to 32-bit.  This applies regardless of the 
> bit-size of the target - you will get the same effect on a 64-bit cpu as 
> on the 8-bit AVR.

Regardless of the target size, but not of int size.
 
> If your compiler does 16-bit multiplications when you have "c = 
> (int32_t) a * b", and requires two "int32_t" casts to do 32-bit 
> multiplication, then your compiler is very badly broken.  As Tim says, 
> badly broken compilers /do/ exist, so if you have to use them, then you 
> need to use two casts.  But I personally don't think you need to write 
> your code to work with broken toolchains unless you actually have to.

Now it gets interesting. When were the int_32_t and int_16_t added to C?

Seems to me that compilers only claiming a version of the standard
before they were added wouldn't have to use the same rules.

Consider that a compiler might have a int_128_t that it could add and
subtract, but not multiply or divide. Maybe it can generate a 128 bit
product from two 64 bit operands. Does the standard prohibit a 
compiler from offering those operations?

-- glen

[toc] | [prev] | [next] | [standalone]

#28773

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote:
>
> (snip, someone wrote)
>>>> I would expect that gcc would be ANSI compliant, and would therefore
>>>> promote both 16-bit integers to 32-bit before doing the multiply.
>
> (snip, then I wrote)
>>> Maybe I am missing something here, but are there versions of gcc for 16
>>> bit processors, with 16 bit int? If so, then promotion to int won't
>>> promote to 32 bits without a cast.
>  
>> The correct behaviour for C standards compliance is that when you 
>> multiply two operands of different int size, the smaller one is promoted 
>> to the size of the larger one.  Then the multiply is carried out modulo 
>> the size of the larger one.  Then the result is truncated or extended as 
>> needed to fit the target variable.
>
> I haven't read the standard so recently, but I thought that was only
> after the default promotions. Values smaller than int would be promoted
> to int, then the size of the multiply (and product) determined.

Yes, it's two-stage process.

In case it helps, here is the terminology as used by the C standard:

"integer promotions"  These are the conversions that often occur prior
to preforming an arithmetic operation.  They form part of the:

"usual arithmetic conversions" which is how a common type is arrived at
for arithmetic operations that requite it.  Unless complex or floating
types are involved, the integer promotions are performed on both
operands and then a set of rules is used to determine the common type.
For integer types it is usually simply the widest of the two, even if
that is an unsigned type and the other is a signed type.

"default argument promotions" apply to function calls in the absence of
a prototype.  These are the integer promotions augmented by a conversion
of float to double.

The standard never refers to a conversion as a cast (a cast is an
operator that performs an explicit conversion) and it uses the term
"promotion" only in the context of the implicit conversions described
above.  A conversion of one type to a wider one in some other context is
not called a promotion.

> If you multiply two 8 bit unsigned char values, is the product 
> modulo 256? I don't think so.

No, it's not.

<snip>
> Now it gets interesting. When were the int_32_t and int_16_t added to
> C?

1999.  The types are intN_t and uintN_t (no extra _) for various N.
They are optional, but must be defined if the implementation has
suitable types (basically 2's complement and no padding bits).  Other,
similar, types like int_leastN_t and int_fastN_t are required in all
implementations.  For example, int_least32_t is the smallest type that
has at least 32 (value) bits.

> Seems to me that compilers only claiming a version of the standard
> before they were added wouldn't have to use the same rules.

True.

> Consider that a compiler might have a int_128_t that it could add and
> subtract, but not multiply or divide. Maybe it can generate a 128 bit
> product from two 64 bit operands. Does the standard prohibit a 
> compiler from offering those operations?

I don't think it could define int128_t unless it could multiply them.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28774

In comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

(snip, I wrote)

>> If you multiply two 8 bit unsigned char values, is the product 
>> modulo 256? I don't think so.
 
> No, it's not.

For comparison purposes, I believe that Fortran does not have this rule.

If you add, subtract, multiply, or (I believe) divide 8 bit integers
the result is, generally, eight bits. One should, at least, not be
surprised if the result is computed modulo some small value.

I like the C rules better.

PL/I generally tries to keep the bits until it reaches the
implementation maximum. That is complicated when scaled fixed
point (non-integer) values are used, where it keeps the appropriate
digits (binary or decimal) to the right of the radix point, 
possibly truncating on the left.

-- glen

[toc] | [prev] | [next] | [standalone]

#28779

On 29/11/2012 03:31, glen herrmannsfeldt wrote:
> In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote:
>
> (snip, someone wrote)
>>>> I would expect that gcc would be ANSI compliant, and would therefore
>>>> promote both 16-bit integers to 32-bit before doing the multiply.
>
> (snip, then I wrote)
>>> Maybe I am missing something here, but are there versions of gcc for 16
>>> bit processors, with 16 bit int? If so, then promotion to int won't
>>> promote to 32 bits without a cast.
>
>> The correct behaviour for C standards compliance is that when you
>> multiply two operands of different int size, the smaller one is promoted
>> to the size of the larger one.  Then the multiply is carried out modulo
>> the size of the larger one.  Then the result is truncated or extended as
>> needed to fit the target variable.
>
> I haven't read the standard so recently, but I thought that was only
> after the default promotions. Values smaller than int would be promoted
> to int, then the size of the multiply (and product) determined.

As pointed out by Hans-Bernhard, you are correct here.  I'm sorry for 
causing confusion by posting while half asleep.

Default "int" promotions are done first for each operand.  They are 
promoted to "signed int", "unsigned int", "signed long int" or "unsigned 
long int" (and "long long" for newer C standards), stopping at the first 
type that covers the entire range.  In practice, this means anything 
smaller than an "int" will get promoted to a "signed int".

>
> If you multiply two 8 bit unsigned char values, is the product
> modulo 256? I don't think so.
>
>> So the bit-size of the processor, and the bit-size of "int" on that
>> particular target, is irrelevant.  And the size of the result variable
>> is also irrelevant (this catches out some newbies).
>
>> Given:
>
>> int16_t a, b;
>> int32_t c
>
>> c = (int32_t)a * b;
>
>> Then b is cast to int32_t, the 32-bit multiplication is carried out, and
>> the result assigned to c.
>
> Maybe not completely irrelevent, consider a system with a 64 bit int.
>
>> If you write just "c = a * b", then the multiplication is carried it at
>> 16-bit, then promoted to 32-bit.  This applies regardless of the
>> bit-size of the target - you will get the same effect on a 64-bit cpu as
>> on the 8-bit AVR.
>
> Regardless of the target size, but not of int size.
>
>> If your compiler does 16-bit multiplications when you have "c =
>> (int32_t) a * b", and requires two "int32_t" casts to do 32-bit
>> multiplication, then your compiler is very badly broken.  As Tim says,
>> badly broken compilers /do/ exist, so if you have to use them, then you
>> need to use two casts.  But I personally don't think you need to write
>> your code to work with broken toolchains unless you actually have to.
>
> Now it gets interesting. When were the int_32_t and int_16_t added to C?
>

The types were officially added with C99, but they existed in practice 
before that as "long int" and "short int" on most compilers (some 
targets don't support 16-bit types, and thus have "short int" as 32-bit 
and no int16_t.  And the standards allow compilers with a "short" of 
64-bit or more, in which case neither "int32_t" nor "int16_t" would 
exist - but I have never heard of such a beast).

> Seems to me that compilers only claiming a version of the standard
> before they were added wouldn't have to use the same rules.

The rules haven't changed (again, sorry for my mistaken post).  Types 
such as "int32_t" are just typedef's for "normal" C types.

>
> Consider that a compiler might have a int_128_t that it could add and
> subtract, but not multiply or divide. Maybe it can generate a 128 bit
> product from two 64 bit operands. Does the standard prohibit a
> compiler from offering those operations?
>

The "int128_t" here is either a typedef for an existing C type (which 
could include "long long int" in C99), in which case it would have to 
support all integral operations, or it is purely a compiler extension, 
in which case it is non-standard.  But I believe the standards say that 
/if/ a type of this form "int128_t" is defined in standard headers for 
the compiler, then it must act as a full integral type of that size.

[toc] | [prev] | [next] | [standalone]

#28785

In comp.lang.c David Brown <david@westcontrol.removethisbit.com> wrote:

(snip)
>> Now it gets interesting. When were the int_32_t and int_16_t added to C?

> The types were officially added with C99, but they existed in practice 
> before that as "long int" and "short int" on most compilers (some 
> targets don't support 16-bit types, and thus have "short int" as 32-bit 
> and no int16_t.  And the standards allow compilers with a "short" of 
> 64-bit or more, in which case neither "int32_t" nor "int16_t" would 
> exist - but I have never heard of such a beast).
 
>> Seems to me that compilers only claiming a version of the standard
>> before they were added wouldn't have to use the same rules.
 
> The rules haven't changed (again, sorry for my mistaken post).  Types 
> such as "int32_t" are just typedef's for "normal" C types.

Most likely, but as they aren't in the C89 standard, unless the
user typedef's them, seems to me the compiler is free to implement
then in any way desired.

-- glen

[toc] | [prev] | [next] | [standalone]

#28789

On 29/11/2012 12:31, glen herrmannsfeldt wrote:
> In comp.lang.c David Brown <david@westcontrol.removethisbit.com> wrote:
>
> (snip)
>>> Now it gets interesting. When were the int_32_t and int_16_t added to C?
>
>> The types were officially added with C99, but they existed in practice
>> before that as "long int" and "short int" on most compilers (some
>> targets don't support 16-bit types, and thus have "short int" as 32-bit
>> and no int16_t.  And the standards allow compilers with a "short" of
>> 64-bit or more, in which case neither "int32_t" nor "int16_t" would
>> exist - but I have never heard of such a beast).
>
>>> Seems to me that compilers only claiming a version of the standard
>>> before they were added wouldn't have to use the same rules.
>
>> The rules haven't changed (again, sorry for my mistaken post).  Types
>> such as "int32_t" are just typedef's for "normal" C types.
>
> Most likely, but as they aren't in the C89 standard, unless the
> user typedef's them, seems to me the compiler is free to implement
> then in any way desired.
>

That is correct - but I would be very surprised to see a compiler that 
did have a type with a name like that, and did not implement it the 
obvious way.  It might be /legal/ under C89 rules for the compiler to 
have a type called "int32_t" with different behaviour, but I can't 
imagine it actually being the case.  I'm sure Tim Wescott can think of 
an exception, however!

[toc] | [prev] | [next] | [standalone]

#28788

On 29.11.2012 09:37, David Brown wrote:
> On 29/11/2012 03:31, glen herrmannsfeldt wrote:

>> Consider that a compiler might have a int_128_t that it could add and
>> subtract, but not multiply or divide. Maybe it can generate a 128 bit
>> product from two 64 bit operands. Does the standard prohibit a
>> compiler from offering those operations?

> The "int128_t" here is either a typedef for an existing C type (which
> could include "long long int" in C99), in which case it would have to
> support all integral operations, or it is purely a compiler extension,
> in which case it is non-standard.

Since we were nit-picking anyway: not quite.  As of C99 the standard 
explicitly foresees the possible need to have more than the usual 10 
different integer types ({signed|unsigned} {char|short|int|long|long 
long}) in a target.  That's why they included a provision for "extended 
integer types".  These types don't have standardized names (because they 
can't), but their behaviour is still covered by the standard.

So the type behind int128_t need not be an "existing C type" (as in: 
something that was already defined before), nor is it allowed to be a 
pure compiler extension (which the standard would have no say over at 
all).  If it's an extension, it has to be a standard extension, so its 
behaviour is ruled by the standard.

 > But I believe the standards say that
> /if/ a type of this form "int128_t" is defined in standard headers for
> the compiler, then it must act as a full integral type of that size.

Yes.

[toc] | [prev] | [next] | [standalone]

#28794

Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
<snip>
> Since we were nit-picking anyway: not quite.  As of C99 the standard
> explicitly foresees the possible need to have more than the usual 10
> different integer types ({signed|unsigned} {char|short|int|long|long
> long}) in a target.

These may be the usual ones, but there are 11 "standard integer types"
because they include _Bool.  (Well, you did say we are nit-picking!)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28815

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
> <snip>
>> Since we were nit-picking anyway: not quite.  As of C99 the standard
>> explicitly foresees the possible need to have more than the usual 10
>> different integer types ({signed|unsigned} {char|short|int|long|long
>> long}) in a target.
>
> These may be the usual ones, but there are 11 "standard integer types"
> because they include _Bool.  (Well, you did say we are nit-picking!)

And plain char *isn't* one of the "standard integer types", even
though it's a standard type, and it's an integer type, and its
characteristics (range, representation, and behavior) are identical
either to those of signed char or to those of unsigned char, both
of which are "standard integer types".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#28793

David Brown <david@westcontrol.removethisbit.com> writes:

> On 29/11/2012 03:31, glen herrmannsfeldt wrote:
>> In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote:
>>
>> (snip, someone wrote)
>>>>> I would expect that gcc would be ANSI compliant, and would therefore
>>>>> promote both 16-bit integers to 32-bit before doing the multiply.
>>
>> (snip, then I wrote)
>>>> Maybe I am missing something here, but are there versions of gcc for 16
>>>> bit processors, with 16 bit int? If so, then promotion to int won't
>>>> promote to 32 bits without a cast.
>>
>>> The correct behaviour for C standards compliance is that when you
>>> multiply two operands of different int size, the smaller one is promoted
>>> to the size of the larger one.  Then the multiply is carried out modulo
>>> the size of the larger one.  Then the result is truncated or extended as
>>> needed to fit the target variable.
>>
>> I haven't read the standard so recently, but I thought that was only
>> after the default promotions. Values smaller than int would be promoted
>> to int, then the size of the multiply (and product) determined.
>
> As pointed out by Hans-Bernhard, you are correct here.  I'm sorry for
> causing confusion by posting while half asleep.
>
> Default "int" promotions are done first for each operand.  They are
> promoted to "signed int", "unsigned int", "signed long int" or
> "unsigned long int" (and "long long" for newer C standards), stopping
> at the first type that covers the entire range.  In practice, this
> means anything smaller than an "int" will get promoted to a "signed
> int".

That's not quite right, though I'm not exactly sure what you mean.  As
you say, the integer promotions are done first.  That can produce either
an int or an unsigned int, or it may have no effect at all if the type
is already "bigger" than an int.  Then one operand, but sometimes both
operands, are further converted (not promoted) to get a common type.
You can read the rules at

 www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (sec. 6.3.1.8)

but the conversion does not stop at the first type that covers the
entire range (at least according to how I interpret that phrase).  For
example, in (unsigned)1 * (signed)-1 the signed operand is converted to
the type of the unsigned one even though that type can't cover the
entire range of the operand or operands.

Almost any summary of the rules is going to be wrong; if an accurate
summary can be written it should go into the language standard -- it
would be a great boon -- but I don't think that's possible.  For example
I had to put "bigger" in quotes because the rule is based on a technical
term called the conversion rank of the type and not on its size.  (The
integer promotions have no effect on a long int even on systems where a
long int is no bigger than an int).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28797

On 11/29/2012 03:37 AM, David Brown wrote:
...
> Default "int" promotions are done first for each operand.  They are 
> promoted to "signed int", "unsigned int", "signed long int" or "unsigned 
> long int" (and "long long" for newer C standards), stopping at the first 
> type that covers the entire range.  In practice, this means anything 
> smaller than an "int" will get promoted to a "signed int".

Not quite. The integer conversions never change anything to any type
other than 'int' or 'unsigned int'.

"If an int can represent all values of the original type (as restricted
by the width, for a bit-field), the value is converted to an int;
otherwise, it is converted to an unsigned int. These are called the
integer promotions.58) All other types are unchanged by the integer
promotions." (6.3.1.1p2) The first use of "integer promotions" in that
clause is italicized, which is an ISO convention indicating that the
sentence containing that phrase serves as the definition of the phrase.

..
>> Now it gets interesting. When were the int_32_t and int_16_t added to C?
>>
> 
> The types were officially added with C99, but they existed in practice 
> before that as "long int" and "short int" on most compilers (some 
> targets don't support 16-bit types, and thus have "short int" as 32-bit 
> and no int16_t.  And the standards allow compilers with a "short" of 
> 64-bit or more, in which case neither "int32_t" nor "int16_t" would 
> exist - but I have never heard of such a beast).

I've heard of machines with 32-bit short, but not 64-bit. Note that
while int32_t and int16_t could not be provided by <stdint.h> for such a
compiler, int_least32_t and int_fast32_t (and similarly for 16) must be.

>> Seems to me that compilers only claiming a version of the standard
>> before they were added wouldn't have to use the same rules.
> 
> The rules haven't changed (again, sorry for my mistaken post). ...

Yes they have. In C99 and later, <stdint.h> and <inttypes.h> are
standard headers, and if #included, the identifiers they define must
meet certain well-specified requirements. In C90, there were no such
standard headers, no guarantees on what a header file with that name
would contain if you successfully #included it, and no corresponding
restrictions on how user code could use those identifiers after
#including those header files.

> ... Types
> such as "int32_t" are just typedef's for "normal" C types.

That depends upon what you mean by 'normal'. The C99 standard
distinguishes between standard and extended integer types. The standard
integer types have names specified by the C standard; extended types are
implementation-defined, and may have other names. There are many
standard typedefs that are required to have either arithmetic or integer
type; but there are none that are restricted to standard integer types.
Would you consider __extended_integer_type to be a "normal" C type?

...
> The "int128_t" here is either a typedef for an existing C type (which 
> could include "long long int" in C99), in which case it would have to 
> support all integral operations, or it is purely a compiler extension, 
> in which case it is non-standard.

No, supporting int128_t would not be a non-standard extension, it's just
providing an optional feature of standard C. The key difference is that
if an implementation chooses to support an optional feature, it must
support it in precisely the manner specified by the standard for that
feature; extensions give an implementation a lot more freedom. In C2011,
there's a lot of optional features.

The only size-named types that a conforming implementation of <stdint.h>
must provide are [u]int_leastN_t, and [u]int_fastN_t for N = 8, 16, 32,
and 64. For all other values of N, and for [u]intN_t for all values of
N, the typedefs are optional. You can determine precisely which of the
optional <stdint.h> types are supported by #ifdef of the corresponding
*_MAX macro. If that macro is #defined, you can use the corresponding
type in full confidence that it behaves precisely as specified by the
standard.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28798

On 11/29/2012 09:07 AM, James Kuyper wrote:
...
> "If an int can represent all values of the original type (as restricted
> by the width, for a bit-field), the value is converted to an int;
> otherwise, it is converted to an unsigned int. These are called the
> integer promotions.58) All other types are unchanged by the integer
> promotions." (6.3.1.1p2) The first use of "integer promotions" in that
> clause is italicized, which is an ISO convention indicating that the
> sentence containing that phrase serves as the definition of the phrase.

I just realized that the meaning of the phrase "All other types" is not
clear without the preceding part of that clause which I snipped:

> The following may be used in an expression wherever an int or unsigned int may
> be used:
> — An object or expression with an integer type (other than int or unsigned int)
> whose integer conversion rank is less than or equal to the rank of int and
> unsigned int.
> — A bit-field of type _Bool, int, signed int, or unsigned int.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28833

James Kuyper wrote:
> 
> On 11/29/2012 09:07 AM, James Kuyper wrote:
> ...
> > "If an int can represent all values of the original type
> > (as restricted
> > by the width, for a bit-field), the value is converted to an int;
> > otherwise, it is converted to an unsigned int. These are called the
> > integer promotions.58) All other types are unchanged by the integer
> > promotions."
> > (6.3.1.1p2) The first use of "integer promotions" in that
> > clause is italicized, which is an ISO convention indicating
> > that the
> > sentence containing that phrase serves
> > as the definition of the phrase.
> 
> I just realized that the meaning of the phrase "All other types"
> is not
> clear without the preceding part of that clause which I snipped:
> 
> > The following may be used in an expression
> > wherever an int or unsigned int may
> > be used:
> > — An object or expression with an integer type
> > (other than int or unsigned int)
> > whose integer conversion rank is less than
> > or equal to the rank of int and unsigned int.
> > —
> > A bit-field of type _Bool, int, signed int, or unsigned int.

I recall reading some posts in this newsgroup a long time ago,
which claimed that under certain circumstances,
that it was possible in C99,
for unsigned int to promote to type signed int.

But that was never the case. 

In C99
6.3.1.1 paragraph 2, read as "less than"
instead of "less than or equal" as you have above;
and unsigned int type was covered by "All other types"
in the last sentence.


-- 
pete

[toc] | [prev] | [next] | [standalone]

#28837

On 11/29/2012 06:25 PM, pete wrote:
> James Kuyper wrote:
>>
>> On 11/29/2012 09:07 AM, James Kuyper wrote:
>> ...
>>> "If an int can represent all values of the original type
>>> (as restricted
>>> by the width, for a bit-field), the value is converted to an int;
>>> otherwise, it is converted to an unsigned int. These are called the
>>> integer promotions.58) All other types are unchanged by the integer
>>> promotions."
>>> (6.3.1.1p2) The first use of "integer promotions" in that
>>> clause is italicized, which is an ISO convention indicating
>>> that the
>>> sentence containing that phrase serves
>>> as the definition of the phrase.
>>
>> I just realized that the meaning of the phrase "All other types"
>> is not
>> clear without the preceding part of that clause which I snipped:
>>
>>> The following may be used in an expression
>>> wherever an int or unsigned int may
>>> be used:
>>> — An object or expression with an integer type
>>> (other than int or unsigned int)
>>> whose integer conversion rank is less than
>>> or equal to the rank of int and unsigned int.
>>> —
>>> A bit-field of type _Bool, int, signed int, or unsigned int.
> 
> I recall reading some posts in this newsgroup a long time ago,
> which claimed that under certain circumstances,
> that it was possible in C99,
> for unsigned int to promote to type signed int.

An unsigned type whose entire range can be represented by an int will
promote to signed int, as can easily be confirmed by checking the above
text, and that point has been raised in this group - there were several
threads that touched on that subject in just this past summer. However,
 anyone who claimed that it could happen to "unsigned int" was mistaken.
That clause explicitly applies only to types "other than int or unsigned
int".

> But that was never the case. 
> 
> In C99
> 6.3.1.1 paragraph 2, read as "less than"
> instead of "less than or equal" as you have above;
> and unsigned int type was covered by "All other types"
> in the last sentence.

n1256.pdf (which is C99 with all three TCs applied, making it MORE
useful than C99 itself) and n1570.pdf (which is essentially identical to
C2011) both have "less than or equal to". The line is marked as being
changed from C99 in n1256.pdf, implying that one of the TCs is the
reason. My copy of C99 itself is inaccessible right now, so I can't
confirm the nature of the change.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28855

James Kuyper <jameskuyper@verizon.net> wrote:
> 
> n1256.pdf (which is C99 with all three TCs applied, making it MORE
> useful than C99 itself) and n1570.pdf (which is essentially identical to
> C2011) both have "less than or equal to". The line is marked as being
> changed from C99 in n1256.pdf, implying that one of the TCs is the
> reason. My copy of C99 itself is inaccessible right now, so I can't
> confirm the nature of the change.

It was TC2 and the change came from DR 230. It was to handle the case of
enumerationed types with the same rank as int, it didn't have anything
to do with unsigned int.
-- 
Larry Jones

I'm a genius. -- Calvin

[toc] | [prev] | [next] | [standalone]

#29396

pete <pfiland@mindspring.com> writes:

> James Kuyper wrote:
>> 
>> On 11/29/2012 09:07 AM, James Kuyper wrote:
>> ...
>> > "If an int can represent all values of the original type
>> > (as restricted
>> > by the width, for a bit-field), the value is converted to an int;
>> > otherwise, it is converted to an unsigned int. These are called the
>> > integer promotions.58) All other types are unchanged by the integer
>> > promotions."
>> > (6.3.1.1p2) The first use of "integer promotions" in that
>> > clause is italicized, which is an ISO convention indicating
>> > that the
>> > sentence containing that phrase serves
>> > as the definition of the phrase.
>> 
>> I just realized that the meaning of the phrase "All other types"
>> is not
>> clear without the preceding part of that clause which I snipped:
>> 
>> > The following may be used in an expression
>> > wherever an int or unsigned int may
>> > be used:
>> >  '' An object or expression with an integer type
>> > (other than int or unsigned int)
>> > whose integer conversion rank is less than
>> > or equal to the rank of int and unsigned int.
>> > ''
>> > A bit-field of type _Bool, int, signed int, or unsigned int.
>
> I recall reading some posts in this newsgroup a long time ago,
> which claimed that under certain circumstances,
> that it was possible in C99,
> for unsigned int to promote to type signed int.
>
> But that was never the case. 

Actually it was.

> In C99
> 6.3.1.1 paragraph 2, read as "less than"
> instead of "less than or equal" as you have above;
> and unsigned int type was covered by "All other types"
> in the last sentence.

Yes but it was changed by a TC (still counts as part of C99
even though the TC didn't issue until later).  Look at N1256.

In fairness I should add that it was an unintended consequence.
Still, the official text was changed so that unsigned int
could 'promote' to int under some circumstances, and that
was true for much or most of the time C99 was in force.

[toc] | [prev] | [next] | [standalone]

#28818

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> I've heard of machines with 32-bit short, but not 64-bit. Note that
> while int32_t and int16_t could not be provided by <stdint.h> for such a
> compiler, int_least32_t and int_fast32_t (and similarly for 16) must be.

Trivia: I've used a machine (Cray T90) with 8-bit char and 64-bit short,
int, long, and long long.  It had no 16-bit or 32-bit integer types.

[...]

> That depends upon what you mean by 'normal'. The C99 standard
> distinguishes between standard and extended integer types. The standard
> integer types have names specified by the C standard; extended types are
> implementation-defined, and may have other names.

They *must* have other names.

Normally such names would be identifiers reserved to the
implementation, starting with an underscore and either another
underscore or an uppercase letter.  (Though I suppose an
implementation that supports other forms of identifiers as a
language extension could use them; for example some compiler permit
identifiers with '$' characters.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#28822

On 11/29/2012 02:38 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> That depends upon what you mean by 'normal'. The C99 standard
>> distinguishes between standard and extended integer types. The standard
>> integer types have names specified by the C standard; extended types are
>> implementation-defined, and may have other names.
> 
> They *must* have other names.

Not if there aren't any. :-) I should have worded that differently.
They're not required to exist, but if they do, you're right - they must
have other names.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28757

On 2012-11-28, Tim Wescott <tim@seemywebsite.com> wrote:
> On Wed, 28 Nov 2012 18:05:06 +0000, Grant Edwards wrote:

>>> And you have to be careful about how/when any expansions occur.  For
>>> example with gcc-avr, if you want
>>>
>>>     int32_t = int16_t * int16_t
>>>
>>> (the full 32 bit result of a 16x16 bit multiply), you have to cast each
>>> of the 16-bit operands to 32bits.
>> 
>> Shouldn't casting just one of the 16 bit values work the same as casting
>> both of them?
>
> Yes.  But that's if you take "should" as indicating a moral direction, 
> rather than as an indication of what you can reasonably expect from every 
> tool chain.
>
> I would expect that gcc would be ANSI compliant, and would therefore 
> promote both 16-bit integers to 32-bit before doing the multiply.

Nope.  On the target in question (AVR), an "int" is 16 bits (at least
by default).  Same for msp430 (and maybe for some of the H8 targets).
I think there is a command-line option for some 16-bit targets to tell
gcc to use 32-bit representations for "int" instead of the defautl 16
bits.

> But I've worked with compilers in the past that didn't do this, so
> when writing code that may be used in multiple places, I up-cast the
> same way one votes in Chicago: early and often.

If, like AVR and msp430, an "int" is 16 bits, then you must cast at
least one of the two operands to a 32 bit integer type if you want a
16x16=>32 multiply.

-- 
Grant Edwards               grant.b.edwards        Yow! Mr and Mrs PED, can I
                                  at               borrow 26.7% of the RAYON
                              gmail.com            TEXTILE production of the
                                                   INDONESIAN archipelago?

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web