Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120124 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2017-09-21 20:50 -0700 |
| Last post | 2017-09-22 09:12 -0700 |
| Articles | 20 on this page of 178 — 26 participants |
Back to article view | Back to comp.lang.c
Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-21 20:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:15 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:21 -0500
Re: Something C might need fir <profesor.fir@gmail.com> - 2017-09-22 00:44 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-22 11:02 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 12:35 -0500
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 13:46 -0400
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 11:47 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 12:16 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 18:10 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 15:24 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 15:52 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:29 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:29 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:06 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 12:28 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 16:17 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 18:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 22:45 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:22 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 11:29 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-23 10:25 -0400
Re: Something C might need Reinhardt Behm <rbehm@hushmail.com> - 2017-09-24 22:09 +0800
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 15:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 13:17 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:53 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 14:54 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 23:10 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:14 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 01:04 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 17:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 08:48 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 11:50 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 21:59 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 14:25 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:39 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-26 11:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:44 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 18:57 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 00:08 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 20:51 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:10 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 22:22 -0400
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:35 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 16:16 +0200
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:47 -0700
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 13:38 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:29 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:40 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:30 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-25 08:58 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 17:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-23 11:32 -0700
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:43 +0000
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:07 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-25 13:34 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-26 10:04 +1300
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-26 14:31 +0000
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-27 08:38 +1300
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 17:49 -0700
Re: Something C might need gordonb.w32iq@burditt.org (Gordon Burditt) - 2017-09-23 21:21 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-24 11:27 -0700
Re: Something C might need gordonb.woyvd@burditt.org (Gordon Burditt) - 2017-09-25 01:08 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-25 09:38 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-25 10:00 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 11:32 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 12:29 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 20:38 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 15:25 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-23 20:36 -0400
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:42 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 22:47 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 15:10 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 16:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 16:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:00 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:51 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:11 +0200
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:04 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 22:10 +0100
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-24 10:19 +1300
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:38 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 02:14 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:16 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:41 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:15 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 14:03 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 13:59 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 16:08 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 21:50 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:40 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:28 +0200
Re: Something C might need luser droog <luser.droog@gmail.com> - 2017-09-26 06:28 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:47 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-27 07:22 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 09:01 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-27 09:42 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:42 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:22 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:48 +0200
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-28 17:31 +0000
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 22:09 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 22:44 +0100
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 01:57 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:02 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 19:10 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 16:27 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-27 09:26 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:53 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 10:52 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:20 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-27 11:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:57 +0200
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-24 14:49 -0400
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 22:06 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:09 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:12 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:46 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:41 +0200
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 21:05 +0100
Re: Something C might need gordonb.r273i@burditt.org (Gordon Burditt) - 2017-09-23 21:34 -0500
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 09:01 +0100
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-24 19:34 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:53 -0500
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 12:27 -0400
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 20:33 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:52 -0500
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 23:23 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 15:15 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:49 -0500
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:46 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:32 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 21:50 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:32 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-26 22:34 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:39 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 19:38 +0100
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 15:00 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 12:29 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:12 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 11:38 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-22 04:21 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-22 14:54 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 08:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 06:49 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-22 20:24 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 12:45 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 09:00 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:34 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 10:49 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 19:25 -0400
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-22 19:35 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 11:52 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 18:25 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 13:36 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 20:20 -0700
Rick says C is a dying language. (Was: Something C might need) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:15 +0000
Re: Rick says C is a dying language. (Was: Something C might need) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 04:40 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 13:00 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 10:28 -0400
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-22 23:22 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 18:01 +1200
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-22 20:31 -0400
Re: Something C might need jladasky@itu.edu - 2017-09-22 16:27 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 16:34 -0700
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-26 21:44 +0000
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-26 14:53 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 02:14 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 21:31 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-22 14:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:29 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-22 09:12 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-24 20:51 -0400 |
| Message-ID | <oq9jtq$n8l$1@jstuckle.eternal-september.org> |
| In reply to | #120253 |
On 9/24/2017 7:08 PM, bartc wrote: > On 24/09/2017 23:57, Jerry Stuckle wrote: >> On 9/24/2017 10:32 AM, bartc wrote: > >>> Then you can streamline each one, rather than ALL users still running >>> around trying to figure out exactly how wide 'long' is or what >>> stdint.h type is best or what print format needs to be used. >>> >> >> C already does that - without being split into multiple languages. >> That's one of its powers. > > It's astonishing really - hundred of millions can be spent developing > the various new technologies for a new model of car. > > But throwing together the ideal, most efficient and productive language > for its various programmable devices, something that a whizzkid can > prototype in a month - that's apparently so hard that it's necessary to > rely on a language from 1972. > Gee, maybe that's because it does so well it doesn't need to be replaced. Of course, you are free to design your own language. No one is stopping you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-25 02:10 +0100 |
| Message-ID | <4IYxB.1118821$ZZ2.19480@fx08.am4> |
| In reply to | #120260 |
On 25/09/2017 01:51, Jerry Stuckle wrote: > On 9/24/2017 7:08 PM, bartc wrote: >> On 24/09/2017 23:57, Jerry Stuckle wrote: >>> On 9/24/2017 10:32 AM, bartc wrote: >> >>>> Then you can streamline each one, rather than ALL users still >>>> running around trying to figure out exactly how wide 'long' is or >>>> what stdint.h type is best or what print format needs to be used. >>>> >>> >>> C already does that - without being split into multiple languages. >>> That's one of its powers. >> >> It's astonishing really - hundred of millions can be spent developing >> the various new technologies for a new model of car. >> >> But throwing together the ideal, most efficient and productive >> language for its various programmable devices, something that a >> whizzkid can prototype in a month - that's apparently so hard that >> it's necessary to rely on a language from 1972. >> > > Gee, maybe that's because it does so well it doesn't need to be replaced. > > Of course, you are free to design your own language. No one is stopping > you. No. I have done and that's what I use. I have been hoping for a while it could be replaced by C to simplify interconnectivity with other systems (and so that someone else has the headache of maintaining it) but that hasn't happened yet. I don't think it will because mine is far more of a pleasure to work with even if interfacing to foreign libraries is a nightmare. But I'm surprised no one else has produced a mainstream competitor to C that does the same job.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-24 22:22 -0400 |
| Message-ID | <oq9p91$ars$1@jstuckle.eternal-september.org> |
| In reply to | #120263 |
On 9/24/2017 9:10 PM, bartc wrote: > On 25/09/2017 01:51, Jerry Stuckle wrote: >> On 9/24/2017 7:08 PM, bartc wrote: >>> On 24/09/2017 23:57, Jerry Stuckle wrote: >>>> On 9/24/2017 10:32 AM, bartc wrote: >>> >>>>> Then you can streamline each one, rather than ALL users still >>>>> running around trying to figure out exactly how wide 'long' is or >>>>> what stdint.h type is best or what print format needs to be used. >>>>> >>>> >>>> C already does that - without being split into multiple languages. >>>> That's one of its powers. >>> >>> It's astonishing really - hundred of millions can be spent developing >>> the various new technologies for a new model of car. >>> >>> But throwing together the ideal, most efficient and productive >>> language for its various programmable devices, something that a >>> whizzkid can prototype in a month - that's apparently so hard that >>> it's necessary to rely on a language from 1972. >>> >> >> Gee, maybe that's because it does so well it doesn't need to be replaced. >> >> Of course, you are free to design your own language. No one is >> stopping you. > > > No. I have done and that's what I use. I have been hoping for a while it > could be replaced by C to simplify interconnectivity with other systems > (and so that someone else has the headache of maintaining it) but that > hasn't happened yet. > If you have your own language, then why are you here bitching about C? You're all alone in your bitching. > I don't think it will because mine is far more of a pleasure to work > with even if interfacing to foreign libraries is a nightmare. > That's great. If it's such a super language, then you should have no problem getting other people to use it, also. > But I'm surprised no one else has produced a mainstream competitor to C > that does the same job. > Maybe because most C programmers are intelligent enough to understand and use C properly. But a few are too stoopid and all they do is bitch about it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-09-25 06:35 -0700 |
| Message-ID | <882448e9-c3ee-4926-b2a4-562d9a720053@googlegroups.com> |
| In reply to | #120263 |
On Sunday, September 24, 2017 at 10:10:30 PM UTC-3, Bart wrote: > On 25/09/2017 01:51, Jerry Stuckle wrote: > > On 9/24/2017 7:08 PM, bartc wrote: > >> On 24/09/2017 23:57, Jerry Stuckle wrote: > >>> On 9/24/2017 10:32 AM, bartc wrote: > >> > >>>> Then you can streamline each one, rather than ALL users still > >>>> running around trying to figure out exactly how wide 'long' is or > >>>> what stdint.h type is best or what print format needs to be used. > >>>> > >>> > >>> C already does that - without being split into multiple languages. > >>> That's one of its powers. > >> > >> It's astonishing really - hundred of millions can be spent developing > >> the various new technologies for a new model of car. > >> > >> But throwing together the ideal, most efficient and productive > >> language for its various programmable devices, something that a > >> whizzkid can prototype in a month - that's apparently so hard that > >> it's necessary to rely on a language from 1972. > >> > > > > Gee, maybe that's because it does so well it doesn't need to be replaced. > > > > Of course, you are free to design your own language. No one is stopping > > you. > > > No. I have done and that's what I use. I have been hoping for a while it > could be replaced by C to simplify interconnectivity with other systems > (and so that someone else has the headache of maintaining it) but that > hasn't happened yet. > > I don't think it will because mine is far more of a pleasure to work > with even if interfacing to foreign libraries is a nightmare. > > But I'm surprised no one else has produced a mainstream competitor to C > that does the same job. A new language compatible with C could be like this. Let's ignore macros for a while. The new language could have this: #import "c_header_file.h" This #import, reads all declarations from C code and let's you to use in your new language. You also can compile and link c code. (consequently a c compiler still required) C++, is changing the syntax and allowing duplicate ways for doing the same thing. For instance: int F(); or auto F() int; are valid. More samples include typedef/using and enum/enum class nullptr or 0. The advantage of this method, compared with C++ method, is that you can have just one new syntax. You cannot mix the old syntax. The old syntax can be used just inside #import. The problem of this method is that if after 20 years you realize some mistakes, then you need import version 2 for your previous syntax. Macros, it's a hard point where the new language need to make an decision if it will import macros or not. If you have a C library that uses macros you need an alternative to reuse it. Mostly C libraries I see uses macros for constants. #define X 1 could be interpreted as constant by the #import. But let's say some library has a macro "SUCCEEDED" to check if the result code is an error. Then to use the library you would need to create wrappers. The last alternative is what I said some time ago, the defines could be parsed for constants or inline functions and imported following some rules. Macros that broke the rules are not imported. You still may have some problems, but after some time, if the new language is good, the libraries could have wrappers or be adapted to follow the rules for import.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 16:16 +0200 |
| Message-ID | <oqb34b$l9u$1@dont-email.me> |
| In reply to | #120288 |
On 25/09/17 15:35, Thiago Adams wrote: > On Sunday, September 24, 2017 at 10:10:30 PM UTC-3, Bart wrote: >> On 25/09/2017 01:51, Jerry Stuckle wrote: >>> On 9/24/2017 7:08 PM, bartc wrote: >>>> On 24/09/2017 23:57, Jerry Stuckle wrote: >>>>> On 9/24/2017 10:32 AM, bartc wrote: >>>> >>>>>> Then you can streamline each one, rather than ALL users still >>>>>> running around trying to figure out exactly how wide 'long' is or >>>>>> what stdint.h type is best or what print format needs to be used. >>>>>> >>>>> >>>>> C already does that - without being split into multiple languages. >>>>> That's one of its powers. >>>> >>>> It's astonishing really - hundred of millions can be spent developing >>>> the various new technologies for a new model of car. >>>> >>>> But throwing together the ideal, most efficient and productive >>>> language for its various programmable devices, something that a >>>> whizzkid can prototype in a month - that's apparently so hard that >>>> it's necessary to rely on a language from 1972. >>>> >>> >>> Gee, maybe that's because it does so well it doesn't need to be replaced. >>> >>> Of course, you are free to design your own language. No one is stopping >>> you. >> >> >> No. I have done and that's what I use. I have been hoping for a while it >> could be replaced by C to simplify interconnectivity with other systems >> (and so that someone else has the headache of maintaining it) but that >> hasn't happened yet. >> >> I don't think it will because mine is far more of a pleasure to work >> with even if interfacing to foreign libraries is a nightmare. >> >> But I'm surprised no one else has produced a mainstream competitor to C >> that does the same job. > > A new language compatible with C could be like this. > > Let's ignore macros for a while. > The new language could have this: > > #import "c_header_file.h" > > This #import, reads all declarations from C code and let's you to > use in your new language. You also can compile and link c code. > (consequently a c compiler still required) > > C++, is changing the syntax and allowing duplicate ways for doing > the same thing. > > For instance: > > int F(); > or > auto F() int; > are valid. Assuming you mean "auto F() -> int", then yes, both are valid. There are good reasons for this second syntax being added to C++ - sometimes in templates the type of the return is not known until after the parameters are declared. And very conveniently, "auto F()" with /no/ given return type is also valid for definitions (but not other declarations) - the compiler figures out the return type itself. > > More samples include typedef/using and enum/enum class nullptr or 0. "using" is neater and more flexible than "typedef". If C++ had "using" from the beginning, it would never have needed "typedef" - but backwards compatibility means both syntaxes are kept. "enum" and "enum class" do different things - they are not duplicates. Similarly, "nullptr" is not a duplicate of "0". Certainly C++ has been adding quite a few features in recent times - and it is entirely reasonable to prefer C because it is a smaller and stable language - but it is not reasonable to think that C++ just adds features for the sake of it, or to give more ways of writing the same thing. > > The advantage of this method, compared with C++ method, > is that you can have just one new syntax. You cannot mix the old > syntax. The old syntax can be used just inside #import. > The problem of this method is that if after 20 years you realize > some mistakes, then you need import version 2 for your previous > syntax. > > > Macros, it's a hard point where the new language need to make an > decision if it will import macros or not. > If you have a C library that uses macros you need an alternative > to reuse it. > Mostly C libraries I see uses macros for constants. > #define X 1 could be interpreted as constant by the #import. > > But let's say some library has a macro "SUCCEEDED" to check > if the result code is an error. Then to use the library you would need > to create wrappers. The last alternative is what I said some time ago, > the defines could be parsed for constants or inline functions and > imported following some rules. Macros that broke the rules are not > imported. You still may have some problems, but after some time, if the > new language is good, the libraries could have wrappers or be adapted > to follow the rules for import. > Compatibility with existing languages and code is always a difficult point when you want a new language with new "clean" syntax.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-09-25 07:47 -0700 |
| Message-ID | <a614be68-c759-483b-9f7f-ce419e3f3c2d@googlegroups.com> |
| In reply to | #120292 |
On Monday, September 25, 2017 at 11:16:56 AM UTC-3, David Brown wrote:
> On 25/09/17 15:35, Thiago Adams wrote:
> > On Sunday, September 24, 2017 at 10:10:30 PM UTC-3, Bart wrote:
> >> On 25/09/2017 01:51, Jerry Stuckle wrote:
> >>> On 9/24/2017 7:08 PM, bartc wrote:
> >>>> On 24/09/2017 23:57, Jerry Stuckle wrote:
> >>>>> On 9/24/2017 10:32 AM, bartc wrote:
> >>>>
> >>>>>> Then you can streamline each one, rather than ALL users still
> >>>>>> running around trying to figure out exactly how wide 'long' is or
> >>>>>> what stdint.h type is best or what print format needs to be used.
> >>>>>>
> >>>>>
> >>>>> C already does that - without being split into multiple languages.
> >>>>> That's one of its powers.
> >>>>
> >>>> It's astonishing really - hundred of millions can be spent developing
> >>>> the various new technologies for a new model of car.
> >>>>
> >>>> But throwing together the ideal, most efficient and productive
> >>>> language for its various programmable devices, something that a
> >>>> whizzkid can prototype in a month - that's apparently so hard that
> >>>> it's necessary to rely on a language from 1972.
> >>>>
> >>>
> >>> Gee, maybe that's because it does so well it doesn't need to be replaced.
> >>>
> >>> Of course, you are free to design your own language. No one is stopping
> >>> you.
> >>
> >>
> >> No. I have done and that's what I use. I have been hoping for a while it
> >> could be replaced by C to simplify interconnectivity with other systems
> >> (and so that someone else has the headache of maintaining it) but that
> >> hasn't happened yet.
> >>
> >> I don't think it will because mine is far more of a pleasure to work
> >> with even if interfacing to foreign libraries is a nightmare.
> >>
> >> But I'm surprised no one else has produced a mainstream competitor to C
> >> that does the same job.
> >
> > A new language compatible with C could be like this.
> >
> > Let's ignore macros for a while.
> > The new language could have this:
> >
> > #import "c_header_file.h"
> >
> > This #import, reads all declarations from C code and let's you to
> > use in your new language. You also can compile and link c code.
> > (consequently a c compiler still required)
> >
> > C++, is changing the syntax and allowing duplicate ways for doing
> > the same thing.
> >
> > For instance:
> >
> > int F();
> > or
> > auto F() int;
> > are valid.
>
> Assuming you mean "auto F() -> int", then yes, both are valid.
>
> There are good reasons for this second syntax being added to C++ -
> sometimes in templates the type of the return is not known until after
> the parameters are declared.
Also in lambdas. [] ->int { }
> And very conveniently, "auto F()" with /no/ given return type is also
> valid for definitions (but not other declarations) - the compiler
> figures out the return type itself.
>
> >
> > More samples include typedef/using and enum/enum class nullptr or 0.
>
> "using" is neater and more flexible than "typedef". If C++ had "using"
> from the beginning, it would never have needed "typedef" - but backwards
> compatibility means both syntaxes are kept.
>
> "enum" and "enum class" do different things - they are not duplicates.
> Similarly, "nullptr" is not a duplicate of "0".
They are different because they need to keep compatibility. In a new language
int * p = 0 ; could be an error. Same for enum/typedef.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-09-25 13:38 -0700 |
| Message-ID | <4274b5b1-5456-4813-9a41-93cbcb84a276@googlegroups.com> |
| In reply to | #120288 |
On Monday, September 25, 2017 at 10:35:27 AM UTC-3, Thiago Adams wrote: ... > A new language compatible with C could be like this. > > Let's ignore macros for a while. > The new language could have this: > > #import "c_header_file.h" > > This #import, reads all declarations from C code and let's you to > use in your new language. You also can compile and link c code. > (consequently a c compiler still required) There is a new language called Kotlin that did something similar of this, but for Java. It's called Kotlin. "Use any existing library on the JVM, as there’s 100% compatibility, including SAM support." (Java doesn't have macros :)) https://kotlinlang.org/
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-24 23:29 -0500 |
| Message-ID | <tt0hscplihsj6km4gspkrc11mom1jgusb7@4ax.com> |
| In reply to | #120230 |
On Sun, 24 Sep 2017 15:32:43 +0100, bartc <bc@freeuk.com> wrote: >On 24/09/2017 15:09, Reinhardt Behm wrote: >> AT Saturday 23 September 2017 22:25, Jerry Stuckle wrote: >> >>> On 9/23/2017 6:29 AM, bartc wrote: > >>> I think you would be in deep crap without those chips. They are used in >>> all kinds of things - from microwave ovens to automobiles to MP3 >>> players. Nowadays most electronic items use one or more of these chips. >>> And the most common language used to program them is C. >> >> Not to forget the keyboard and mouse he is using to post his nonsense. > >Between c. 1976 and 1985 I am 99% certain that the keyboards I used did >not contain any microprogrammable controller let alone be coded in C. >(After that I used an ibm pc-compatible keyboard and I have no idea what >went on inside it.) > >The point: keyboards don't need to depend on C to function. (Why they >even needed a microcontroller, until it was necessary to support USB, I >don't know.) Memories grow a bit dim here, but IIRC, the original IBM PC keyboard used an 8031 (it may have been a different controller in the 8048 line). The AT keyboard switched to an 8042. And I rather doubt they were programmed in anything other than assembler. Someone disassembled the 8042 ROM for AT keyboards a number of years ago: http://www.halicery.com/8042/8042_1503033.TXT FWIW, that doesn't really look like compiler generated code to me.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-25 17:40 -0500 |
| Message-ID | <qd1jscp1nacovlti90rem6s0tu7e1spsld@4ax.com> |
| In reply to | #120266 |
On Sun, 24 Sep 2017 23:29:56 -0500, Robert Wessel <robertwessel2@yahoo.com> wrote: >On Sun, 24 Sep 2017 15:32:43 +0100, bartc <bc@freeuk.com> wrote: > >>On 24/09/2017 15:09, Reinhardt Behm wrote: >>> AT Saturday 23 September 2017 22:25, Jerry Stuckle wrote: >>> >>>> On 9/23/2017 6:29 AM, bartc wrote: >> >>>> I think you would be in deep crap without those chips. They are used in >>>> all kinds of things - from microwave ovens to automobiles to MP3 >>>> players. Nowadays most electronic items use one or more of these chips. >>>> And the most common language used to program them is C. >>> >>> Not to forget the keyboard and mouse he is using to post his nonsense. >> >>Between c. 1976 and 1985 I am 99% certain that the keyboards I used did >>not contain any microprogrammable controller let alone be coded in C. >>(After that I used an ibm pc-compatible keyboard and I have no idea what >>went on inside it.) >> >>The point: keyboards don't need to depend on C to function. (Why they >>even needed a microcontroller, until it was necessary to support USB, I >>don't know.) > > >Memories grow a bit dim here, but IIRC, the original IBM PC keyboard >used an 8031 (it may have been a different controller in the 8048 >line). The AT keyboard switched to an 8042. > >And I rather doubt they were programmed in anything other than >assembler. > >Someone disassembled the 8042 ROM for AT keyboards a number of years >ago: > >http://www.halicery.com/8042/8042_1503033.TXT > >FWIW, that doesn't really look like compiler generated code to me. FWIW, I got to a reference, and the original PC/XT keyboard had an 8048.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-24 23:30 -0500 |
| Message-ID | <ii1hsc98od0030rulqgf3hkr65bpje9c5e@4ax.com> |
| In reply to | #120229 |
On Sun, 24 Sep 2017 22:09:19 +0800, Reinhardt Behm <rbehm@hushmail.com> wrote: >AT Saturday 23 September 2017 22:25, Jerry Stuckle wrote: > >> On 9/23/2017 6:29 AM, bartc wrote: >>> On 23/09/2017 06:45, David Kleinecke wrote: >>>> On Friday, September 22, 2017 at 6:20:35 PM UTC-7, Keith Thompson wrote: >>>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>>> [...] >>>>>> Assuming the hardware arithmetic is 64-bit then I think it >>>>>> would be best to have "short" be 32-bit, char 8-bit and >>>>>> 16-bit "long char". "Wide char" would be more standard but >>>>>> why introduce a new keyword. "Short short" for 16-bit would >>>>>> be in the spirit of "long long" (which I assume no longer >>>>>> would exist). >>>>> >>>>> How much existing code do you want to break? >>>> >>>> Ah ha - a major difference in viewpoint. >>>> >>>> I wasn't addressing existing code at all. I have no >>>> desire to even bend any of it. >>>> >>>> I am looking forward. What I see is people using types >>>> like "uint8_t" instead of "unsigned char". I was trying >>>> bring the old C nomenclature back into good repute. >>> >>> In that case it's easy: >>> >>> char 8 bits >>> short 16 >>> int 32 >>> long 64 >>> long long 128 (Optional) >>> >>> float 32 >>> double 64 >>> >>> void* 32 or 64 >>> >>> Since this is what typical /computers/ running C will actually have (not >>> just any device, no matter how tiny, that happens to be programmable). >>> >> >> Because C can be compiled on systems other than what you call >> /computers/. And it is used on a lot of those systems. Arguably more >> individual systems than your /computers/. >> >>> And it also matches languages such as C#, Java, Go, and Rust. They will >>> use different designations, but you know where you are with them. >>> >> >> So what? Different languages, different rules. Why not make C look like >> COBOL or RPG instead? >> >>> At the minute, no one can use 'int' or 'long' if they expect one to be >>> 32 bits and the other 64, and no wider. >>> >> >> Which is why there are specific types for specific sizes. >> >>>> I think machine that are not byte-based need to >>>> used with great care and lots of special bells and >>>> whistles. >>> >>> I think forget about those. >>> >> >> I think you would be in deep crap without those chips. They are used in >> all kinds of things - from microwave ovens to automobiles to MP3 >> players. Nowadays most electronic items use one or more of these chips. >> And the most common language used to program them is C. > >Not to forget the keyboard and mouse he is using to post his nonsense. OTOH most of those *are* byte oriented devices.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-25 08:58 -0400 |
| Message-ID | <oqauh2$f14$1@jstuckle.eternal-september.org> |
| In reply to | #120267 |
On 9/25/2017 12:30 AM, Robert Wessel wrote: > On Sun, 24 Sep 2017 22:09:19 +0800, Reinhardt Behm > <rbehm@hushmail.com> wrote: > >> AT Saturday 23 September 2017 22:25, Jerry Stuckle wrote: >> >>> On 9/23/2017 6:29 AM, bartc wrote: >>>> On 23/09/2017 06:45, David Kleinecke wrote: >>>>> On Friday, September 22, 2017 at 6:20:35 PM UTC-7, Keith Thompson wrote: >>>>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>>>> [...] >>>>>>> Assuming the hardware arithmetic is 64-bit then I think it >>>>>>> would be best to have "short" be 32-bit, char 8-bit and >>>>>>> 16-bit "long char". "Wide char" would be more standard but >>>>>>> why introduce a new keyword. "Short short" for 16-bit would >>>>>>> be in the spirit of "long long" (which I assume no longer >>>>>>> would exist). >>>>>> >>>>>> How much existing code do you want to break? >>>>> >>>>> Ah ha - a major difference in viewpoint. >>>>> >>>>> I wasn't addressing existing code at all. I have no >>>>> desire to even bend any of it. >>>>> >>>>> I am looking forward. What I see is people using types >>>>> like "uint8_t" instead of "unsigned char". I was trying >>>>> bring the old C nomenclature back into good repute. >>>> >>>> In that case it's easy: >>>> >>>> char 8 bits >>>> short 16 >>>> int 32 >>>> long 64 >>>> long long 128 (Optional) >>>> >>>> float 32 >>>> double 64 >>>> >>>> void* 32 or 64 >>>> >>>> Since this is what typical /computers/ running C will actually have (not >>>> just any device, no matter how tiny, that happens to be programmable). >>>> >>> >>> Because C can be compiled on systems other than what you call >>> /computers/. And it is used on a lot of those systems. Arguably more >>> individual systems than your /computers/. >>> >>>> And it also matches languages such as C#, Java, Go, and Rust. They will >>>> use different designations, but you know where you are with them. >>>> >>> >>> So what? Different languages, different rules. Why not make C look like >>> COBOL or RPG instead? >>> >>>> At the minute, no one can use 'int' or 'long' if they expect one to be >>>> 32 bits and the other 64, and no wider. >>>> >>> >>> Which is why there are specific types for specific sizes. >>> >>>>> I think machine that are not byte-based need to >>>>> used with great care and lots of special bells and >>>>> whistles. >>>> >>>> I think forget about those. >>>> >>> >>> I think you would be in deep crap without those chips. They are used in >>> all kinds of things - from microwave ovens to automobiles to MP3 >>> players. Nowadays most electronic items use one or more of these chips. >>> And the most common language used to program them is C. >> >> Not to forget the keyboard and mouse he is using to post his nonsense. > > > OTOH most of those *are* byte oriented devices. > They are also microcontrollers - not PCs or even microprocessors. That's the point. And not all of them are byte oriented - at least not 8 bit bytes. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-23 08:41 -0700 |
| Message-ID | <0a5d39ba-fc96-4fea-922d-bcb4b0db0c32@googlegroups.com> |
| In reply to | #120193 |
On Saturday, September 23, 2017 at 5:29:40 AM UTC-5, Bart wrote: > In that case it's easy: > > char 8 bits > short 16 > int 32 > long 64 > long long 128 (Optional) How about allowing the sizes to be configured via compiler options or directives that precede the first usage of the types in question? Compilers for the Macintosh in the 1980s were able to process "int" as either 16 or 32 bits, and most modern processors should have little difficulty handling any combination of power-of-two integer sizes. If code will called upon in some applications to process lots of values smaller than two billion, but in other applications it may need to process much larger values, having it use "long" but changing the compiler configuration based upon requirements would allow the code to be more efficient in the first application (32-bit values can be cached twice as efficiently as 64-bit ones) but also satisfy the needs of the latter application when built for 64-bit "int".
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-23 17:32 +0100 |
| Message-ID | <m0wxB.1139287$Vu3.583458@fx44.am4> |
| In reply to | #120201 |
On 23/09/2017 16:41, supercat@casperkitty.com wrote: > On Saturday, September 23, 2017 at 5:29:40 AM UTC-5, Bart wrote: >> In that case it's easy: >> >> char 8 bits >> short 16 >> int 32 >> long 64 >> long long 128 (Optional) > > How about allowing the sizes to be configured via compiler options or > directives that precede the first usage of the types in question? Then you lose the advantage of just /knowing/ that int is 32 bits. Suppose you want to combine several sets of functions from different sources into one module, but they make different assumptions about 'int' or each requires different set up. But then, they will all be using common code in this application which has its own requirements for int. > Compilers for the Macintosh in the 1980s were able to process "int" as > either 16 or 32 bits, Didn't that use the 68K? That couldn't make up its mind if it was a 16- or 32-bit device. The rest of the microcomputer world was in transition (I didn't switch 'int' 16-bit to 32-bit until 2002 I think). Now, for the main processors used in computers, an int of 32 bits is expected, but there is no pressing need for it to be 64 bits, especially if 'long' fills that role. If int was 32, and long was 64 bits, then people would just use one or the other, or both. (In my dynamic language, there is one main 'int' type and that is 64 bits. Narrower ones are for packed storage. In the static one, 'int' is 32 bits and 'dint' is 64 bits, while 'intm' is the machine's native word size and will be 32 or 64 bits.) > and most modern processors should have little > difficulty handling any combination of power-of-two integer sizes. If > code will called upon in some applications to process lots of values > smaller than two billion, but in other applications it may need to > process much larger values, having it use "long" but changing the > compiler configuration based upon requirements would allow the code > to be more efficient in the first application (32-bit values can be > cached twice as efficiently as 64-bit ones) but also satisfy the needs > of the latter application when built for 64-bit "int". You mean that the same application can be built for 32- or 64-bit machines, but with different limitations? So that the 32-bit/2GB machine doesn't waste effort on 64-bit ops that would never be needed because counts won't go above 32 bits. Something like my idea of using 'intm' might come in useful here, which adapts itself to the machine. (Doesn't size_t do what in C?) But I did face such a problem (whether my interpreter should use 32-bit internal byte-code or 64-bit (byte-code includes pointers). But there were some other complications and in the end I used 64-bit for both, for simplicity. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-23 11:32 -0700 |
| Message-ID | <aabc8a43-a27b-42bc-9107-413bb84181eb@googlegroups.com> |
| In reply to | #120202 |
On Saturday, September 23, 2017 at 11:32:36 AM UTC-5, Bart wrote:
> On 23/09/2017 16:41, supercat@casperkitty.com wrote:
> > How about allowing the sizes to be configured via compiler options or
> > directives that precede the first usage of the types in question?
>
> Then you lose the advantage of just /knowing/ that int is 32 bits.
Almost no code can be expected to work usefully on a compiler that is
not configured properly for use with it. I would like to see standardized
way by which code could specify a configuration via directives and either
have a compiler automatically configure itself to fit the indicated
requirements or refuse compilation when able to do so, but compilers
must be configured *somehow*.
If configurable int sizes were seen as a desirable feature, however, then
code which expects "int" to be 32 bits would not be limited to platforms
where "int" would default to 32 bits, but would also be usable on those
where it would default to some other size but could be configured to be
32 bits anyway.
> Suppose you want to combine several sets of functions from different
> sources into one module, but they make different assumptions about 'int'
> or each requires different set up.
Combining such functions in one module would likely not be possible unless
a compiler included directives that could be used within a source file. On
the other hand, a build system could allow compilation units with different
integer sizes to be combined within a single program if it has a directive
to request name mangling based on parameter types [used mainly for library
functions] and code which doesn't use that directive uses fixed-sized types
in its interfaces.
Provided that it's possible to specify data types with particular sizes and
semantics when needed, having other more "flexible" ways of specifying data
types may improve efficiency as well, especially if it's possible to give
compilers more flexibility than they now have (e.g. declare a type which
will need to hold values -5000..+5000, but which a compiler may replace with
a larger type at its convenience. On many processors, code like:
T array[50000];
for (unsigned i=0; i<50000; i++) T[i]=1234;
will run faster if T is int16_t than if it's int32_t, but code like:
T foo;
....
foo++;
if (foo) ...;
would run slower with int16_t than int32_t [on a system where "int"
is 32 bits, incrementing an int16_t that holds 32767 would have to yield
-32768 unless an implementation documents that it adds code that would slow
down in-range computations]. Having a type that could behave as int16_t in
the former scenario but could (at the compiler's discretion) behave as
int32_t in the latter, would allow more efficient code generation than would
be possible under today's rules.
> > Compilers for the Macintosh in the 1980s were able to process "int" as
> > either 16 or 32 bits,
>
> Didn't that use the 68K? That couldn't make up its mind if it was a 16-
> or 32-bit device. The rest of the microcomputer world was in transition
> (I didn't switch 'int' 16-bit to 32-bit until 2002 I think).
On the 68000, most 16-bit operations had a slight speed advantage over
32-bit operations. On today's processors, even those which without
question are "64-bit" systems, operations on smaller types will still
often have a speed advantage over those on larger ones, either because
of vectorization or because of caching issues.
In addition, by the time people were writing C compilers for the Macintosh
there was already a lot of C code that had been written for 16-bit systems,
and an option to make "int" be 16 bits made it easier to port such code
for use on the Macintosh.
> Now, for the main processors used in computers, an int of 32 bits is
> expected, but there is no pressing need for it to be 64 bits, especially
> if 'long' fills that role.
Is there any reason "long long" or "int64_t" couldn't fulfill the need for
a longer type just as well?
Since the mid 1980s, a lot of code has been written with the premise that:
char -- 8
short -- 16
int -- 16 or 32
long -- 32
Obviously such types won't work on a 36-bit system, but I see no reason why
a compiler for an octet-based machine shouldn't be configurable to work with
code that expects such types.
> > and most modern processors should have little
> > difficulty handling any combination of power-of-two integer sizes. If
> > code will called upon in some applications to process lots of values
> > smaller than two billion, but in other applications it may need to
> > process much larger values, having it use "long" but changing the
> > compiler configuration based upon requirements would allow the code
> > to be more efficient in the first application (32-bit values can be
> > cached twice as efficiently as 64-bit ones) but also satisfy the needs
> > of the latter application when built for 64-bit "int".
>
> You mean that the same application can be built for 32- or 64-bit
> machines, but with different limitations? So that the 32-bit/2GB machine
> doesn't waste effort on 64-bit ops that would never be needed because
> counts won't go above 32 bits.
That would be one purpose. Though if an implementation could use name
mangling for routines that have types like "int" in their signatures
it would even be possible to combine pieces of code that have different
expectations about integer sizes into one program. The only cases that
would be particularly problematic would be those where it's necessary
to pass a va_list to code that does not expect to pass arguments using
the largest size of object [if all arguments are physically passed as
64 bits, then code which passes a 16-bit "int" to a variadic function
would need to truncate it to 16 bits and then sign-extend it to 64,
and the code that fetches the argument wouldn't have to know or care
what the original size was].
> Something like my idea of using 'intm' might come in useful here, which
> adapts itself to the machine. (Doesn't size_t do what in C?)
I think size_t exists because of platforms like large- or compact-model
8086 or 80286 where pointers are 32 bits, but pointer arithmetic is
limited to a 64K range within any given segment. No individual object is
going to exceed 64K, so there's no need to have sizeof() yield a value
larger than a 16-bit "unsigned". Incidentally, on many such systems,
ptrdiff_t behaves interestingly. Given any two pointers p and q to
different parts of the same object, it's possible that the difference
between p and q will exceed +/- 32768, but p+(q-p)==q will hold anyway.
The Standard doesn't require that, and some pedants might claim such a
thing only works by happenstance, but I think those who designed such
implementations were well aware of the useful properties of modular
arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-09-25 14:43 +0000 |
| Message-ID | <slrnosi5gc.14au.grahn+nntp@frailea.sa.invalid> |
| In reply to | #120202 |
On Sat, 2017-09-23, bartc wrote: > On 23/09/2017 16:41, supercat@casperkitty.com wrote: ... >> Compilers for the Macintosh in the 1980s were able to process "int" as >> either 16 or 32 bits, > > Didn't that use the 68K? That couldn't make up its mind if it was a 16- > or 32-bit device. The rest of the microcomputer world was in transition > (I didn't switch 'int' 16-bit to 32-bit until 2002 I think). Don't know about the Mac, but C compilers for the Commodore-Amiga (MC68000) generally used 32-bit ints. I wouldn't say "couldn't make up its mind". As far as I was concerned as a programmer, it was a normal 32-bit processor. I suspect that compilers with 16-bit ints had them for legacy reasons. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 22:07 +0200 |
| Message-ID | <oqbnlu$u0i$1@dont-email.me> |
| In reply to | #120296 |
On 25/09/17 16:43, Jorgen Grahn wrote: > On Sat, 2017-09-23, bartc wrote: >> On 23/09/2017 16:41, supercat@casperkitty.com wrote: > ... >>> Compilers for the Macintosh in the 1980s were able to process "int" as >>> either 16 or 32 bits, >> >> Didn't that use the 68K? That couldn't make up its mind if it was a 16- >> or 32-bit device. The rest of the microcomputer world was in transition >> (I didn't switch 'int' 16-bit to 32-bit until 2002 I think). > > Don't know about the Mac, but C compilers for the Commodore-Amiga > (MC68000) generally used 32-bit ints. > > I wouldn't say "couldn't make up its mind". As far as I was concerned > as a programmer, it was a normal 32-bit processor. I suspect that > compilers with 16-bit ints had them for legacy reasons. > The original m68k had 32-bit wide registers, but a 16-bit wide ALU. The ISA supported operations on 8-bit, 16-bit and 32-bit values. It was intended to compete with existing 16-bit architectures but be future-compatible with 32-bit systems (rather than merely backwards compatible). A pure 32-bit ALU and 32-bit datapaths would have been too expensive at that time, so 32-bit operations took almost twice as long as 16-bit ones. The external databus was 16 bits wide too, IIRC. (I never actually used a 68000, only a microcontroller with the same basic cpu.) So what is the "natural" size for an int on such a system? The registers supported 32-bit, but 16-bit was faster. Either 16-bit or 32-bit would make sense for "int", and many compilers would let you choose. (For gcc, you have "-mshort" for 16-bit int and "-mno-short" or the default for 32-bit int.) The 68020 had a full 32-bit ALU, and thus there was no advantage of having 16-bit int. I don't know the details of the Amiga, but I /think/ it was at least a 68020 - and thus there would not have been a particular reason to support 16-bit ints on that target.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-25 13:34 -0700 |
| Message-ID | <c7dc298e-333b-4c47-9f1f-392575f1d66a@googlegroups.com> |
| In reply to | #120324 |
On Monday, September 25, 2017 at 3:07:35 PM UTC-5, David Brown wrote: > The original m68k had 32-bit wide registers, but a 16-bit wide ALU. The > ISA supported operations on 8-bit, 16-bit and 32-bit values. It was > intended to compete with existing 16-bit architectures but be > future-compatible with 32-bit systems (rather than merely backwards > compatible). A pure 32-bit ALU and 32-bit datapaths would have been too > expensive at that time, so 32-bit operations took almost twice as long > as 16-bit ones. The external databus was 16 bits wide too, IIRC. (I > never actually used a 68000, only a microcontroller with the same basic > cpu.) The Motorola 68000 was packaged in a 64-pin DIP and had a non-multiplexed data bus. Using a 32-bit bus would have required expanding the package to at least 80 pins, and I'm not sure there were any standard packages that would have been suitable for such purposes when the 68000 was introduced. > The 68020 had a full 32-bit ALU, and thus there was no advantage of > having 16-bit int. I don't know the details of the Amiga, but I /think/ > it was at least a 68020 - and thus there would not have been a > particular reason to support 16-bit ints on that target. An option for 16-bit "int" would have been useful when porting code from other 16-bit systems, or when writing code that should be able to operate more efficiently in low-memory environments (using a table of four-byte offsets on a system which has insufficient memory to handle any individual object over 32K would be wasteful).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-26 10:04 +1300 |
| Message-ID | <f2t9bqFks76U1@mid.individual.net> |
| In reply to | #120324 |
On 09/26/17 09:07 AM, David Brown wrote: > > The 68020 had a full 32-bit ALU, and thus there was no advantage of > having 16-bit int. I don't know the details of the Amiga, but I /think/ > it was at least a 68020 - and thus there would not have been a > particular reason to support 16-bit ints on that target. The Amiga used a 68000 or a 68010. There was one with a 68020, but that was a one-off I built! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-09-26 14:31 +0000 |
| Message-ID | <slrnoskp6u.14au.grahn+nntp@frailea.sa.invalid> |
| In reply to | #120331 |
On Mon, 2017-09-25, Ian Collins wrote: > On 09/26/17 09:07 AM, David Brown wrote: >> >> The 68020 had a full 32-bit ALU, and thus there was no advantage of >> having 16-bit int. I don't know the details of the Amiga, but I /think/ >> it was at least a 68020 - and thus there would not have been a >> particular reason to support 16-bit ints on that target. > > The Amiga used a 68000 or a 68010. There was one with a 68020, but that > was a one-off I built! No, more like what David wrote. Early models and the (in Europe) very widely spread A500 used a 68000; the later A3000, A1200 and A4000 used a 68020 or better. You typically used compilers with 32-bit ints even if you targeted the 68000 models ... and you /did/ target them, at least if you were a hobbyist, since the high-end models were rare and expensive. Perhaps it didn't matter much: people like me tended to avoid the standard library, and use the WORD, LONG etc aliases for everything. I didn't unlearn those habits until I reluctantly moved to Unix. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-27 08:38 +1300 |
| Message-ID | <f2voliF9eopU1@mid.individual.net> |
| In reply to | #120344 |
On 09/27/17 03:31 AM, Jorgen Grahn wrote: > On Mon, 2017-09-25, Ian Collins wrote: >> On 09/26/17 09:07 AM, David Brown wrote: >>> >>> The 68020 had a full 32-bit ALU, and thus there was no advantage of >>> having 16-bit int. I don't know the details of the Amiga, but I /think/ >>> it was at least a 68020 - and thus there would not have been a >>> particular reason to support 16-bit ints on that target. >> >> The Amiga used a 68000 or a 68010. There was one with a 68020, but that >> was a one-off I built! > > No, more like what David wrote. Early models and the (in Europe) very > widely spread A500 used a 68000; the later A3000, A1200 and A4000 used > a 68020 or better. I should have said mine was the only A500 with a 68020... -- Ian
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web