Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #10572 > unrolled thread
| Started by | Robert Roland <fake@ddress.no> |
|---|---|
| First post | 2012-11-24 17:41 +0100 |
| Last post | 2012-11-26 00:08 +0000 |
| Articles | 20 on this page of 153 — 47 participants |
Back to article view | Back to comp.arch.embedded
Getting started with AVR and C Robert Roland <fake@ddress.no> - 2012-11-24 17:41 +0100
Re: Getting started with AVR and C hamilton <hamilton@nothere.com> - 2012-11-24 09:55 -0700
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 10:39 +0100
Re: Getting started with AVR and C Rene <a@b.c> - 2012-11-24 18:03 +0100
Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-10 13:21 +0100
Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-12-10 18:33 -0800
Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-11 12:34 +0100
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-24 12:44 -0600
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:12 -0800
Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-24 11:28 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:42 -0800
Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-25 07:01 -0800
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 20:14 +0100
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 03:18 +0700
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
Re: Getting started with AVR and C Dave Nadler <drn@nadler.com> - 2012-11-24 21:01 -0800
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 me@linnix.info-for.us - 2012-11-30 09:26 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 13:22 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 14:10 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:16 -0800
Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-11-30 17:36 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:18 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 10:08 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 00:45 -0800
Re: Getting started with AVR and C Ed Beroset <beroset@mindspring.com> - 2012-12-01 08:00 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 13:22 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-01 17:33 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 17:43 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-02 14:13 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-04 20:34 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-04 18:25 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 07:55 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:11 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-05 07:52 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 11:02 -0500
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 21:28 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:21 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:05 +0200
Re: Getting started with AVR and C Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2012-12-05 23:22 +0200
Re: Getting started with AVR and C Niklas Holsti <niklas.holsti@tidorum.invalid> - 2012-12-06 00:00 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:17 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:10 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-06 07:15 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 21:52 -0800
Re: Getting started with AVR and C Lanarcam <lanarcam1@yahoo.fr> - 2012-12-06 20:59 +0100
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-06 12:38 -0800
Re: Getting started with AVR and C George Neuner <gneuner2@comcast.net> - 2012-12-06 20:39 -0500
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 22:31 -0500
Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-12-05 16:32 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-05 17:04 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 22:01 -0800
Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-12-06 14:05 +0000
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-06 10:28 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 16:58 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 07:34 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 10:55 -0500
Re: Getting started with AVR and C Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-06 11:11 -0500
Re: Getting started with AVR and C Rocky <RobertGush@gmail.com> - 2012-12-06 21:38 -0800
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-07 03:49 -0800
Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 02:58 -0600
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 17:28 +0200
Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 11:55 -0600
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 Christopher Head <chead@is.invalid> - 2012-11-28 23:24 -0800
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 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
Re: Getting started with AVR and C dbr@kbrx.com - 2012-11-24 21:49 +0000
Re: Getting started with AVR and C MK <mk@nospam.co.uk> - 2012-11-25 12:24 +0000
Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-11-26 00:08 +0000
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-28 14:49 +0000 |
| Message-ID | <0.96c7977b73f1cb3bf4d0.20121128144941GMT.87ip8pu6ii.fsf@bsb.me.uk> |
| In reply to | #10598 |
Ivan Shmakov <oneingray@gmail.com> writes: >>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>>> Ivan Shmakov <oneingray@gmail.com> writes: <snip> > >> a << b a times 2 ^b (shift left) > >> a >> b a times 2 ^(-b) (shift right) > > > These ones are tricky because of all the corner cases (a shift equal > > or greater than the operand size, a shift of a bit into the sign > > position, > > Shouldn't these issues be already familiar to those coming from > the embedded programming background? The trouble is that people often think that what happened on the CPUs they've used before is what will happen on the next one. In other words there's a tendency to extrapolate form "what happens" to "what is defined to happen". But maybe the world of embedded programming is so diverse that people rarely make these assumptions. <snip> > > You could make a really rich summary table that shows priority, > > associativity, whether the expression denotes an lvalue and what > > happens to the operands (are they just promoted as for the shift > > operands or are the "usual arithmetic conversions" applied as for + > > and *). I can see why you would want to avoid too much detail in a > > simple explanation like this, but it does seem like a useful thing to > > do. > > Well, it seems like there already is such a table at [1]. Well I meant something more than that, but I understand your desire to keep things simple. The interesting things about C operators are the result type and value, the conversions that are done to the operands (simple promotion or "the usual arithmetic conversions"), the precedence and associativity, whether the result denotes an lvalue, and any side effects. Maybe that's too much for a single table, but I might have a go though. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Frank Miles <fpm@u.washington.edu> |
|---|---|
| Date | 2012-11-28 17:53 +0000 |
| Message-ID | <k95j21$otc$1@dont-email.me> |
| In reply to | #10598 |
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-28 18:05 +0000 |
| Message-ID | <k95joi$qcq$1@reader1.panix.com> |
| In reply to | #10600 |
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?
--
Grant Edwards grant.b.edwards Yow! It's NO USE ... I've
at gone to "CLUB MED"!!
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 12:56 -0600 |
| Message-ID | <JaGdnWuCkdH4wyvNnZ2dnUVZ_oOdnZ2d@web-ster.com> |
| In reply to | #10601 |
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. -- 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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-28 21:45 +0000 |
| Message-ID | <k960mf$ghq$1@speranza.aioe.org> |
| In reply to | #10604 |
In comp.lang.c Tim Wescott <tim@seemywebsite.com> wrote: > On Wed, 28 Nov 2012 18:05:06 +0000, Grant Edwards wrote: >> On 2012-11-28, Frank Miles <fpm@u.washington.edu> 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. 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. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 15:55 -0600 |
| Message-ID | <JaGdnWWCkdHAFSvNnZ2dnUVZ_oOdnZ2d@web-ster.com> |
| In reply to | #10605 |
On Wed, 28 Nov 2012 21:45:51 +0000, glen herrmannsfeldt wrote: > In comp.lang.c Tim Wescott <tim@seemywebsite.com> wrote: >> On Wed, 28 Nov 2012 18:05:06 +0000, Grant Edwards wrote: > >>> On 2012-11-28, Frank Miles <fpm@u.washington.edu> 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. > > 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. > > -- glen Yes. But a compliant processor will take int16_t a, b; int32_t c c = (int32_t)a * b; and cast both a and b to 32-bit. I have worked with compilers that would _demote_ a 32-bit to a 16 bit and do the math, unless _both_ operands were cast to 32-bit, i.e. c = (int32_t)a * (int32_t)b; Wrong? Yes. But if that's what the compiler do, that's what you work with... -- 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 | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2012-11-29 01:35 +0100 |
| Message-ID | <TN6dnaDoIqIhMCvNnZ2dnUVZ8v-dnZ2d@lyse.net> |
| In reply to | #10605 |
On 28/11/12 22:45, glen herrmannsfeldt wrote: > In comp.lang.c Tim Wescott <tim@seemywebsite.com> wrote: >> On Wed, 28 Nov 2012 18:05:06 +0000, Grant Edwards wrote: > >>> On 2012-11-28, Frank Miles <fpm@u.washington.edu> 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. > > 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. 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2012-11-29 01:47 +0100 |
| Message-ID | <ahnplnFbufpU1@mid.dfncis.de> |
| In reply to | #10611 |
On 29.11.2012 01:35, David Brown wrote: > 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. Close, but not cigar. You forgot about types smaller than the platform's "int". Those will be converted up to either signed or unsigned int anyway, i.e. even if both operands are of the same size. > So the bit-size of the processor, and the bit-size of "int" on that > particular target, is irrelevant. Incorrect. It is very relevant as soon as either of the operands' types is smaller than "int" on the particular target. The rule to remember is that C never does arithmetic on anything smaller than an 'int'. > Given: > > int16_t a, b; > int32_t c > > If you write just "c = a * b", then the multiplication is carried it at > 16-bit, then promoted to 32-bit. Not if you're on a 32-bit target it isn't. Default conversion to 32-bit int takes place first, so both operands are first converted to 32-bit, then a 32 x 32 --> 32 bit multiply is carried out. At least in principle (that is: modulo the "as-if rule").
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-11-29 09:24 +0100 |
| Message-ID | <xJmdne4-9L7HgCrNnZ2dnUVZ8s-dnZ2d@lyse.net> |
| In reply to | #10612 |
On 29/11/2012 01:47, Hans-Bernhard Bröker wrote: > On 29.11.2012 01:35, David Brown wrote: > >> 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. > > Close, but not cigar. You forgot about types smaller than the > platform's "int". Those will be converted up to either signed or > unsigned int anyway, i.e. even if both operands are of the same size. > >> So the bit-size of the processor, and the bit-size of "int" on that >> particular target, is irrelevant. > > Incorrect. It is very relevant as soon as either of the operands' types > is smaller than "int" on the particular target. > > The rule to remember is that C never does arithmetic on anything smaller > than an 'int'. > >> Given: >> >> int16_t a, b; >> int32_t c >> >> If you write just "c = a * b", then the multiplication is carried it at >> 16-bit, then promoted to 32-bit. > > Not if you're on a 32-bit target it isn't. Default conversion to 32-bit > int takes place first, so both operands are first converted to 32-bit, > then a 32 x 32 --> 32 bit multiply is carried out. At least in > principle (that is: modulo the "as-if rule"). Of course you are correct here. I should not be posting so late - or I should have drunk more coffee first, because I know this stuff (as long as my brain is functioning correctly!). Apologies if I've added to the confusion here, and thanks for the correction.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-29 01:18 +0000 |
| Message-ID | <0.b3ca9d18d0528a0b5ff8.20121129011842GMT.871ufdtde5.fsf@bsb.me.uk> |
| In reply to | #10611 |
David Brown <david.brown@removethis.hesbynett.no> writes:
<snip>
> 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.
Not exactly, no, though there is some confusion because you talk of
different int sizes. int is one C type so there is only one int size,
but I'm assuming you meant "integer types of different size".
If that's what you meant, it's not quite right because multiplying a
short by a char (for example) will involve promoting both operands to
int. Other more outlandish examples include multiplying a char by a
_Bool and many cases involving bit fields.
> Then the multiply is carried
> out modulo the size of the larger one.
That's one commonly observed behaviour but it is not "the correct
behaviour". If the common type arrived at by the arithmetic conversions
is a signed type, the multiplication may overflow and anything at all
can happen (i.e. what happens is undefined by the C standard). Unsigned
integer arithmetic does not overflow.
> Then the result is truncated
> or extended as needed to fit the target variable.
Again, not quite. The result is converted to type of the object it is
being assigned to, and a great deal of leeway is given to
implementations when the target type is a signed int. If the result
can't be represented in the target type, either the result is
implementation defined or an implementation defined signal is raised.
For unsigned types, the behaviour is entirely defined by the C standard
(conversion modulo 2^width which is, as you say, truncation).
> 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.
(unless int happens to be wider than 32 bits)
> 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.
The machine bit-size is not really the thing that matters. What matters
is the sizes assigned to the various types by the C implementation.
What you say is roughly correct for an implementation with a 16 bit int
type ("roughly" because of the possibility of overflow).
The size given to int is often the natural one (or one of the natural
ones) for the machine in question. When this is the case, the bit size
of the target does matter, but only because of the differing int sizes.
> 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.
It leads to a special kind of hell! When you can't ever shake off the
idea that x, y or z once went wrong on compiler p, q or r, you end up
having to fold every trick you ever used to get your code past bad
compilers into every program.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2012-11-28 20:07 -0600 |
| Message-ID | <JaGdnZ29kdH_XivNnZ2dnUVZ_oOdnZ2d@web-ster.com> |
| In reply to | #10613 |
On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:
> David Brown <david.brown@removethis.hesbynett.no> writes: <snip>
>> 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.
>
> Not exactly, no, though there is some confusion because you talk of
> different int sizes. int is one C type so there is only one int size,
> but I'm assuming you meant "integer types of different size".
>
> If that's what you meant, it's not quite right because multiplying a
> short by a char (for example) will involve promoting both operands to
> int. Other more outlandish examples include multiplying a char by a
> _Bool and many cases involving bit fields.
>
>> Then the multiply is carried
>> out modulo the size of the larger one.
>
> That's one commonly observed behaviour but it is not "the correct
> behaviour". If the common type arrived at by the arithmetic conversions
> is a signed type, the multiplication may overflow and anything at all
> can happen (i.e. what happens is undefined by the C standard). Unsigned
> integer arithmetic does not overflow.
>
>> Then the result is truncated
>> or extended as needed to fit the target variable.
>
> Again, not quite. The result is converted to type of the object it is
> being assigned to, and a great deal of leeway is given to
> implementations when the target type is a signed int. If the result
> can't be represented in the target type, either the result is
> implementation defined or an implementation defined signal is raised.
>
> For unsigned types, the behaviour is entirely defined by the C standard
> (conversion modulo 2^width which is, as you say, truncation).
>
>> 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.
>
> (unless int happens to be wider than 32 bits)
>
>> 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.
>
> The machine bit-size is not really the thing that matters. What matters
> is the sizes assigned to the various types by the C implementation. What
> you say is roughly correct for an implementation with a 16 bit int type
> ("roughly" because of the possibility of overflow).
>
> The size given to int is often the natural one (or one of the natural
> ones) for the machine in question. When this is the case, the bit size
> of the target does matter, but only because of the differing int sizes.
>
>> 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.
>
> It leads to a special kind of hell! When you can't ever shake off the
> idea that x, y or z once went wrong on compiler p, q or r, you end up
> having to fold every trick you ever used to get your code past bad
> compilers into every program.
Me, I just try to remember that x, y or z went wrong on some compiler
some time, so that if I see symptoms again those problems are on my short
list, and maybe even a fix or two.
Like Texas Instrument's Code Composter for the TMS320F2812, which has a
32-bit "double". #$%@.
--
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:23 +0000 |
| Message-ID | <k97ulf$jpg$3@reader1.panix.com> |
| In reply to | #10616 |
On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:
> Me, I just try to remember that x, y or z went wrong on some compiler
> some time, so that if I see symptoms again those problems are on my short
> list, and maybe even a fix or two.
>
> Like Texas Instrument's Code Composter for the TMS320F2812, which has a
> 32-bit "double". #$%@.
Or on the TMS320C40, where char, int, long, long long, float and
double are all 32 bits and all have a sizeof() 1. Trying to impliment
any sort of communications protocol with that was fun.
--
Grant Edwards grant.b.edwards Yow! Is it NOUVELLE
at CUISINE when 3 olives are
gmail.com struggling with a scallop
in a plate of SAUCE MORNAY?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 11:01 -0500 |
| Message-ID | <k980sv$sh4$1@dont-email.me> |
| In reply to | #10639 |
On 11/29/2012 10:23 AM, Grant Edwards wrote: > On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote: >> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote: > >> Me, I just try to remember that x, y or z went wrong on some compiler >> some time, so that if I see symptoms again those problems are on my short >> list, and maybe even a fix or two. >> >> Like Texas Instrument's Code Composter for the TMS320F2812, which has a >> 32-bit "double". #$%@. > > Or on the TMS320C40, where char, int, long, long long, float and > double are all 32 bits and all have a sizeof() 1. ... There's a key difference there. The implementation you describe could be fully conforming. The one he described could not; you can't meet the standard's precision and range requirements for double with a 32-bit data type. > ... Trying to impliment > any sort of communications protocol with that was fun. Thanks for that information. Claims have frequently been made on comp.lang.c that, while the C standard allows CHAR_BIT != 8, the existence of such implementations is a myth. I'm glad to have a specific counter example to cite. There's something I've wondered about such machines: when data from other machines containing data types smaller than 32 bits (for instance, ASCII text files) is transferred to the TMS320C40, how is this usually handled? I could imagine three main possibilities: a) Four 8-bit bytes of data are packed into each 32-bit byte b) Each field value stored in a data type smaller than 32 bits is converted to a 32-bit type, and stored as such. For instance, a file containing 45,678 8-bit bytes of text gets converted into a file containing 45,678 32-bit bytes of text. c) Different methods are used in different contexts, leading to constant headaches. This strikes me as the most likely possibility. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-29 19:19 +0000 |
| Message-ID | <k98cfs$lnr$1@reader1.panix.com> |
| In reply to | #10641 |
On 2012-11-29, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/29/2012 10:23 AM, Grant Edwards wrote:
>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
>>> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:
>>
>>> Me, I just try to remember that x, y or z went wrong on some compiler
>>> some time, so that if I see symptoms again those problems are on my short
>>> list, and maybe even a fix or two.
>>>
>>> Like Texas Instrument's Code Composter for the TMS320F2812, which has a
>>> 32-bit "double". #$%@.
>>
>> Or on the TMS320C40, where char, int, long, long long, float and
>> double are all 32 bits and all have a sizeof() 1. ...
>
> There's a key difference there. The implementation you describe could
> be fully conforming. The one he described could not; you can't meet
> the standard's precision and range requirements for double with a
> 32-bit data type.
Well, the case I cited had 32-bit doubles. Other than that, I think it
was conforming. When trying to reuse source modules, it's shocking
how many assumptions I make that aren't implied by the C standard.
>> ... Trying to impliment any sort of communications protocol with
>> that was fun.
>
> Thanks for that information. Claims have frequently been made on
> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
> existence of such implementations is a myth. I'm glad to have a
> specific counter example to cite.
If you look at some other DSPs, I think you'll find similar examples
where everything is 16 bits (they tend not to support FP at all).
> There's something I've wondered about such machines: when data from
> other machines containing data types smaller than 32 bits (for
> instance, ASCII text files) is transferred to the TMS320C40, how is
> this usually handled? I could imagine three main possibilities:
A TMS320 is a DSP, and I doubt there are any that have actual
filesystems. OTOH, high-speed serial interfaces are common, and
filling in things like protocol headers involves a lot of
shifting/masking/anding/oring.
> a) Four 8-bit bytes of data are packed into each 32-bit byte
That's pretty common for data being sent to/from "normal" CPUs.
> b) Each field value stored in a data type smaller than 32 bits is
> converted to a 32-bit type, and stored as such. For instance, a
> file containing 45,678 8-bit bytes of text gets converted into a
> file containing 45,678 32-bit bytes of text.
If you need to do any sort of string manipulation (which you try to
avoid like the plague), that's what you end up doing.
> c) Different methods are used in different contexts, leading to
> constant headaches. This strikes me as the most likely possibility.
Exactly.
And the icing on the cake is that the 32-bit FP represention isn't
IEEE-784, so you also get to convert between external and internal FP
representations also. Fun!
--
Grant Edwards grant.b.edwards Yow! My NOSE is NUMB!
at
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 14:32 -0500 |
| Message-ID | <k98d8j$gn4$1@dont-email.me> |
| In reply to | #10644 |
On 11/29/2012 02:19 PM, Grant Edwards wrote: > On 2012-11-29, James Kuyper <jameskuyper@verizon.net> wrote: >> On 11/29/2012 10:23 AM, Grant Edwards wrote: >>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote: ... >>>> Like Texas Instrument's Code Composter for the TMS320F2812, which has a >>>> 32-bit "double". #$%@. >>> >>> Or on the TMS320C40, where char, int, long, long long, float and >>> double are all 32 bits and all have a sizeof() 1. ... >> >> There's a key difference there. The implementation you describe could >> be fully conforming. The one he described could not; you can't meet >> the standard's precision and range requirements for double with a >> 32-bit data type. > > Well, the case I cited had 32-bit doubles. Oops - I missed that. OK - a more accurate statement would have been that your example had no additional conformance issues that weren't present in his example. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Jon Kirwan <jonk@infinitefactors.org> |
|---|---|
| Date | 2012-11-29 11:44 -0800 |
| Message-ID | <diefb8p226eou89jtfpg1ddfflsubt9sq0@4ax.com> |
| In reply to | #10641 |
On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper <jameskuyper@verizon.net> wrote: ><snip> >Claims have frequently been made on >comp.lang.c that, while the C standard allows CHAR_BIT != 8, the >existence of such implementations is a myth. I'm glad to have a specific >counter example to cite. ><snip> I believe that C was implemented on the PDP-10. I didn't use it when I was programming the PDP-10 (I used assembly, then, and some other languages... but not C, until I worked on Unix v6 in '78.) But that was a 36-bit machine. And ASCII was packed into 7 bits so that 5 chars fit in a word. No one used 8, so far as I recall. That was the standard method. So I'm curious now what the C implementation did. Of course, all that is prior to any standard. But it might be another case to discuss, anyway. Jon
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-29 21:23 +0000 |
| Message-ID | <k98jou$n5a$1@speranza.aioe.org> |
| In reply to | #10648 |
In comp.lang.c Jon Kirwan <jonk@infinitefactors.org> wrote: > On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper > <jameskuyper@verizon.net> wrote: >><snip> >>Claims have frequently been made on >>comp.lang.c that, while the C standard allows CHAR_BIT != 8, the As I remember the stories, the CRAY-1 had 64 bit char. >>existence of such implementations is a myth. I'm glad to have a specific >>counter example to cite. >><snip> > I believe that C was implemented on the PDP-10. I didn't use > it when I was programming the PDP-10 (I used assembly, then, > and some other languages... but not C, until I worked on Unix > v6 in '78.) But that was a 36-bit machine. And ASCII was > packed into 7 bits so that 5 chars fit in a word. No one used > 8, so far as I recall. That was the standard method. So I'm > curious now what the C implementation did. Yes the TOPS-10 file format stores ASCII as 5 characters to the word, but C can't do that. In a discussion some time ago about actual implementations, 9 and 18 bit char were discussed. The PDP-10 has instructions for operating on halfwords, which could be used, possibly with execute (XCT) to select the appropriate instruction, or for loops an unrolled loop. Or 9 bit chars using the byte instructions. > Of course, all that is prior to any standard. But it might be > another case to discuss, anyway. I keep wondering about a C compiler for the 7090, one of the last sign magnitude machines, and also 36 bits. It was usual to store six 6 bit BCDIC (more often called just BCD) characters per word. Also, 6 bit characters on 7 track magnetic tape. The card reader on the 704, and I will guess also the 7090, reads one card row into two 36 bit words, ignoring the last eight columns. Software had to convert that into 12 characters in two words. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-29 18:15 -0800 |
| Message-ID | <lnk3t3alal.fsf@nuthaus.mib.org> |
| In reply to | #10653 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In comp.lang.c Jon Kirwan <jonk@infinitefactors.org> wrote:
>> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
>> <jameskuyper@verizon.net> wrote:
>
>>><snip>
>>>Claims have frequently been made on
>>>comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
>
> As I remember the stories, the CRAY-1 had 64 bit char.
[...]
That may well be true; I never used a Cray-1. (And there was more
emphasis on Fortran, or should I say FORTRAN, than on C.)
By the time I started using Crays, they were running Unicos, Cray's
version of Unix, so they pretty much had to have CHAR_BIT==8.
--
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]
| From | me@linnix.info-for.us |
|---|---|
| Date | 2012-11-30 09:26 -0800 |
| Message-ID | <76c77f99-6c09-4a37-a318-4bf75ff4fbb4@googlegroups.com> |
| In reply to | #10648 |
> I believe that C was implemented on the PDP-10. I didn't use > it when I was programming the PDP-10 (I used assembly, then, > and some other languages... but not C, until I worked on Unix > v6 in '78.) But that was a 36-bit machine. And ASCII was > packed into 7 bits so that 5 chars fit in a word. No one used > 8, so far as I recall. That was the standard method. So I'm > curious now what the C implementation did. For Unix, serial I/O was as important as efficient storage of data. Most serial terminal can't do more than 8 bits, and usually 7E or 7O. So, 8 bit char became standard.
[toc] | [prev] | [next] | [standalone]
| From | Jon Kirwan <jonk@infinitefactors.org> |
|---|---|
| Date | 2012-11-30 13:22 -0800 |
| Message-ID | <r94ib85ed59imsvurh2ruq7sr1d0bkf82v@4ax.com> |
| In reply to | #10666 |
On Fri, 30 Nov 2012 09:26:39 -0800 (PST), me@linnix.info-for.us wrote: >> I believe that C was implemented on the PDP-10. I didn't use >> it when I was programming the PDP-10 (I used assembly, then, >> and some other languages... but not C, until I worked on Unix >> v6 in '78.) But that was a 36-bit machine. And ASCII was >> packed into 7 bits so that 5 chars fit in a word. No one used >> 8, so far as I recall. That was the standard method. So I'm >> curious now what the C implementation did. > >For Unix, serial I/O was as important as efficient storage of data. Given the cost of memory back then, primary or secondary, a great many man-hours were spent on efficient storage. Serial I/O was almost exclusively used because of how modems worked, then, for transmission over long distances. (Some may argue that it requires fewer wires, too, in cables. But that was less an issue then -- witness the 36-pin and 25-pin Centronix cables/connectors which were very wire-heavy.) It turns out that terminals, like the ASR-33 and KSR-35, were often used without a computer for dial-up modem use over a phone line. So they used a serial interface, by design. Which meant that Unix needed to cope with it. But I wouldn't say "as important as." I worked on the v6 Unix kernel, so I was slightly aware of the situation. Of course, I was just bringing up the PDP-10 because of its odd way of packing 7-bit codes into a 36-bit word. >Most serial terminal can't do more than 8 bits, and usually 7E or 7O. >So, 8 bit char became standard. At the time, there was no real standard at all. I saw equal numbers of machines using EBCDIC and 6-bit (5-bit Boudot was waning by this time but I also remember old terminals that used 5-bit) and 7-bit. No machine used 8-bit for anything, then. The 8th bit was always just looked at as either 'don't punch it at all, so the paper tape is more durable' or else make it even or odd parity. Some of us would write programs to punch out visible English messages on the tape, which was one of the few reasons we actually wanted control over 8 bits (for those paper punch machines that punched 8.) I honestly hoped, but didn't know, if ASCII would win out in the end. I almost had a feeling then that I'd be converting from one code to another the rest of my life, if things continued as they were. I wanted ASCII to win, though. Side note: there was only a gradual "coming together" on the idea that an 8-bit byte was a "good idea." I think a lot of people these days imagine that it was always as obvious and as ubiquitous as it is today. But that's not entirely true. Things went to 8-bit, gradually. Partly, because 8 bits is a nice 2^3 power thing and partly because ASCII was gradually taking over as a standard and would fit into a 8-bit byte, nicely. There was a confluence of forces going on and this kind of "precipitated out" to what it is today. Side note again: Recently, I read a "personal history" talking about the complexity of the ASR-33. The author has no idea. I also remember quite well the much more complicated KSR-35. I worked on repairing both, from time to time. By comparison, the ASR-33 was a toy, designed for less lifetime and less complex, as well. The earlier KSR-35 was made for men, so to speak -- extremely well lubricated system with real man-parts and not toy pieces. The ASR-33 had a cute little cylinder with the letters on it, not that unlike the typewriter ball. The KSR-35 had a large hammer block, instead. Jon
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web