Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101847 > unrolled thread
| Started by | "Fernando D. Bozzo" <fdbozzo@gmail.com> |
|---|---|
| First post | 2017-01-15 08:45 -0800 |
| Last post | 2017-01-30 05:21 -0800 |
| Articles | 20 on this page of 151 — 22 participants |
Back to article view | Back to comp.lang.c
Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 08:45 -0800
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-15 16:53 +0000
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:34 -0800
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 21:09 +0000
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 13:45 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 14:09 -0800
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 22:41 +0000
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 15:06 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 16:49 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-17 16:56 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 20:37 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-18 09:38 +0100
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:49 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-31 10:39 -0800
Re: Dinamic array without malloc - Can be done? luser droog <luser.droog@gmail.com> - 2017-01-31 10:55 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-31 11:40 -0800
Re: Dinamic array without malloc - Can be done? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-31 10:57 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 23:06 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:42 -0800
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-15 20:15 +0000
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:43 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:08 -0800
Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 12:25 -0500
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:46 -0800
Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 20:13 +0000
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:06 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:46 -0800
Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:10 -0500
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:37 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 21:02 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 04:23 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:05 +0100
Re: Dinamic array without malloc - Can be done? Ian Collins <ian-news@hotmail.com> - 2017-01-16 21:16 +1300
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:48 +0100
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:29 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:37 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:56 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 10:34 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:48 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 11:10 -0800
Re: Dinamic array without malloc - Can be done? Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-15 20:22 +0100
Re: Dinamic array without malloc - Can be done? Chad <cdalten@gmail.com> - 2017-01-15 11:50 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:12 -0800
Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 17:50 +0000
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:38 -0800
Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 19:34 +0000
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:51 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 13:10 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:23 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 18:08 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:56 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:35 -0800
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:07 -0800
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:17 -0800
Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-16 15:21 -0600
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-31 22:22 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:22 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 16:23 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 02:04 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 17:27 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 09:16 +0100
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:32 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:02 +0100
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-16 09:22 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:25 +0100
Re: Dinamic array without malloc - Can be done? Barry Schwarz <schwarzb@dqel.com> - 2017-01-15 11:53 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 12:22 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:32 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 16:01 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:19 +0100
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 11:28 +0000
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 14:29 +0100
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 15:41 +0000
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 17:27 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 07:56 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 17:31 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:48 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:29 +0100
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:25 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 12:28 -0800
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 12:38 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:57 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 00:37 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:23 +0100
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 01:35 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-16 09:15 -0800
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 01:29 +0000
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:08 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:08 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:35 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 16:31 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 09:27 +0100
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 12:11 +0000
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 14:23 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 05:38 -0800
Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 14:17 +0000
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 07:09 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 05:14 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 14:40 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 06:41 -0800
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 16:00 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 07:45 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 08:18 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 08:27 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 09:29 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 09:23 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 10:35 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 12:41 -0800
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 13:45 -0800
Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-17 21:00 -0600
Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 11:55 -0800
Re: Dinamic array without malloc - Can be done? Siri Cruise <chine.bleu@yahoo.com> - 2017-01-15 14:59 -0800
Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 20:04 +0000
Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-15 21:33 +0100
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 13:00 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:27 -0800
Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:34 -0500
Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:43 -0500
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:17 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:22 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 21:00 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:01 -0800
Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-30 11:35 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 16:18 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-02-01 16:37 -0800
Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-01 23:21 -0600
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 00:27 -0800
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-02-02 10:58 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 22:51 -0800
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-15 15:41 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:44 -0800
Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-15 16:17 -0800
Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 01:47 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 01:50 -0800
Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 02:38 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 03:15 -0800
Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 03:40 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 04:21 -0800
Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 04:29 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 04:36 -0800
Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-16 11:36 +0000
Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 03:44 -0800
Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-16 15:34 +0000
Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-16 16:01 +0000
Re: Dinamic array without malloc - Can be done? John Bode <jfbode1029@gmail.com> - 2017-01-17 10:14 -0800
Re: Dinamic array without malloc - Can be done? James Kuyper <jameskuyper@verizon.net> - 2017-01-17 13:21 -0500
Re: Dinamic array without malloc - Can be done? John Bode <jfbode1029@gmail.com> - 2017-01-17 11:43 -0800
Re: Dinamic array without malloc - Can be done? James Kuyper <jameskuyper@verizon.net> - 2017-01-17 15:07 -0500
Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 12:24 -0800
Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-17 10:24 -0800
Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:21 -0800
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-01-16 12:38 -0800 |
| Message-ID | <o5jash$q5d$1@dont-email.me> |
| In reply to | #102004 |
On 1/16/2017 12:28 PM, supercat@casperkitty.com wrote: > On Monday, January 16, 2017 at 1:25:21 PM UTC-6, Chris M. Thomasson wrote: >> Actually, this brings back a database like mutex based technique that >> can atomically lock multiple records/objects, at once, akin to lock >> based transactional memory IIRC, the deadlock avoiding locking pattern >> can be outfitted with rwlocks instead of mutex... > > If two threads tried to use the same LIFO memory manager and one thread > were holding some LIFO-managed storage when the second thread acquired > some of its own, the first thread would not be able to release its > storage until the second thread released its storage. Not a particularly > nice arrangement. LIFO atomic stack is still in IBM Principles of Operation. Very nice. http://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1 Under Multi programming and Multiprocessing A-43 -> Free Pool Manipulation A-48 Also, check out PLO. A-50 > > A much better arrangement would be for each thread to have its own > independent LIFO memory manager. Agreed! > Provided that the system supported > some efficient means of declaring "thread-static" variables, such an > approach would eliminate the need for any kind of locking or other > coordination. fwiw, I remember getting permission to post this diagram: http://webpages.charter.net/appcore/vzoom/msgsys.pdf
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-15 16:57 -0800 |
| Message-ID | <lnshojg6tf.fsf@kst-u.example.com> |
| In reply to | #101895 |
"Fernando D. Bozzo" <fdbozzo@gmail.com> writes:
[...]
> I'm doing a practice on which I have to "fix" a copy of apache 2.2 (http://httpd.apache.org/docs/2.2/mod/core.html) that have some methods taked out, and I must to reprogram them following some directions given in the course (validations and the like).
[...]
Please limit your lines to less than 80 columns, preferably less than
72, by inserting hard line breaks if necessary. It makes your text
easier to read. I see you're using Google Groups, but many newsreaders
either don't wrap long lines, or wrap them but not necessarily on word
boundaries.
--
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 | "Fernando D. Bozzo" <fdbozzo@gmail.com> |
|---|---|
| Date | 2017-01-16 00:37 -0800 |
| Message-ID | <862ec045-5574-4d39-96e1-b72402df4154@googlegroups.com> |
| In reply to | #101906 |
El lunes, 16 de enero de 2017, 1:57:29 (UTC+1), Keith Thompson escribió: > "Fernando D. Bozzo" writes: > [...] > > I'm doing a practice on which I have to "fix" a copy of apache 2.2 (http://httpd.apache.org/docs/2.2/mod/core.html) that have some methods taked out, and I must to reprogram them following some directions given in the course (validations and the like). > [...] > > Please limit your lines to less than 80 columns, preferably less than > 72, by inserting hard line breaks if necessary. It makes your text > easier to read. I see you're using Google Groups, but many newsreaders > either don't wrap long lines, or wrap them but not necessarily on word > boundaries. > Hi Keith: I will try to format manually, sorry. And yes, I'm using Google Groups
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-16 10:23 +0100 |
| Message-ID | <o5i3at$45j$1@dont-email.me> |
| In reply to | #101933 |
On 16/01/17 09:37, Fernando D. Bozzo wrote: > El lunes, 16 de enero de 2017, 1:57:29 (UTC+1), Keith Thompson > escribió: >> Please limit your lines to less than 80 columns, preferably less >> than 72, by inserting hard line breaks if necessary. It makes your >> text easier to read. I see you're using Google Groups, but many >> newsreaders either don't wrap long lines, or wrap them but not >> necessarily on word boundaries. >> > > > Hi Keith: > > I will try to format manually, sorry. And yes, I'm using Google > Groups > Google groups is useful if you need to search the history of groups, or very occasionally visit a group. But if you are using Usenet regularly, you really should get a proper newsreader and a proper news account. There are many possibilities here, and a discussion is way off-topic for the group. But one popular combination that is completely free and works on any system is Thunderbird for the newsreader, and news.eternal-september.org as the newsserver. Once you try these, you will never want to touch Google Groups again, and other people reading your posts will be happier.
[toc] | [prev] | [next] | [standalone]
| From | "Fernando D. Bozzo" <fdbozzo@gmail.com> |
|---|---|
| Date | 2017-01-16 01:35 -0800 |
| Message-ID | <0e1c4c9d-9051-4663-abfc-968aa98c1dd1@googlegroups.com> |
| In reply to | #101939 |
Hi David: I use Google Groups a lot, because I'm in many groups, and I prefer mobility. I use them at home, at work and even when taking the bus or train on the mobile or tablet.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-16 09:15 -0800 |
| Message-ID | <lnziirdiz7.fsf@kst-u.example.com> |
| In reply to | #101940 |
"Fernando D. Bozzo" <fdbozzo@gmail.com> writes:
> I use Google Groups a lot, because I'm
> in many groups, and I prefer mobility.
> I use them at home, at work and even
> when taking the bus or train on the
> mobile or tablet.
I've replied with some suggestions by e-mail.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-16 01:29 +0000 |
| Message-ID | <o5h7jk$977$1@dont-email.me> |
| In reply to | #101895 |
On 15/01/2017 23:32, Fernando D. Bozzo wrote:
> I'm doing a practice on which I have to "fix" a copy of apache 2.2 (http://httpd.apache.org/docs/2.2/mod/core.html) that have some methods taked out, and I must to reprogram them following some directions given in the course (validations and the like).
>
> One of those methods is the "parse" method, that receives the input line that I need to parse, something like:
>
> GET /public/cat.html HTTP/1.1
>
>
> So the VLAs I'm using are to make some string operations on a copy of this line to get back into parts (command, path, file and Http version)
>
> As you can see, the size of data is small, can't be more than a couple of 100s chars, and that's why I didn't want to use malloc. I reserve the use of dynamic memory for when I really need a big size, but for less than 8 MB I think that is a waste of time and make the modifications a little more complicated than what I need.
It's no longer clear whether you need what is normally called a dynamic
array. The array declared here:
void fn (void){
char buffer[1000];
}
has a fixed size but is dynamic in that the 1000 bytes aren't allocated
until the function is called.
As supercat said, you might be able to get away with just allocating a
buffer with a fixed upper limit. Then you don't need to get involved
with VLAs. But you will need to check you don't exceed the limit that is
set.
With input line handling, there is always the possibility that people
may type in very long lines, or more likely they could redirect input to
come from a file, perhaps a binary file, that could give 100M bytes of
input without a line break.
In that case, a VLA that can adapt /might/ be better, but if the stack
size is 8MB, and the line that is submitted is more 8M characters, that
can cause a crash. And it's difficult to test for that before the VLA is
declared, as there is no easy way of finding out how much stack is left.
Here malloc would be better as, first, it can have access to GB of data,
and second you can check for an error return.
But for processing short lines like your example, a safer way is to use
a fixed-size array, or to use a VLA but first check the length is
unlikely to cause a problem. However, if there is only 512 bytes of
stack left, and your limit is 1024 bytes, both will crash!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-16 10:08 +0100 |
| Message-ID | <o5i2g7$1la$1@dont-email.me> |
| In reply to | #101870 |
On 15/01/17 20:53, Barry Schwarz wrote: > On Sun, 15 Jan 2017 10:38:17 -0800 (PST), "Fernando D. Bozzo" > <fdbozzo@gmail.com> wrote: > >> El domingo, 15 de enero de 2017, 18:50:39 (UTC+1), Richard >> Heathfield escribió: <snip> >>> Why don't you want to use malloc? >>> >> >> >> Hi Richard, the reason is just to simplify the garbage collection >> automatically, and not needing to free() manually at some point. If >> I could use some mechanism like try/catch then this could not be a >> problem, but without it it makes more difficult to manage the flow >> of a program. >> >> May be is the little practice I have until now, but for small >> arrays (<1MB) could be a good idea. > > Why do you think the garbage collection performed when the VLA is > destroyed is any simpler then the garbage collection performed when > allocated memory is freed? Perhaps he thinks it is the case, because it is true? It is easier for the programmer - you just end the block, rather than having to free the pointer. It is more efficient at run-time in the code - allocation is typically just adding/subtracting a size value to the stack pointer, and deallocation is reversing that operation (if it is needed at all - often that will be combined with the rest of the function epilogue). > Are you aware that you cannot extend (or > shrink) a VLA while the size of an allocated array can be adjusted > by realloc? I am sure he is aware that a VLA is not the same thing as using malloc. > > Since the "stack" is usually smaller than the "heap", using a VLA in > a recursive function can lead to problems sooner than using malloc. > > I am curious how the choice of allocation method can affect the flow > of your program. Could you give an example. I realize that one > approach calls malloc which is outside your code. But I'm pretty > certain the code generated by the definition of the VLA will do a > lot of processing unrelated to any executable statements you have > coded. It may even call malloc for you. It is highly unlikely that using a VLA will call malloc. (It is not impossible - someone mentioned that this is done on some 8051 compilers. But there we are talking about very limited processors with no decent data stack support.) > > The frequently cited quote about premature optimization springs > unbidden to mind. > I wonder if you know what VLA's actually are.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-16 08:08 -0800 |
| Message-ID | <1b6f41e5-41b9-4529-a75c-38673131ed16@googlegroups.com> |
| In reply to | #101937 |
On Monday, January 16, 2017 at 3:09:03 AM UTC-6, David Brown wrote: > It is highly unlikely that using a VLA will call malloc. (It is not > impossible - someone mentioned that this is done on some 8051 compilers. > But there we are talking about very limited processors with no decent > data stack support.) It is also done on current Keil compilers for the ARM (which is hadly what I would call a "very limited processor with no decent data stack support"). Whether that is better or worse than trying to allocate the arrays on the stack would depend upon usage patterns, though the design does mean that a request to allocate more space than is available is more likely to result in a hard fault than in arbitrary data corruption. Neither failure is good, of course, but in an embedded system the former is often much preferable to the latter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 00:35 +0100 |
| Message-ID | <o5jl8j$29l$1@dont-email.me> |
| In reply to | #101972 |
On 16/01/17 17:08, supercat@casperkitty.com wrote: > On Monday, January 16, 2017 at 3:09:03 AM UTC-6, David Brown wrote: >> It is highly unlikely that using a VLA will call malloc. (It is not >> impossible - someone mentioned that this is done on some 8051 compilers. >> But there we are talking about very limited processors with no decent >> data stack support.) > > It is also done on current Keil compilers for the ARM (which is hadly what > I would call a "very limited processor with no decent data stack support"). That surprises me. However, my limited experience of Keil for the 8051 does not inspire confidence in the quality of their tools, and my understanding is that ARM is moving from Keil's tools to clang for the "official" ARM compiler (as well as giving enormous support to gcc for ARM). If I choose to use a VLA or alloca() instead of malloc(), it is because I think a stack-based allocation is a better choice. I can understand the compiler generating a malloc-like call on a target that basically does not have a data stack, but not for the ARM. It is like asking for "x * y" and finding the compiler generates a loop that adds "x" together "y" times. Technically, it may be correct code - but it is far from what I want. > Whether that is better or worse than trying to allocate the arrays on the > stack would depend upon usage patterns, though the design does mean that a > request to allocate more space than is available is more likely to result > in a hard fault than in arbitrary data corruption. Neither failure is good, > of course, but in an embedded system the former is often much preferable to > the latter. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-16 16:31 -0800 |
| Message-ID | <81c89a92-ff50-445c-bdef-8e9e2a915799@googlegroups.com> |
| In reply to | #102012 |
On Monday, January 16, 2017 at 5:35:21 PM UTC-6, David Brown wrote: > On 16/01/17 17:08, supercat wrote: > > It is also done on current Keil compilers for the ARM (which is hadly what > > I would call a "very limited processor with no decent data stack support"). > > That surprises me. However, my limited experience of Keil for the 8051 > does not inspire confidence in the quality of their tools, and my > understanding is that ARM is moving from Keil's tools to clang for the > "official" ARM compiler (as well as giving enormous support to gcc for ARM). What complaints to you have about the 8051 Keil? To be sure, it processes a non-standard dialect of C because such a dialect is a better fit for the target than a conforming dialect could be, but I'd rather have a compiler implement a useful dialect than a conforming-but-useless one. For most compilers I use, I can think of at least one bug that I've encountered. The Keil is one of four I can think of for which none come to mind (as compared with CCS compiler for the PIC which miscomputed jump targets, HiTech compiler for the PIC which mis-set banking bits, MPW compiler for the Macintosh which miscomputed stack frame sizes between 32K and 64K, Turbo C for the PC whose floating-point formatting is buggy, gcc which optimizes out memmove() even in cases where its presence is needed to make code have defined behavior, and then uses the lack of the memmove as a basis for treating code as having Undefined Behavior, clang which doesn't recognize aliasing of objects accessed through unions, etc.) What don't you like about it?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 09:27 +0100 |
| Message-ID | <o5kkf0$hpl$1@dont-email.me> |
| In reply to | #102015 |
On 17/01/17 01:31, supercat@casperkitty.com wrote: > On Monday, January 16, 2017 at 5:35:21 PM UTC-6, David Brown wrote: >> On 16/01/17 17:08, supercat wrote: >>> It is also done on current Keil compilers for the ARM (which is hadly what >>> I would call a "very limited processor with no decent data stack support"). >> >> That surprises me. However, my limited experience of Keil for the 8051 >> does not inspire confidence in the quality of their tools, and my >> understanding is that ARM is moving from Keil's tools to clang for the >> "official" ARM compiler (as well as giving enormous support to gcc for ARM). > > What complaints to you have about the 8051 Keil? Most of my experience with Keil's 8051 compiler is in the form of colleagues asking me if their C code is wrong or if the incorrect object code is a compiler issue. In almost all cases, it is the later. I don't have a list of the bugs, but there are many - my colleagues who use the tool have to program in a special manner avoiding perfectly normal C constructs because the compiler gets them wrong. Sometimes this seems to be intentional from Keil, to make the compiler work like they think programmers might expect, rather than how C works. So if you have: uint8_t a = 200; uint8_t b = 100; uint16_t c = a + b; Keil will make c equal to 44 because it does not do integer promotion. I don't know whether the Keil compiler folks think their users expect 8-bit arithmetic here without promotion, or they just can't write an optimiser that generates good /correct/ code here. > To be sure, it processes > a non-standard dialect of C because such a dialect is a better fit for the > target than a conforming dialect could be, but I'd rather have a compiler > implement a useful dialect than a conforming-but-useless one. I can understand that the compiler has to have plenty of extensions to generate efficient code on such a limited processor, and also that it does not follow C standards everywhere. For example, it is perfectly reasonable that "double" is 32-bit in the compiler. But it has /many/ bugs generating incorrect code, and breaks rules for no reason. You can't use it to program in C - you can only use it to program in Keil-C. It's the kind of crap I had to deal with 20 years ago, and should not exist today - and certainly not at the absurd prices they charge. But because you can only program it in Keil-C, and because some SoC's still have 8051 cores and the manufacturers release their essential code and libraries in Keil-C, people are stuck with it.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-17 12:11 +0000 |
| Message-ID | <o5l1im$q9o$1@dont-email.me> |
| In reply to | #102029 |
On 17/01/2017 08:27, David Brown wrote: > On 17/01/17 01:31, supercat@casperkitty.com wrote: >> What complaints to you have about the 8051 Keil? > > Most of my experience with Keil's 8051 compiler is in the form of > colleagues asking me if their C code is wrong or if the incorrect object > code is a compiler issue. In almost all cases, it is the later. I > don't have a list of the bugs, but there are many - my colleagues who > use the tool have to program in a special manner avoiding perfectly > normal C constructs because the compiler gets them wrong. > > Sometimes this seems to be intentional from Keil, to make the compiler > work like they think programmers might expect, rather than how C works. > So if you have: > > uint8_t a = 200; > uint8_t b = 100; > uint16_t c = a + b; > > Keil will make c equal to 44 because it does not do integer promotion. That seems reasonable to me, if this is an 8-bit processor that would struggle with 16-bit arithmetic. Would promoting /all/ 8-bit operations to 16-bit really be a good idea on such a processor? Just write: c = (uint16_t)a+b. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 14:23 +0100 |
| Message-ID | <o5l5qc$8oo$1@dont-email.me> |
| In reply to | #102034 |
On 17/01/17 13:11, BartC wrote: > On 17/01/2017 08:27, David Brown wrote: >> On 17/01/17 01:31, supercat@casperkitty.com wrote: > >>> What complaints to you have about the 8051 Keil? >> >> Most of my experience with Keil's 8051 compiler is in the form of >> colleagues asking me if their C code is wrong or if the incorrect object >> code is a compiler issue. In almost all cases, it is the later. I >> don't have a list of the bugs, but there are many - my colleagues who >> use the tool have to program in a special manner avoiding perfectly >> normal C constructs because the compiler gets them wrong. >> >> Sometimes this seems to be intentional from Keil, to make the compiler >> work like they think programmers might expect, rather than how C works. >> So if you have: >> >> uint8_t a = 200; >> uint8_t b = 100; >> uint16_t c = a + b; >> >> Keil will make c equal to 44 because it does not do integer promotion. > > That seems reasonable to me, if this is an 8-bit processor that would > struggle with 16-bit arithmetic. > > Would promoting /all/ 8-bit operations to 16-bit really be a good idea > on such a processor? Yes, it would be an excellent idea - because this is supposed to be a /C/ compiler. I would expect the compiler to do the operation logically as 16-bit integers, but generate code to use a single 8-bit addition along with whatever instructions are must efficient to generate the high byte from the carry. If I wanted an 8-bit result, I would have written: c = (uint8_t) (a + b); (or simply declared c as uint8_t). And then I would have expected the compiler to still do the operation logically as the addition of two 16-bit signed ints, but in practice optimise to a single 8-bit addition. That's the way C works - for better or for worse - and it is the way a C programmer expects their C compilers to work. > > Just write: c = (uint16_t)a+b. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-17 05:38 -0800 |
| Message-ID | <0d97ccb9-af2e-496d-b0e5-15bdd33d9735@googlegroups.com> |
| In reply to | #102034 |
On Tuesday, January 17, 2017 at 6:11:42 AM UTC-6, Bart wrote:
> That seems reasonable to me, if this is an 8-bit processor that would
> struggle with 16-bit arithmetic.
>
> Would promoting /all/ 8-bit operations to 16-bit really be a good idea
> on such a processor?
>
> Just write: c = (uint16_t)a+b.
Given:
uint8_t a,b,c,d,e;
uint16_t i;
...
c=a+b;
i=d+e;
a compiler can very easily recognize that the assignment to "c" does not
make any use of the high byte of a+b, and as a consequence need not bother
to calculate it. Since the assignment to "i" would make use of the high
byte, however, it would need to be calculated.
The way C's promotion rules work with signed and unsigned numbers is nasty
bit of kludgery which results in some measure from the fact that long and
unsigned integer types were not designed into the language from the start
and they were added to different platforms without any coherent vision for
how they should behave. C's original vision was that all operations on
integers would behave as though promoted to the longest integer type. If
there had been separate "number" types which eagerly promote, and "wrapping"
types which never do, code could have been far more portable and I don't
think it would have particularly hurt efficiency. Given something like:
uint16_t x,y,z;
z = (x*y)>>4;
there are three ways that code might be interpreted:
1. Perform the multiplication, truncate the result to 16 bits, and then
shift it by four.
2. Perform the multiplication as though using the largest possible
integer type and then shift it by 4.
3. Perform the multiplication using the most convenient type that's at
least 16 bits and shift it by 4.
Having explicit promoting and non-promoting types, with the semantics that
a compiler would use #2 with promoting types and #1 with non-promoting
types, would allow behavior to be independent of the target system. While
code would be less efficient on 16-bit systems than would be possible if
#3 were allowed, having compilers use a safe approach except when code says
an alternative is acceptable would seem more amenable to portability than
having a language tend toward approach #3.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-17 14:17 +0000 |
| Message-ID | <o5l8uc$jnh$1@dont-email.me> |
| In reply to | #102039 |
On 17/01/2017 13:38, supercat@casperkitty.com wrote:
> On Tuesday, January 17, 2017 at 6:11:42 AM UTC-6, Bart wrote:
>> That seems reasonable to me, if this is an 8-bit processor that would
>> struggle with 16-bit arithmetic.
>>
>> Would promoting /all/ 8-bit operations to 16-bit really be a good idea
>> on such a processor?
>>
>> Just write: c = (uint16_t)a+b.
>
> Given:
> uint8_t a,b,c,d,e;
> uint16_t i;
> ...
> c=a+b;
> i=d+e;
>
> a compiler can very easily recognize that the assignment to "c" does not
> make any use of the high byte of a+b, and as a consequence need not bother
> to calculate it. Since the assignment to "i" would make use of the high
> byte, however, it would need to be calculated.
It's easy in that example. But it is possible to construct more
elaborate ones:
c = (........... (a+b) ..........);
Here you have to imagine that this has dozens of terms and the (a+b) is
buried several levels deep. Now change the lhs to:
i = (........... (a+b) ..........);
Now, it's now longer easy to tell whether the sphere of influence of the
left-hand-side's type extends as far as (a+b).
And even if it did, this may be undesirable: a particular sub-expression
is known to be working perfectly, it may in fact have been lifted from
working code elsewhere, but now its internal behaviour may be
compromised by what is happening far outside it.
And then what if the left hand side is 'i = c = ...' or 'c = i = ...'?
The order of i and c will affect the evaluation of the rhs.
Imagine, also, if the right-hand-side was encapsulated in a function:
c = f(...);
i = f(...);
Clearly f must return the same type and same result in both cases.
So the rules need to be simpler. Terms need to be more self-contained.
>
> The way C's promotion rules work with signed and unsigned numbers is nasty
> bit of kludgery which results in some measure from the fact that long and
> unsigned integer types were not designed into the language from the start
> and they were added to different platforms without any coherent vision for
> how they should behave. C's original vision was that all operations on
> integers would behave as though promoted to the longest integer type. If
> there had been separate "number" types which eagerly promote, and "wrapping"
> types which never do, code could have been far more portable and I don't
> think it would have particularly hurt efficiency. Given something like:
>
> uint16_t x,y,z;
> z = (x*y)>>4;
>
> there are three ways that code might be interpreted:
>
> 1. Perform the multiplication, truncate the result to 16 bits, and then
> shift it by four.
>
> 2. Perform the multiplication as though using the largest possible
> integer type and then shift it by 4.
>
> 3. Perform the multiplication using the most convenient type that's at
> least 16 bits and shift it by 4.
>
> Having explicit promoting and non-promoting types, with the semantics that
> a compiler would use #2 with promoting types and #1 with non-promoting
> types, would allow behavior to be independent of the target system.
Again, I think it needs to be kept simple with casts used to control
behaviour.
(I came across this when implementing byte-code with dynamic typing.
When evaluating then '(a+b)' part of of '(a+b)*c', it doesn't know what
the type of c is. 'a+b' must be done in a self-contained manner. If it
turns out that a+b is int, and c is float, /then/ the conversions can be
done (eg. a+b is floated).
But it was desirable that if code works one way when dynamic, then the
same expression could work the same way when static. And C I think works
largely this way, as sub-expressions are evaluated independently of what
the types might be immediately outside.)
--
Bartc
While
> code would be less efficient on 16-bit systems than would be possible if
> #3 were allowed, having compilers use a safe approach except when code says
> an alternative is acceptable would seem more amenable to portability than
> having a language tend toward approach #3.
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-17 07:09 -0800 |
| Message-ID | <1d649b4b-a618-4748-bac8-8eef9ec574be@googlegroups.com> |
| In reply to | #102042 |
On Tuesday, January 17, 2017 at 8:17:25 AM UTC-6, Bart wrote: > On 17/01/2017 13:38, supercat wrote: > > Given: > > uint8_t a,b,c,d,e; > > uint16_t i; > > ... > > c=a+b; > > i=d+e; > > > > a compiler can very easily recognize that the assignment to "c" does not > > make any use of the high byte of a+b, and as a consequence need not bother > > to calculate it. Since the assignment to "i" would make use of the high > > byte, however, it would need to be calculated. > > It's easy in that example. But it is possible to construct more > elaborate ones: > > c = (........... (a+b) ..........); > > Here you have to imagine that this has dozens of terms and the (a+b) is > buried several levels deep. Now change the lhs to: > > i = (........... (a+b) ..........); > > Now, it's now longer easy to tell whether the sphere of influence of the > left-hand-side's type extends as far as (a+b). The only difficult cases are those which involve division, remainder, right-shift, and relational operators. If I were designing a language, I might be inclined to require that the left-hand operand of such operators be explicitly cast in some cases where the left-hand side includes a left shift, but in other cases it's not hard to determine pretty well what level of precision would be needed at each step. > And even if it did, this may be undesirable: a particular sub-expression > is known to be working perfectly, it may in fact have been lifted from > working code elsewhere, but now its internal behaviour may be > compromised by what is happening far outside it. If a language always behaves as though integer operations promote to the maximum integer precision, and floating-point operations do likewise (C, as originally designed, did both those things) then the behavior of an expression would not be affected by context. A compiler might evaluate the operands at a smaller size in some contexts than in others, but only in cases where it wouldn't affect the result. > And then what if the left hand side is 'i = c = ...' or 'c = i = ...'? > The order of i and c will affect the evaluation of the rhs. No differently from how it would under today's rules. > Imagine, also, if the right-hand-side was encapsulated in a function: > > c = f(...); > i = f(...); > > Clearly f must return the same type and same result in both cases. The result would be as though the expression were cast to the function's return type. > So the rules need to be simpler. Terms need to be more self-contained. Simple rule, if designing a language from scratch: all computations involving integer number bytes behave as though computed using the largest such type. Explicit conversions would be required when using wrapping type in cases where evaluation as larger types could set the upper bits in a way that would not be ignored by an outer expression. Thus, given: wrap8_t a,b; wrap16_t i; ... a=i+b; // Add lower half of i to a (no cast required) i=a+b; // Syntax error (8-bit and 16-bit arithmetic yield different result) i=(wrap16_t)(a+b); // Syntax error (same as above) i=(wrap16_t)a+b; // Perform add as 16 bits i=(wrap8_t)(a+b); // Perform add as 8 bits, then zero-pad i=a & b; // Acceptable (result unaffected by use of 16-bit operation) i=~a; // Syntax error (result affected by use of 16-bit operation) i=a & j; // Acceptable i=a | j; // Unacceptable > > The way C's promotion rules work with signed and unsigned numbers is nasty > > bit of kludgery which results in some measure from the fact that long and > > unsigned integer types were not designed into the language from the start > > and they were added to different platforms without any coherent vision for > > how they should behave. > Again, I think it needs to be kept simple with casts used to control > behaviour. > > (I came across this when implementing byte-code with dynamic typing. > When evaluating then '(a+b)' part of of '(a+b)*c', it doesn't know what > the type of c is. 'a+b' must be done in a self-contained manner. If it > turns out that a+b is int, and c is float, /then/ the conversions can be > done (eg. a+b is floated). Basically promote everything to the largest integer type. That's fine from a language rule except in cases needing wrapping modular arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-17 05:14 -0800 |
| Message-ID | <1202e0d3-d4e0-4693-a5ce-357700757692@googlegroups.com> |
| In reply to | #102029 |
On Tuesday, January 17, 2017 at 2:27:52 AM UTC-6, David Brown wrote: > Sometimes this seems to be intentional from Keil, to make the compiler > work like they think programmers might expect, rather than how C works. > So if you have: > > uint8_t a = 200; > uint8_t b = 100; > uint16_t c = a + b; > > Keil will make c equal to 44 because it does not do integer promotion. > I don't know whether the Keil compiler folks think their users expect > 8-bit arithmetic here without promotion, or they just can't write an > optimiser that generates good /correct/ code here. Microchip's early so-called "C" compilers worked that way, but none of the versions of Keil I used ever did. The biggest issue I've encountered when working with Keil on the 8051 stems from the existence of multiple address spaces and the use of pointer qualifiers to access them. Even here, though, in all of the modes I've used Keil tends to treat unqualified pointers as three-byte "pointer to anywhere" type that can only be accessed using library routines for that purpose. Horribly slow and inefficient but I don't really know much alternative given the architecture. Using qualified pointer types makes things much faster, but if a function is written to take a pointer to an object in the IDATA region and one passes it a pointer to something in the CODE region, it's going to access the wrong thing; while the Standard does not anticipate the need to use proper qualifiers I still wouldn't say such issues are the compilers fault. > > To be sure, it processes > > a non-standard dialect of C because such a dialect is a better fit for the > > target than a conforming dialect could be, but I'd rather have a compiler > > implement a useful dialect than a conforming-but-useless one. > > I can understand that the compiler has to have plenty of extensions to > generate efficient code on such a limited processor, and also that it > does not follow C standards everywhere. For example, it is perfectly > reasonable that "double" is 32-bit in the compiler. But it has /many/ > bugs generating incorrect code, and breaks rules for no reason. You > can't use it to program in C - you can only use it to program in Keil-C. > It's the kind of crap I had to deal with 20 years ago, and should not > exist today - and certainly not at the absurd prices they charge. Compiler prices are absurd, and price does not always translate to quality. On the other hand, when you say such things shouldn't exist today, what would you suggest as alternative for writing code for a piece of 8051-based hardware that already exists? I don't think I'll ever again pick an 8051 core for any future systems I do, but if I had a compiler that was just like the one I used 20 years ago but which worked on Windows 7 I can't think of a whole lot of improvements I'd want to make. Sure there are some places where the Keil compiler's code would be 3x as slow as optimal assembly, but the solution to that is to write a small amount of assembly code to help the compiler out. Writing 2000 lines of C and 200 lines of assembly is a lot easier than writing 5000+ lines of assembly. > But because you can only program it in Keil-C, and because some SoC's > still have 8051 cores and the manufacturers release their essential code > and libraries in Keil-C, people are stuck with it. The limitations of the 8051 architecture are the fault of Intel, not Keil. Maybe you had a different version of Keil from what I used, but I had no complaints about mine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 14:40 +0100 |
| Message-ID | <o5l6pt$c3h$1@dont-email.me> |
| In reply to | #102035 |
On 17/01/17 14:14, supercat@casperkitty.com wrote: > On Tuesday, January 17, 2017 at 2:27:52 AM UTC-6, David Brown wrote: >> Sometimes this seems to be intentional from Keil, to make the compiler >> work like they think programmers might expect, rather than how C works. >> So if you have: >> >> uint8_t a = 200; >> uint8_t b = 100; >> uint16_t c = a + b; >> >> Keil will make c equal to 44 because it does not do integer promotion. >> I don't know whether the Keil compiler folks think their users expect >> 8-bit arithmetic here without promotion, or they just can't write an >> optimiser that generates good /correct/ code here. > > Microchip's early so-called "C" compilers worked that way, but none of the > versions of Keil I used ever did. Microchip's early compilers were appalling - huge prices for a tool that could not manage an array of structs or a struct with an array, and required so much hand-optimising of the C code that you might as well write in assembly. I don't know what version of Keil is involved here. I also don't remeber the details here, and I don't have the tool on my systems to test it. > The biggest issue I've encountered when > working with Keil on the 8051 stems from the existence of multiple address > spaces and the use of pointer qualifiers to access them. Even here, though, > in all of the modes I've used Keil tends to treat unqualified pointers as > three-byte "pointer to anywhere" type that can only be accessed using library > routines for that purpose. Horribly slow and inefficient but I don't really > know much alternative given the architecture. Using qualified pointer types > makes things much faster, but if a function is written to take a pointer to > an object in the IDATA region and one passes it a pointer to something in the > CODE region, it's going to access the wrong thing; while the Standard does > not anticipate the need to use proper qualifiers I still wouldn't say such > issues are the compilers fault. I don't blame the compiler for generating slow code on the rotten processor architecture that was an outdated design when it was created some 35 years ago. And it's fair enough that you need compiler extensions and special pointer types to get the best out of the device. But I /do/ blame the compiler for generating incorrect code that does not follow the rules of C. (I also blame the thoughtless SoC hardware designers that think the 8051 is a sane choice of core when they want to add a small cpu to their chips.) > >>> To be sure, it processes >>> a non-standard dialect of C because such a dialect is a better fit for the >>> target than a conforming dialect could be, but I'd rather have a compiler >>> implement a useful dialect than a conforming-but-useless one. >> >> I can understand that the compiler has to have plenty of extensions to >> generate efficient code on such a limited processor, and also that it >> does not follow C standards everywhere. For example, it is perfectly >> reasonable that "double" is 32-bit in the compiler. But it has /many/ >> bugs generating incorrect code, and breaks rules for no reason. You >> can't use it to program in C - you can only use it to program in Keil-C. >> It's the kind of crap I had to deal with 20 years ago, and should not >> exist today - and certainly not at the absurd prices they charge. > > Compiler prices are absurd, and price does not always translate to quality. /Some/ compiler prices are absurd. Others are quite reasonable, and some are high and yet still good value for money. > On the other hand, when you say such things shouldn't exist today, what > would you suggest as alternative for writing code for a piece of 8051-based > hardware that already exists? The "best" choice would depend on the circumstances. If you have to work with code already designed for Keil, then Keil will be the best choice if you can afford it - because the code is already in Keil-C rather than C. For an unrestrained choice, then there are alternatives like IAR, Tasking, and of course SDCC. I have no experience with any of them, and cannot comment on them. But whether or not there are better alternatives, the kind of bug I have had to deal with in Keil 8051 should not be in a modern compiler. With the prices they charge, they should be expected to have comprehensive test suites and correct behaviour in almost all code. > I don't think I'll ever again pick an 8051 > core for any future systems I do, but if I had a compiler that was just like > the one I used 20 years ago but which worked on Windows 7 I can't think of > a whole lot of improvements I'd want to make. Sure there are some places > where the Keil compiler's code would be 3x as slow as optimal assembly, but > the solution to that is to write a small amount of assembly code to help > the compiler out. Writing 2000 lines of C and 200 lines of assembly is a > lot easier than writing 5000+ lines of assembly. Certainly maintaining the C is easier than maintaining assembly. And correctness trumps efficiency every time. > >> But because you can only program it in Keil-C, and because some SoC's >> still have 8051 cores and the manufacturers release their essential code >> and libraries in Keil-C, people are stuck with it. > > The limitations of the 8051 architecture are the fault of Intel, not Keil. > Maybe you had a different version of Keil from what I used, but I had no > complaints about mine. > My experience with Keil is mostly limited to helping others determine if the bug is in their code or the compiler, which of course makes me very biased - I have only seen the tool at its worst.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-17 06:41 -0800 |
| Message-ID | <39157dd8-afc2-4197-a0cc-bd5f91282d90@googlegroups.com> |
| In reply to | #102040 |
On Tuesday, January 17, 2017 at 7:40:53 AM UTC-6, David Brown wrote: > On 17/01/17 14:14, supercat wrote: > > Microchip's early so-called "C" compilers worked that way, but none of the > > versions of Keil I used ever did. > > Microchip's early compilers were appalling - huge prices for a tool that > could not manage an array of structs or a struct with an array, and > required so much hand-optimising of the C code that you might as well > write in assembly. I used to use the CCS Compiler for the PICs. Its dialect of C was goofier that Microchip's [type "short" being ONE bit!? C'mon!] but coding for it was easier than coding in assembly. I jumped ship on it when some bugs appeared I couldn't code around (if a compiler randomly miscomputes the target addresses of jumps there's really not much a programmer can do). > I don't know what version of Keil is involved here. I also don't > remeber the details here, and I don't have the tool on my systems to > test it. Fair enough. Was it 20+ years ago? I did my first major project using Keil-51 around 1995. The compiler had been sold as a "pro" version of Archimedes by the makers of that product, but I don't know that there was anything different from the ordinary Keil compiler apart from the branding. > I don't blame the compiler for generating slow code on the rotten > processor architecture that was an outdated design when it was created > some 35 years ago. And it's fair enough that you need compiler > extensions and special pointer types to get the best out of the device. > > But I /do/ blame the compiler for generating incorrect code that does > not follow the rules of C. If I had noticed such things, I would have shared your view. All I can figure is that you were using a different version than I was. If that is the case, I'm not sure that your views of Keil from back then should negatively affect your views of the company today. > (I also blame the thoughtless SoC hardware designers that think the 8051 > is a sane choice of core when they want to add a small cpu to their chips.) I hear you on that one. While Intel made some dubious design choices in the 8051, the architecture is reasonably practical for the kinds of things one would do in machine language with a microcontroller that only needs 256 bytes of RAM. When I first started working with the 8051 and heard that there was a C compiler for it, I found the concept unbelievable given its many disjoint forms of memory addressing; when I started programming it in C some years later, I was surprised to find it was surprisingly workable (though I suspect my background in 8051 assembly language helped a lot). As for why SoC vendors would be using it, all I can figure is that it's cheap. I have at times wondered, though, what it would take to develop an open-source 8-bit core that was better and cheaper, that vendors could use instead. I think the concept of addressing regions is a good thing (and even compilers for the ARM could benefit if the ABI would recognize such a thing!) but hardware should support a universal-pointer type. > > Compiler prices are absurd, and price does not always translate to quality. > > /Some/ compiler prices are absurd. Others are quite reasonable, and > some are high and yet still good value for money. I should have said compiler pricING is absurd. Some compilers are reasonable, and are absurdly cheap, but I can identify no rhyme or reason to how things are priced. > > On the other hand, when you say such things shouldn't exist today, what > > would you suggest as alternative for writing code for a piece of 8051-based > > hardware that already exists? > > The "best" choice would depend on the circumstances. If you have to > work with code already designed for Keil, then Keil will be the best > choice if you can afford it - because the code is already in Keil-C > rather than C. For an unrestrained choice, then there are alternatives > like IAR, Tasking, and of course SDCC. I have no experience with any of > them, and cannot comment on them. Never used those, though I found Keil's tools a little nicer than IAR's for the ARM. > But whether or not there are better alternatives, the kind of bug I have > had to deal with in Keil 8051 should not be in a modern compiler. With > the prices they charge, they should be expected to have comprehensive > test suites and correct behaviour in almost all code. Does Keil's 8051 compiler *presently* behave as you describe? > > The limitations of the 8051 architecture are the fault of Intel, not Keil. > > Maybe you had a different version of Keil from what I used, but I had no > > complaints about mine. > > My experience with Keil is mostly limited to helping others determine if > the bug is in their code or the compiler, which of course makes me very > biased - I have only seen the tool at its worst. Another possibility, btw, is that the compiler might offer options for things like integer promotions, and people might be using projects where they are set in non-standard fashion. I don't remember such an option, but if earlier 8051 compilers did not promote, it's possible some production 8051 code relied upon such behavior. Perhaps a project got imported from an older compiler with broken promotion rules (but the code for the project at the time was set up to deal with them) and the rules were set to be compatible with the old compiler.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web