Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #107910 > unrolled thread
| Started by | Peabody <waybackNO584SPAM44@yahoo.com> |
|---|---|
| First post | 2017-04-08 22:59 -0500 |
| Last post | 2017-04-26 11:09 -0700 |
| Articles | 20 on this page of 187 — 30 participants |
Back to article view | Back to comp.lang.c
And they say C is obscure Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 22:59 -0500
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-08 22:17 -0600
Re: And they say C is obscure Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-09 07:42 -0500
Re: And they say C is obscure Barry Schwarz <schwarzb@dqel.com> - 2017-04-09 07:46 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-04-09 16:47 +0200
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 14:42 -0400
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 13:25 -0700
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:56 -0400
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-09 15:18 -0600
Re: And they say C is obscure Ken Brody <kenbrody@spamcop.net> - 2017-04-10 12:57 -0400
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 14:46 +0000
Re: And they say C is obscure luser droog <luser.droog@gmail.com> - 2017-04-09 07:26 -0700
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 14:18 -0400
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-09 20:53 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 13:52 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:48 +0000
Re: And they say C is obscure Ken Brody <kenbrody@spamcop.net> - 2017-04-14 13:36 -0400
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-20 13:24 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 08:05 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 15:32 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 09:48 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 18:00 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 11:34 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 18:41 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-09 13:18 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 14:03 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-09 22:56 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-04-10 09:12 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 08:22 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 18:28 +0100
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 17:49 +0000
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 11:50 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 20:33 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 13:06 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-10 21:48 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 22:15 +0100
Re: And they say C is obscure Michael Barry <barrym95838@yahoo.com> - 2017-04-10 18:46 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 21:46 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 23:09 +0100
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-11 12:40 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-11 14:15 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 10:13 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-26 10:38 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-10 15:23 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:51 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 13:14 +0100
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-14 10:42 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 19:04 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-14 21:43 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 11:02 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-26 19:05 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-26 12:02 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-26 21:55 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-27 00:15 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:23 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-14 18:12 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 18:37 +0100
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-11 00:03 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-10 14:10 -0700
Re: And they say C is obscure mark.bluemel@gmail.com - 2017-04-11 08:41 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-11 08:58 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-11 09:06 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-11 16:46 +0000
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-11 19:02 +0100
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:59 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 10:59 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-27 21:40 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:17 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:50 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:20 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:37 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-06 00:16 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 11:49 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-06 13:16 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 14:10 -0700
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-06 20:23 -0600
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 21:51 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:04 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:09 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:18 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:54 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-07 13:48 +0100
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 06:13 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-07 15:10 +0200
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-07 16:47 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-07 21:08 +0200
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-07 21:54 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-08 00:59 +0200
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-07 16:59 -0700
Re: And they say C is obscure Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:28 -0500
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-08 10:16 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 02:41 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-08 07:36 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:06 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-09 14:03 +0200
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-09 19:41 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-09 21:35 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 20:25 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 14:48 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 14:23 +0100
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-10 21:31 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-10 12:45 -0700
Re: And they say C is obscure "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-10 16:49 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-07 08:56 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-08 09:54 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 17:32 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-08 18:26 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 02:28 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:15 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 05:53 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-09 14:15 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 06:55 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-09 14:43 +0100
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-09 23:07 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 15:32 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-10 11:39 +0000
Re: And they say C is obscure mark.bluemel@gmail.com - 2017-05-09 06:21 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-11 03:00 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:20 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-10 10:06 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-10 11:11 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 12:45 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 05:33 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 13:41 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 09:32 -0400
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 14:51 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 10:54 -0400
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 17:36 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 09:28 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 19:12 +0100
Re: And they say C is obscure me <crisdunbar@gmail.com> - 2017-05-10 11:53 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 22:19 +0200
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-11 07:36 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-11 00:39 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-11 13:30 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 13:17 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-11 13:37 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-12 10:39 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:34 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-13 09:48 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-13 19:48 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-13 14:01 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-13 15:23 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 03:14 -0700
[OT] Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 12:18 +0100
Re: [OT] Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 13:28 +0100
Re: [OT] Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 15:56 +0200
Re: [OT] Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 16:56 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 02:03 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 03:08 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 13:44 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 16:13 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 08:04 -0700
Re: And they say C is obscure luser droog <luser.droog@gmail.com> - 2017-05-14 08:52 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 09:16 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 17:48 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:11 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 22:57 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-14 14:10 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 15:51 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:04 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-11 07:45 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 16:45 +0100
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-11 19:58 +0100
Re: And they say C is obscure Ike Naar <ike@iceland.freeshell.org> - 2017-05-11 22:15 +0000
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 23:24 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-12 10:50 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 09:57 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 16:31 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 07:50 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-05-10 09:00 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-11 03:03 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-11 09:02 -0700
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-12 18:34 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 18:47 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:03 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:11 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 08:28 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 09:40 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 20:26 +0000
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-10 00:20 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-08 09:01 -0700
Re: And they say C is obscure John Bode <jfbode1029@gmail.com> - 2017-04-11 09:15 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-11 09:29 -0700
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-04-13 16:00 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:45 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 11:09 -0700
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | Peabody <waybackNO584SPAM44@yahoo.com> |
|---|---|
| Date | 2017-04-08 22:59 -0500 |
| Subject | And they say C is obscure |
| Message-ID | <20170409-035940.754.0@Peabody.ssl.astraweb.com> |
Sorry, but I just can't find it. Could someone please explain this: for(linepos= 0; linepos < linelen-3; linepos+= 3, dataframelen++) So this is parsing a TI-TXT file, which looks like this: @FFE0 FF FF FF FF 14 FC FF FF FF FF 5E FD FF FF FF FF 0E FD E6 F9 28 FD FF FF FF FF FF FF FF FF C2 FC q into binary values. So the 3's make sense. I understand it up until the ", dataframelen++" which seems to have nothing to do with the FOR loop. It's like "increment linepos by 3, and while you're at it, go ahead and increment dataframelen too." Am I reading that right? is that structure allowed in C? Well, obviously it is, but how does anyone ever get up to speed in this language. More important, how does anyone check for errors trying to read stuff like this? And while I'm at it, let me ask how you would create an unsigned byte array exactly 2048 bytes long, and fill it with FFs. I guess I need to go to school for this, or give it up and go back to assembler. It's just really hard trying to understand someone else's code. Thanks for any help.
[toc] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-04-08 22:17 -0600 |
| Message-ID | <1bh91ycizu.fsf@pfeifferfamily.net> |
| In reply to | #107910 |
Peabody <waybackNO584SPAM44@yahoo.com> writes:
> Sorry, but I just can't find it.
>
> Could someone please explain this:
>
> for(linepos= 0;
> linepos < linelen-3; linepos+= 3, dataframelen++)
>
> So this is parsing a TI-TXT file, which looks like this:
>
> @FFE0
> FF FF FF FF 14 FC FF FF FF FF 5E FD FF FF FF FF
> 0E FD E6 F9 28 FD FF FF FF FF FF FF FF FF C2 FC
> q
>
> into binary values. So the 3's make sense.
>
> I understand it up until the ", dataframelen++" which seems to have nothing
> to do with the FOR loop. It's like "increment linepos by 3, and while you're
> at it, go ahead and increment dataframelen too." Am I reading that right?
> is that structure allowed in C? Well, obviously it is, but how does anyone
> ever get up to speed in this language. More important, how does anyone check
> for errors trying to read stuff like this?
>
> And while I'm at it, let me ask how you would create an unsigned byte array
> exactly 2048 bytes long, and fill it with FFs.
>
> I guess I need to go to school for this, or give it up and go back to
> assembler. It's just really hard trying to understand someone else's code.
>
> Thanks for any help.
Hazarding a guess since there really isn't enough context to be sure, I
imagine the body of the loop ends up doing some transformation on the
characters at line[linepos] and putting the result in
dataframe[dateframelen] (where the variable names I guessed are almost
certainly wrong, but hopefully helpful in explaining what's happening).
I'm guessing the (not shown) body of the loop is translating a buffer of
hexadecimal values represented in ASCII and separated by spaces into a
buffer of binary bytes.
Filling the buffer you've asked for would look something like
#define BUFSIZ 2048
unsigned char buf[BUFSIZ];
for (int i = 0; i < BUFSIZ; i++)
buf[i] = 0xff;
And the way to come up to speed on the language is, sorry, don't start
with code written by someone trying to be clever.
[toc] | [prev] | [next] | [standalone]
| From | Peabody <waybackNO584SPAM44@yahoo.com> |
|---|---|
| Date | 2017-04-09 07:42 -0500 |
| Message-ID | <20170409-124205.307.0@Peabody.ssl.astraweb.com> |
| In reply to | #107911 |
Joe Pfeiffer says... >> for(linepos= 0; >> linepos < linelen-3; linepos+= 3, dataframelen++) > I'm guessing the (not shown) body of the loop is > translating a buffer of hexadecimal values represented > in ASCII and separated by spaces into a buffer of binary > bytes. Yes, that's exactly what it does. But I found nothing from searching online that described what C permits in the inc/dec field of a FOR loop. It appears you can do multiple things there, but do they have to be increments or decrements, or could you do anything after the comma? > #define BUFSIZ 2048 > unsigned char buf[BUFSIZ]; > for (int i = 0; i < BUFSIZ; i++) > buf[i] = 0xff; Thanks. I just thought there might be a shorthand way of doing that in C. > And the way to come up to speed on the language is, > sorry, don't start with code written by someone trying > to be clever. I guess so. I just thought that code from TI itself for parsing TI-TXT would be a good source. And I'm sure it is, but just difficult to follow sometimes. Thanks for your help.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-04-09 07:46 -0700 |
| Message-ID | <44ikechc1tm6h9cmu6a5tvtb4q3svl1aks@4ax.com> |
| In reply to | #107928 |
On Sun, 09 Apr 2017 07:42:05 -0500, Peabody <waybackNO584SPAM44@yahoo.com> wrote: >Yes, that's exactly what it does. But I found nothing from >searching online that described what C permits in the >inc/dec field of a FOR loop. It appears you can do multiple >things there, but do they have to be increments or >decrements, or could you do anything after the comma? Google for and download n1570, a free and reasonably current copy of the C11 draft and study the sections that deals with the comma operator and the for statement. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-09 16:47 +0200 |
| Message-ID | <ocdhc7$64o$1@dont-email.me> |
| In reply to | #107928 |
On 09/04/17 14:42, Peabody wrote: > Joe Pfeiffer says... > > >> for(linepos= 0; > >> linepos < linelen-3; linepos+= 3, dataframelen++) > > > I'm guessing the (not shown) body of the loop is > > translating a buffer of hexadecimal values represented > > in ASCII and separated by spaces into a buffer of binary > > bytes. > > Yes, that's exactly what it does. But I found nothing from > searching online that described what C permits in the > inc/dec field of a FOR loop. It appears you can do multiple > things there, but do they have to be increments or > decrements, or could you do anything after the comma? > > > #define BUFSIZ 2048 > > unsigned char buf[BUFSIZ]; > > for (int i = 0; i < BUFSIZ; i++) > > buf[i] = 0xff; > > Thanks. I just thought there might be a shorthand way of > doing that in C. > > > And the way to come up to speed on the language is, > > sorry, don't start with code written by someone trying > > to be clever. > > I guess so. I just thought that code from TI itself for > parsing TI-TXT would be a good source. And I'm sure it is, > but just difficult to follow sometimes. > Don't be too sure about that. Often code like this can be very badly written - unclear, fragile (i.e., highly dependent on specific compilers and specific settings), and generally written in a hurry by non-experts. It is common that this sort of thing is written by beginners at a hardware company like TI - the experts are the people designing chips, writing deeply embedded firmware, etc. It certainly will be not be written with "helping beginners" in mind. > Thanks for your help. >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-09 14:42 -0400 |
| Message-ID | <ocdv4t$oan$1@dont-email.me> |
| In reply to | #107928 |
On 04/09/2017 08:42 AM, Peabody wrote:
> Joe Pfeiffer says...
>
> >> for(linepos= 0;
> >> linepos < linelen-3; linepos+= 3, dataframelen++)
>
> > I'm guessing the (not shown) body of the loop is
> > translating a buffer of hexadecimal values represented
> > in ASCII and separated by spaces into a buffer of binary
> > bytes.
>
> Yes, that's exactly what it does. But I found nothing from
> searching online that described what C permits in the
> inc/dec field of a FOR loop. It appears you can do multiple
> things there, but do they have to be increments or
> decrements, or could you do anything after the comma?
The comma is not part of the for-statement, it's part of a comma
expression. "first, second" is an expression that causes "first" to be
executed, then causes "second" to be executed. The expression has a
value which is the same as the value resulting from the execution of
"second". You can use a comma expression almost anywhere in a C program
(though you need to use parenthesis to prevent confusion with any of the
several other ways that commas are used in C). However, in most contexts
it's simpler to replace "result = (first, second)" with "first; result =
second;". A for statement is one of the few locations where it sometimes
actually makes sense to use a comma expression.
The grammar for a for statement is as follows:
for ( clause-1 ; expression-2 ; expression-3 ) statement
clause-1 can be either a declaration or an expression. expression-2 and
expression-3 can be any expression. There are no other restrictions on
clause-1, expression-2, expression-3, or statement. In particular,
there's no requirement that an increment or a decrement appear anywhere
in a for statement.
A for-statement is essentially equivalent to the following code:
{
clause-1;
while(expression-2)
{
statement;
expression-3;
}
}
Both clause-1 and expression-3 are completely optional. If expression-2
is omitted, it is replaced by a non-zero constant. statement is the only
variable part that cannot be omitted. However, it could be the empty
statement ";", which is pretty much the same thing as omitting the
statement.
Among other odd ways I've seen for statements used:
for(unsigned mask = 1; mask; mask <<= 1)
for(struct node *p = start_node; p; p = p->next)
for(double scale = 1.0; scale < MAX_SCALE; scale *= 2.0)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-09 13:25 -0700 |
| Message-ID | <ln37dhxr9r.fsf@kst-u.example.com> |
| In reply to | #107948 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The grammar for a for statement is as follows:
>
> for ( clause-1 ; expression-2 ; expression-3 ) statement
>
> clause-1 can be either a declaration or an expression. expression-2 and
> expression-3 can be any expression. There are no other restrictions on
> clause-1, expression-2, expression-3, or statement. In particular,
> there's no requirement that an increment or a decrement appear anywhere
> in a for statement.
That's not *quite* the actual grammar, but it's probably easier to
understand than the syntax specified in the standard.
The standard's syntax has to be a bit more convoluted to deal with
the semicolon between the first and second clauses; if the first
claus is a declaration, then the semicolon is syntactically part
of the declaration.
Another way to think about it is that the first clause can be either
an expression or a declaration with the semicolon removed.
Bottom line: There are always exactly two semicolons.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-09 22:56 -0400 |
| Message-ID | <oces3l$6o6$1@dont-email.me> |
| In reply to | #107955 |
On 04/09/2017 04:25 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> The grammar for a for statement is as follows:
>>
>> for ( clause-1 ; expression-2 ; expression-3 ) statement
>>
>> clause-1 can be either a declaration or an expression. expression-2 and
>> expression-3 can be any expression. There are no other restrictions on
>> clause-1, expression-2, expression-3, or statement. In particular,
>> there's no requirement that an increment or a decrement appear anywhere
>> in a for statement.
>
> That's not *quite* the actual grammar,
That's an exact quote from 6.8.5.3p1. I didn't notice that it differs
from the syntax provided in 6.8.5p1:
for ( expression opt ; expression opt ; expression opt ) statement
for ( declaration expression opt ; expression opt ) statement
6.8.5.3p1 also says "If clause-1 is a declaration ...", implying that
clause-1 could be a declaration, which would necessarily include it's
own semicolon in addition to the one separating clause-1 from
expression-2. That comment is therefore incompatible with the syntax
specified in 6.8.5p1.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-04-09 15:18 -0600 |
| Message-ID | <1b1st1cm9s.fsf@pfeifferfamily.net> |
| In reply to | #107928 |
Peabody <waybackNO584SPAM44@yahoo.com> writes: > Joe Pfeiffer says... > > >> for(linepos= 0; > >> linepos < linelen-3; linepos+= 3, dataframelen++) > > > I'm guessing the (not shown) body of the loop is > > translating a buffer of hexadecimal values represented > > in ASCII and separated by spaces into a buffer of binary > > bytes. > > Yes, that's exactly what it does. But I found nothing from > searching online that described what C permits in the > inc/dec field of a FOR loop. It appears you can do multiple > things there, but do they have to be increments or > decrements, or could you do anything after the comma? Other people have talked about the syntax of the for-loop; the thing to keep in mind here is that the the clause and expressions in the parentheses can to all intents and purposes be pretty much anything. You mentioned the inc/dec field -- not, that's just an arbitrary expression. You can do virtually anything in there; you can increment, you can decrement, you can move to the next element of a linked list, you can call a function that computes pi (which would be a stupid thing to have there, but the point is you can have anything). > > #define BUFSIZ 2048 > > unsigned char buf[BUFSIZ]; > > for (int i = 0; i < BUFSIZ; i++) > > buf[i] = 0xff; > > Thanks. I just thought there might be a shorthand way of > doing that in C. Other people have pointed out that calling memset() would be a better solution than this. They're right. > > > And the way to come up to speed on the language is, > > sorry, don't start with code written by someone trying > > to be clever. > > I guess so. I just thought that code from TI itself for > parsing TI-TXT would be a good source. And I'm sure it is, > but just difficult to follow sometimes. > > Thanks for your help. Some of the most horrifying code I've ever come across has been manufacturers' own code for their own devices. A lot of it is clearly written by an EE who is an expert at the device, but whose only knowledge of programming came from a two week boot camp.
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2017-04-10 12:57 -0400 |
| Message-ID | <ocgdch$eks$1@dont-email.me> |
| In reply to | #107928 |
On 4/9/2017 8:42 AM, Peabody wrote:
[...]
> >> for(linepos= 0;
> >> linepos < linelen-3; linepos+= 3, dataframelen++)
[...]
> Yes, that's exactly what it does. But I found nothing from
> searching online that described what C permits in the
> inc/dec field of a FOR loop. It appears you can do multiple
> things there, but do they have to be increments or
> decrements, or could you do anything after the comma?
[...]
I think your problem is thinking it's an "increment/decrement field".
The "for" statement simply takes three expressions[1], all of which are
optional. The first is evaluated before the first time through, and the
result discarded; the second is evaluated at the start of each time through,
and if non-zero, the loop is executed; and the third is evaluated at the end
of each time through, with its result being discarded.
While the third expression is typically used to increment/decrement values,
there is no restriction on what the expression can do.
Note, too, that, since all three parts are optional, an omitted "second
expression" is treated as "always true".
[1] Note that the first "expression" can also be a declaration, as in:
for ( int i=0 ; i < 10 ; i++ )
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-10 14:46 +0000 |
| Message-ID | <sVMGA.214271$On5.200315@fx43.iad> |
| In reply to | #107911 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >Peabody <waybackNO584SPAM44@yahoo.com> writes: > >> Sorry, but I just can't find it. >> >> Could someone please explain this: >> >> for(linepos= 0; >> linepos < linelen-3; linepos+= 3, dataframelen++) >> >> So this is parsing a TI-TXT file, which looks like this: >> >> @FFE0 >> FF FF FF FF 14 FC FF FF FF FF 5E FD FF FF FF FF >> 0E FD E6 F9 28 FD FF FF FF FF FF FF FF FF C2 FC >> q >> >> into binary values. So the 3's make sense. >> >> I understand it up until the ", dataframelen++" which seems to have nothing >> to do with the FOR loop. It's like "increment linepos by 3, and while you're >> at it, go ahead and increment dataframelen too." Am I reading that right? >> is that structure allowed in C? Well, obviously it is, but how does anyone >> ever get up to speed in this language. More important, how does anyone check >> for errors trying to read stuff like this? >> >> And while I'm at it, let me ask how you would create an unsigned byte array >> exactly 2048 bytes long, and fill it with FFs. >> >> I guess I need to go to school for this, or give it up and go back to >> assembler. It's just really hard trying to understand someone else's code. >> >> Thanks for any help. > >Hazarding a guess since there really isn't enough context to be sure, I >imagine the body of the loop ends up doing some transformation on the >characters at line[linepos] and putting the result in >dataframe[dateframelen] (where the variable names I guessed are almost >certainly wrong, but hopefully helpful in explaining what's happening). > >I'm guessing the (not shown) body of the loop is translating a buffer of >hexadecimal values represented in ASCII and separated by spaces into a >buffer of binary bytes. > >Filling the buffer you've asked for would look something like > >#define BUFSIZ 2048 >unsigned char buf[BUFSIZ]; >for (int i = 0; i < BUFSIZ; i++) > buf[i] = 0xff; Although I'd generally write 'memset(buf, 0xff, sizeof(buf));'
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-04-09 07:26 -0700 |
| Message-ID | <5a0a7c42-a759-4923-b224-83261824505b@googlegroups.com> |
| In reply to | #107910 |
On Saturday, April 8, 2017 at 10:59:52 PM UTC-5, Peabody wrote:
> Sorry, but I just can't find it.
>
> Could someone please explain this:
>
> for(linepos= 0;
> linepos < linelen-3; linepos+= 3, dataframelen++)
>
> So this is parsing a TI-TXT file, which looks like this:
>
> @FFE0
> FF FF FF FF 14 FC FF FF FF FF 5E FD FF FF FF FF
> 0E FD E6 F9 28 FD FF FF FF FF FF FF FF FF C2 FC
> q
>
> into binary values. So the 3's make sense.
>
> I understand it up until the ", dataframelen++" which seems to have nothing
> to do with the FOR loop. It's like "increment linepos by 3, and while you're
> at it, go ahead and increment dataframelen too." Am I reading that right?
> is that structure allowed in C? Well, obviously it is, but how does anyone
> ever get up to speed in this language. More important, how does anyone check
> for errors trying to read stuff like this?
>
There are 2 things going on here, both of which can be
understood by using the C grammar.
The syntax for a for loop looks like this (ignoring the
distracting complication of using a declaration):
for ( expression; expression; expression )
statement
And an expression can make use of the comma operator
to sequence two sub-expressions:
expression := expression1 , expression2
So, just like you guessed, it's doing 2 things where
/normally/ you might have a single expression that
does just one thing.
HTH
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-09 14:18 -0400 |
| Message-ID | <ocdtn3$j5q$1@dont-email.me> |
| In reply to | #107910 |
On 04/08/2017 11:59 PM, Peabody wrote:
...
> And while I'm at it, let me ask how you would create an unsigned byte array
> exactly 2048 bytes long, and fill it with FFs.
#include <string.h>
unsigned char array[2048];
memset(array, 0xFF, sizeof array);
Note: the #include should be at file scope. The call to memset() must
occur inside a function. The declaration for array could occur either
inside or outside a function.
Functionally, this is identical to the loop that Joe Pfeiffer showed
you. However, it's possible (but not guaranteed) that the call to
memset() may execute significantly faster than that loop - it's quite
unlikely to execute significantly slower.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-09 20:53 +0100 |
| Message-ID | <8760idxsq5.fsf@gmail.com> |
| In reply to | #107945 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 04/08/2017 11:59 PM, Peabody wrote:
> ...
>> And while I'm at it, let me ask how you would create an unsigned byte array
>> exactly 2048 bytes long, and fill it with FFs.
>
> #include <string.h>
>
> unsigned char array[2048];
>
> memset(array, 0xFF, sizeof array);
>
> Note: the #include should be at file scope. The call to memset() must
> occur inside a function. The declaration for array could occur either
> inside or outside a function.
*Warning for Peabody*
void set_to_0xff(char array[2048])
{
memset(array, 0xFF, sizeof array);
}
main()
{
char my_arr[2048];
set_to_0xff(my_arr);
}
will not work. A (IMHO truly horrible but mostly forgiveable)
historical anomaly of the language design.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-09 13:52 -0700 |
| Message-ID | <lny3v9wbgh.fsf@kst-u.example.com> |
| In reply to | #107945 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> James Kuyper <jameskuyper@verizon.net> writes:
>>Functionally, this is identical to the loop that Joe Pfeiffer showed
>>you. However, it's possible (but not guaranteed) that the call to
>>memset() may execute significantly faster than that loop - it's quite
>>unlikely to execute significantly slower.
>
> In C++, AFAIK function calls are preferred to loops. IIRC,
> one reason is that loops are more error prone (they might have
> off-by-one errors, or unsigned-loops might never terminate).
>
> Also, a function name can convey the intent of the author,
> while a loop has to be analyzed by the reader to understand
> what it does.
>
> When one uses a function, OTOH, one has to carefully read
> the documentation before writing the call.
There's nothing specific to C++ about any of that.
A call to memset() is generally preferred to an equivalent for loop,
because it's simpler and likely to be faster. Of course you have to
understand what a function does if you're going to call it. Similarly,
if you write an explicit loop you have to understand how the loop works,
including both the syntax and semantics of a "for" loop and the code
used in the body of the loop. Functions are just one case of the need
to understand the code you're writing.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-14 11:48 +0000 |
| Message-ID | <58f0b5fc.7192062@news.xs4all.nl> |
| In reply to | #107956 |
Keith Thompson <kst-u@mib.org> wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > > In C++, AFAIK function calls are preferred to loops. IIRC, > > one reason is that loops are more error prone (they might have > > off-by-one errors, or unsigned-loops might never terminate). > > > > Also, a function name can convey the intent of the author, > > while a loop has to be analyzed by the reader to understand > > what it does. > > > > When one uses a function, OTOH, one has to carefully read > > the documentation before writing the call. > > There's nothing specific to C++ about any of that. > > A call to memset() is generally preferred to an equivalent for loop, > because it's simpler and likely to be faster. Of course you have to > understand what a function does if you're going to call it. It's also relevant, here, that memset() is a Standard function, and one that can usually be optimised very agressively. If the function is user code, or less fundamental, the equation can change drastically. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2017-04-14 13:36 -0400 |
| Message-ID | <ocr14n$744$1@dont-email.me> |
| In reply to | #108124 |
On 4/14/2017 7:48 AM, Richard Bos wrote: > Keith Thompson <kst-u@mib.org> wrote: [...] >> A call to memset() is generally preferred to an equivalent for loop, >> because it's simpler and likely to be faster. Of course you have to >> understand what a function does if you're going to call it. > > It's also relevant, here, that memset() is a Standard function, and one > that can usually be optimised very agressively. If the function is user > code, or less fundamental, the equation can change drastically. I have also seem smallish memset() calls inlined to things like a simple "store a 4-byte zero here, then another 4-byte zero, and then a 2-byte zero". Much more efficient than any function call plus loop could ever be. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-20 13:24 +0000 |
| Message-ID | <58f8b666.1301234@news.xs4all.nl> |
| In reply to | #108135 |
Ken Brody <kenbrody@spamcop.net> wrote: > On 4/14/2017 7:48 AM, Richard Bos wrote: > > Keith Thompson <kst-u@mib.org> wrote: > [...] > >> A call to memset() is generally preferred to an equivalent for loop, > >> because it's simpler and likely to be faster. Of course you have to > >> understand what a function does if you're going to call it. > > > > It's also relevant, here, that memset() is a Standard function, and one > > that can usually be optimised very agressively. If the function is user > > code, or less fundamental, the equation can change drastically. > > I have also seem smallish memset() calls inlined to things like a simple > "store a 4-byte zero here, then another 4-byte zero, and then a 2-byte > zero". Much more efficient than any function call plus loop could ever be. Yes, that's exactly the kind of thing I meant with "optimised very aggressively". Good luck getting your compiler to manage that with your own functions... Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-20 08:05 -0700 |
| Message-ID | <2c2e8a25-3780-495a-9135-6b24d3a0a207@googlegroups.com> |
| In reply to | #108292 |
On Thursday, April 20, 2017 at 8:25:06 AM UTC-5, Richard Bos wrote:
> Ken Brody <kenbrody@spamcop.net> wrote:
>
> > On 4/14/2017 7:48 AM, Richard Bos wrote:
> > > Keith Thompson <kst-u@mib.org> wrote:
> > [...]
> > >> A call to memset() is generally preferred to an equivalent for loop,
> > >> because it's simpler and likely to be faster. Of course you have to
> > >> understand what a function does if you're going to call it.
> > >
> > > It's also relevant, here, that memset() is a Standard function, and one
> > > that can usually be optimised very agressively. If the function is user
> > > code, or less fundamental, the equation can change drastically.
> >
> > I have also seem smallish memset() calls inlined to things like a simple
> > "store a 4-byte zero here, then another 4-byte zero, and then a 2-byte
> > zero". Much more efficient than any function call plus loop could ever be.
>
> Yes, that's exactly the kind of thing I meant with "optimised very
> aggressively". Good luck getting your compiler to manage that with your
> own functions...
The godbolt compiler tester doesn't have any gcc versions for the ARM past
5.4.1, but given:
#include <string.h>
#include <stdint.h>
void test1(uint16_t *p)
{
p=(uint16_t*)(uint32_t*)p;
memset(p, 0, 8);
}
void test2(uint16_t *p)
{
for (int i=0; i<4; i++)
p[i]=0;
}
it produces better code for the second than the first. If the object is
known to be suitably aligned, it can produce even better code in the
-fno-strict-aliasing dialect, given:
void test3(uint16_t *p)
{
*(uint64_t*)p = 0;
}
On a typical current production ARM (e.g. Cortex-M0 or M3), the first
version of the code would take 7 half-words of code space and make a call
to memset. The second would take 6 half-words of code space with no
branches, calls, or loops, save for the return at the end). The third
would take four half-words of code space, again with no branches, calls,
or loops.
Perhaps there are newer versions of gcc for the ARM which would do something
decent given the first version of the code, but I've not seen any.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-20 15:32 +0000 |
| Message-ID | <nw4KA.20163$xR7.18665@fx28.iad> |
| In reply to | #108295 |
supercat@casperkitty.com writes:
>On Thursday, April 20, 2017 at 8:25:06 AM UTC-5, Richard Bos wrote:
>> Ken Brody <kenbrody@spamcop.net> wrote:
>>
>> > On 4/14/2017 7:48 AM, Richard Bos wrote:
>> > > Keith Thompson <kst-u@mib.org> wrote:
>> > [...]
>> > >> A call to memset() is generally preferred to an equivalent for loop,
>> > >> because it's simpler and likely to be faster. Of course you have to
>> > >> understand what a function does if you're going to call it.
>> > >
>> > > It's also relevant, here, that memset() is a Standard function, and one
>> > > that can usually be optimised very agressively. If the function is user
>> > > code, or less fundamental, the equation can change drastically.
>> >
>> > I have also seem smallish memset() calls inlined to things like a simple
>> > "store a 4-byte zero here, then another 4-byte zero, and then a 2-byte
>> > zero". Much more efficient than any function call plus loop could ever be.
>>
>> Yes, that's exactly the kind of thing I meant with "optimised very
>> aggressively". Good luck getting your compiler to manage that with your
>> own functions...
>
>The godbolt compiler tester doesn't have any gcc versions for the ARM past
>5.4.1, but given:
>
> #include <string.h>
> #include <stdint.h>
> void test1(uint16_t *p)
> {
> p=(uint16_t*)(uint32_t*)p;
> memset(p, 0, 8);
> }
> void test2(uint16_t *p)
> {
> for (int i=0; i<4; i++)
> p[i]=0;
> }
>
GCC 6.1 for arm64 produces:
0000000000000000 <test1>:
0: a9be7bfd stp x29, x30, [sp,#-32]!
4: 910003fd mov x29, sp
8: f9000fa0 str x0, [x29,#24]
c: d2800102 mov x2, #0x8 // #8
10: 52800001 mov w1, #0x0 // #0
14: f9400fa0 ldr x0, [x29,#24]
18: 94000000 bl 0 <memset>
1c: d503201f nop
20: a8c27bfd ldp x29, x30, [sp],#32
24: d65f03c0 ret
0000000000000028 <test2>:
28: d10083ff sub sp, sp, #0x20
2c: f90007e0 str x0, [sp,#8]
30: b9001fff str wzr, [sp,#28]
34: 14000009 b 58 <test2+0x30>
38: b9801fe0 ldrsw x0, [sp,#28]
3c: d37ff800 lsl x0, x0, #1
40: f94007e1 ldr x1, [sp,#8]
44: 8b000020 add x0, x1, x0
48: 7900001f strh wzr, [x0]
4c: b9401fe0 ldr w0, [sp,#28]
50: 11000400 add w0, w0, #0x1
54: b9001fe0 str w0, [sp,#28]
58: b9401fe0 ldr w0, [sp,#28]
5c: 71000c1f cmp w0, #0x3
60: 54fffecd b.le 38 <test2+0x10>
64: d503201f nop
68: 910083ff add sp, sp, #0x20
6c: d65f03c0 ret
changing the call to 'memset' -> '__builtin_memset' produces:
0000000000000000 <test1>:
0: d10043ff sub sp, sp, #0x10
4: f90007e0 str x0, [sp,#8]
8: f94007e0 ldr x0, [sp,#8]
c: f900001f str xzr, [x0]
10: d503201f nop
14: 910043ff add sp, sp, #0x10
18: d65f03c0 ret
000000000000001c <test2>:
1c: d10083ff sub sp, sp, #0x20
20: f90007e0 str x0, [sp,#8]
24: b9001fff str wzr, [sp,#28]
28: 14000009 b 4c <test2+0x30>
2c: b9801fe0 ldrsw x0, [sp,#28]
30: d37ff800 lsl x0, x0, #1
34: f94007e1 ldr x1, [sp,#8]
38: 8b000020 add x0, x1, x0
3c: 7900001f strh wzr, [x0]
40: b9401fe0 ldr w0, [sp,#28]
44: 11000400 add w0, w0, #0x1
48: b9001fe0 str w0, [sp,#28]
4c: b9401fe0 ldr w0, [sp,#28]
50: 71000c1f cmp w0, #0x3
54: 54fffecd b.le 2c <test2+0x10>
58: d503201f nop
5c: 910083ff add sp, sp, #0x20
60: d65f03c0 ret
>it produces better code for the second than the first.
Not if you use __builtin_memset instead of memset.
>
>Perhaps there are newer versions of gcc for the ARM which would do something
>decent given the first version of the code, but I've not seen any.
see above. Can't speak to ARMv7 object code, but ARMv8 gcc can easily
optimize out the memset.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web