Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #28629 > unrolled thread
| Started by | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| First post | 2012-11-25 04:18 +0700 |
| Last post | 2012-11-27 10:21 +0100 |
| Articles | 20 on this page of 87 — 26 participants |
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.
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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 17:32 -0600 |
| Message-ID | <JaGdnWGCkdFvAyvNnZ2dnUVZ_oOdnZ2d@web-ster.com> |
| In reply to | #28757 |
On Wed, 28 Nov 2012 22:26:20 +0000, Grant Edwards wrote: > 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. You mean "Absolutely", not "Nope". At least you do if you're referring to a 16-bit int as being conformant to ANSI C. Per ANSI C99 (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), page 34, the minimum allowable value of INT_MAX is 32767. That fits nicely inside a 16-bit signed number. >> 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. Yes. And if you're using a broken, not-quite-compliant compiler that needs to see _both_ numbers as 32-bit before it'll do a 32-bit operation, then you need to cast _both_. (I'm pretty sure it was Intel's C compiler for the '196). -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-28 19:02 -0500 |
| Message-ID | <50B6A618.5000708@verizon.net> |
| In reply to | #28759 |
On 11/28/2012 06:32 PM, Tim Wescott wrote: > On Wed, 28 Nov 2012 22:26:20 +0000, Grant Edwards wrote: > >> On 2012-11-28, Tim Wescott <tim@seemywebsite.com> 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. >> >> 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. > > You mean "Absolutely", not "Nope". At least you do if you're referring > to a 16-bit int as being conformant to ANSI C. > > Per ANSI C99 (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), > page 34, the minimum allowable value of INT_MAX is 32767. That fits > nicely inside a 16-bit signed number. I'm not sure the point you're making here. The type resulting from integer promotions is always either an 'int' or an 'unsigned int', and they occur only for values of other integer types whose entire range can be represented in the promoted type. Therefore, if int is 16 bits, int16_t operands will not be promoted at all, much less promoted to a 32-bit int, in conflict with what you said you expected of an ANSI compliant compiler. That's what his "Nope" was referring to. On such a platform, the usual arithmetic conversions will cause one of the operands to be converted implicitly to a 32-bit int if the other one is explicitly converted to a 32-bit int. However, section 6.3.1.1p2 defines what an "integer promotion" is, and that definition doesn't include those conversions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 18:29 -0600 |
| Message-ID | <JaGdnWCCkdHNMSvNnZ2dnUVZ_oOdnZ2d@web-ster.com> |
| In reply to | #28760 |
On Wed, 28 Nov 2012 19:02:32 -0500, James Kuyper wrote: > On 11/28/2012 06:32 PM, Tim Wescott wrote: >> On Wed, 28 Nov 2012 22:26:20 +0000, Grant Edwards wrote: >> >>> On 2012-11-28, Tim Wescott <tim@seemywebsite.com> 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. >>> >>> 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. >> >> You mean "Absolutely", not "Nope". At least you do if you're referring >> to a 16-bit int as being conformant to ANSI C. >> >> Per ANSI C99 >> (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), page 34, >> the minimum allowable value of INT_MAX is 32767. That fits nicely >> inside a 16-bit signed number. > > I'm not sure the point you're making here. The type resulting from > integer promotions is always either an 'int' or an 'unsigned int', and > they occur only for values of other integer types whose entire range can > be represented in the promoted type. Therefore, if int is 16 bits, > int16_t operands will not be promoted at all, much less promoted to a > 32-bit int, in conflict with what you said you expected of an ANSI > compliant compiler. That's what his "Nope" was referring to. > > On such a platform, the usual arithmetic conversions will cause one of > the operands to be converted implicitly to a 32-bit int if the other one > is explicitly converted to a 32-bit int. However, section 6.3.1.1p2 > defines what an "integer promotion" is, and that definition doesn't > include those conversions. 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. So I disagreed with (e), and pointed out where in the ANSI specification type 'int' is, indeed, allowed to be 16 bit (and 1's compliment or sign- magnitude, if you've got a perverse processor). 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). You are correct that statement (0) is not true, however you are not correct in thinking that it was said. I assume that you inferred it because you did not pick up the context that Grant trimmed out. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-28 23:39 -0500 |
| Message-ID | <k96ouq$int$1@dont-email.me> |
| In reply to | #28761 |
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
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.please> |
|---|---|
| Date | 2012-11-29 00:59 -0600 |
| Message-ID | <0Y2dnZjJaut9mirNnZ2dnUVZ_uydnZ2d@web-ster.com> |
| In reply to | #28775 |
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? >> 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. 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. Missing the context the first time is understandable -- that statement came about after two previous postings, and you do have to follow the conversation. But I have just told you to READ THE CONTEXT. So where do you get off with repeating a statement of mine, out of context, which YOU'VE DAMNED WELL BEEN TOLD is misleading when taken out of context, then criticizing that false meaning of it? That's shooting straight through "rude" and getting right into "dishonest". -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 07:57 -0500 |
| Message-ID | <k97m4e$or0$1@dont-email.me> |
| In reply to | #28777 |
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
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-29 13:02 -0600 |
| Message-ID | <0fKdnVP5BJfELCrNnZ2dnUVZ_vGdnZ2d@web-ster.com> |
| In reply to | #28791 |
On Thu, 29 Nov 2012 07:57:48 -0500, James Kuyper wrote: > 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. Well, I thought we were talking useful people writing good code using C. Useful people who want to write good code using C don't always use correct "standardese", but they do know how to read all the pertinent documentation. Had you gone back and read said pertinent documentation you would have done a "useful people" sort of thing, and realized what _my_ point was about, regardless of any misuse of terminology on my part. But hey -- I'm just a guy who designs embedded systems that actually make money for my customers. One of the skills that requires is listening to people and not trying to slam them for violating some trivial rule of terminology when they're getting the gist of their statements right. >>> 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. I believe that you need to spend some time with engineers who actually design product. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-29 15:19 +0000 |
| Message-ID | <k97udh$jpg$2@reader1.panix.com> |
| In reply to | #28777 |
On 2012-11-29, Tim Wescott <tim@seemywebsite.please> 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 ...
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2012-11-29 12:03 +0200 |
| Message-ID | <87vccoohdq.fsf@bazspaz.fatphil.org> |
| In reply to | #28775 |
James Kuyper <jameskuyper@verizon.net> 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 /.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-29 11:39 +0000 |
| Message-ID | <k97hh3$rf0$1@speranza.aioe.org> |
| In reply to | #28783 |
In comp.lang.c Phil Carmody <thefatphil_demunged@yahoo.co.uk> 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
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 08:04 -0500 |
| Message-ID | <k97mhk$rci$1@dont-email.me> |
| In reply to | #28783 |
On 11/29/2012 05:03 AM, Phil Carmody wrote: > James Kuyper <jameskuyper@verizon.net> 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
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-29 15:17 +0000 |
| Message-ID | <k97ub6$jpg$1@reader1.panix.com> |
| In reply to | #28761 |
On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 19:19 -0600 |
| Message-ID | <JaGdnWOCkdGuJSvNnZ2dnUVZ_oOdnZ2d@web-ster.com> |
| In reply to | #28741 |
On Wed, 28 Nov 2012 12:56:37 -0600, Tim Wescott wrote: > On Wed, 28 Nov 2012 18:05:06 +0000, Grant Edwards wrote: > >> On 2012-11-28, Frank Miles <fpm@u.washington.edu> wrote: >>> >>>> Generally, the result is as wide as the widest of the operands, >>>> or "int", if no operand is wider than "int". The result then may >>>> be truncated on function application or assignment. (For >>>> instance, i += j is 0 if i is 1, j is 255, and both are declared >>>> to be of the 8-bit unsigned integer uint8_t type.) >>>> >>>> >>> 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. 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. 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_". The primary intent of my comment above was to point out that while an ANSI C compliant compiler will convert both operands to and the result to 32-bits if you cast just one operand to 32 bits, there are compilers out there that won't. I did not mean to say -- and indeed it is not the case -- that a compiler with 16-bit integers will automatically promote them to 32 bits just because you want them to, or even just because the result is getting stuck into a 32-bit number. For a nice ANSI-C compliant compiler you only have to tell it once (by casting one of the operands). For at least one compiler that I have used in the past, you had to tell it so over and over again (by casting everything to 32 bits, oh joy). -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-28 23:44 -0500 |
| Message-ID | <k96p6h$int$2@dont-email.me> |
| In reply to | #28765 |
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
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-28 13:15 -0500 |
| Message-ID | <50B654CB.20403@verizon.net> |
| In reply to | #28735 |
On 11/28/2012 12:53 PM, Frank Miles 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. I'm not familiar with gcc-avr. That constitutes a significant deviation from standard C, where casting either operand would be sufficient to guarantee implicit conversion of the other operand, in accordance with the "usual arithmetic conversions". What is the reason for this difference?
[toc] | [prev] | [next] | [standalone]
| From | Arlet Ottens <usenet+5@c-scape.nl> |
|---|---|
| Date | 2012-11-28 19:17 +0100 |
| Message-ID | <50b6552e$0$6868$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #28737 |
On 11/28/2012 07:15 PM, James Kuyper wrote: > On 11/28/2012 12:53 PM, Frank Miles 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. > > I'm not familiar with gcc-avr. That constitutes a significant deviation > from standard C, where casting either operand would be sufficient to > guarantee implicit conversion of the other operand, in accordance with > the "usual arithmetic conversions". What is the reason for this difference? There's no difference. For gcc-avr it also suffices to cast just one operand.
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 19:30 -0600 |
| Message-ID | <JaGdnWKCkdElJyvNnZ2dnUVZ_oOXnZ2d@web-ster.com> |
| In reply to | #28738 |
On Wed, 28 Nov 2012 19:17:18 +0100, Arlet Ottens wrote: > On 11/28/2012 07:15 PM, James Kuyper wrote: >> On 11/28/2012 12:53 PM, Frank Miles 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. >> >> I'm not familiar with gcc-avr. That constitutes a significant deviation >> from standard C, where casting either operand would be sufficient to >> guarantee implicit conversion of the other operand, in accordance with >> the "usual arithmetic conversions". What is the reason for this >> difference? > > There's no difference. For gcc-avr it also suffices to cast just one > operand. 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. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-29 15:29 +0000 |
| Message-ID | <k97v17$jpg$4@reader1.panix.com> |
| In reply to | #28766 |
On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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?
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2012-11-29 16:36 +0000 |
| Message-ID | <87boegicx9.fsf@devereux.me.uk> |
| In reply to | #28803 |
Grant Edwards <invalid@invalid.invalid> writes: > On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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. Other problem with it is the separate program and data memory spaces. Fine for small deeply embedded things but started to show strain when I wanted a LCD display, menus etc. I would not use it for a new project unless there was a very good reason, ultra-low power perhaps. Cortex M3 is much nicer but the chips are much more complicated of course. -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2012-11-29 22:40 +0200 |
| Message-ID | <v8hfb8p4eppqeqe52rr3ngemub6jcsd1ao@4ax.com> |
| In reply to | #28806 |
On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux <john@devereux.me.uk> wrote: >Grant Edwards <invalid@invalid.invalid> writes: > >> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> 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. > >Other problem with it is the separate program and data memory >spaces. Fine for small deeply embedded things but started to show strain >when I wanted a LCD display, menus etc. I would not use it for a new >project unless there was a very good reason, ultra-low power >perhaps. Cortex M3 is much nicer but the chips are much more complicated >of course. Except for self modifying code, why would one want data (program) access into program space (unless you are writing a linker or debugger) ?? While working with PDP-11's in the 1970's, the ability to use separate I/D (Instruction/Data) space helped a lot to keep code/data in private 64 KiD address spaces.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web