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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-23 11:29 +0100 |
| Message-ID | <gIqxB.1112706$Vu3.123551@fx44.am4> |
| In reply to | #120183 |
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).
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.
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.
> 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.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-23 10:25 -0400 |
| Message-ID | <oq5qrv$e5j$1@jstuckle.eternal-september.org> |
| In reply to | #120193 |
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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-09-24 22:09 +0800 |
| Message-ID | <oq8eam$e9c$1@dont-email.me> |
| In reply to | #120198 |
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. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 15:32 +0100 |
| Message-ID | <emPxB.815348$sC5.718868@fx45.am4> |
| In reply to | #120229 |
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.) The 'nonsense' you mention is presumably my suggestion to concentrate on 8, 16, 32 and 64-bit data types. This is the same nonsense as adopted by Java, Go, D, C# and Rust. How are /those/ used on microcontrollers? Or do they just leave that side of things to C! Well, I'm sure it's been suggested many times that C should have split into a language still suitable for all those dozens of assorted devices, and a one aimed at the sorts of processors we're all using when posting to usenet or running compilers. 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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-24 13:17 -0700 |
| Message-ID | <4358e118-a0c2-4e15-8c0b-0ed9857d39e3@googlegroups.com> |
| In reply to | #120230 |
On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: > 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.) It is possible to build a keyboard controller out of discrete logic, but unless one wants to have the main processor scan the keyboard using a timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, and likely many other machines as well) the amount of logic required is fairly substantial. Microcontrollers that could act as all-in-one-chip solutions were developed in the 1970s, so except in cases where the VIC-20-style keyboard scanning would be practical they provide the cheapest way of interfacing keyboards.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 21:53 +0100 |
| Message-ID | <lXUxB.1061624$fp7.1024894@fx39.am4> |
| In reply to | #120244 |
On 24/09/2017 21:17, supercat@casperkitty.com wrote: > On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: >> 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.) > > It is possible to build a keyboard controller out of discrete logic, but > unless one wants to have the main processor scan the keyboard using a > timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, > and likely many other machines as well) the amount of logic required is > fairly substantial. Microcontrollers that could act as all-in-one-chip > solutions were developed in the 1970s, so except in cases where the > VIC-20-style keyboard scanning would be practical they provide the cheapest > way of interfacing keyboards. I don't think the logic is that difficult. You wouldn't have discrete logic chips (74 series gates etc) anyway, there can be a custom chip but it needn't be a microcontroller. The first keyboard I bought was accessed via a 8-bit port; I think the top bit indicated a key was ready. The ones my company bought for its microcomputers I think had a more elaborate controller, but were still accessed in parallel mode (via a flat cable as it was in the same case). I forget the details, but certainly nothing as hairy as a floppy or hard disk controller. Anyway, suppose there was a programmable controller involved; how many lines of line would be needed? Would it really be necessary to use C; does no other language - other than the controller's machine code - exist that works at this level? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-24 14:54 -0700 |
| Message-ID | <de9565a6-ebcc-4672-9db4-aa588b5820b6@googlegroups.com> |
| In reply to | #120246 |
On Sunday, September 24, 2017 at 3:53:46 PM UTC-5, Bart wrote:
> On 24/09/2017 21:17, supercat@casperkitty.com wrote:
> > It is possible to build a keyboard controller out of discrete logic, but
> > unless one wants to have the main processor scan the keyboard using a
> > timer-tick interrupt (the approach used by the VIC-20 and Commodore 64,
> > and likely many other machines as well) the amount of logic required is
> > fairly substantial. Microcontrollers that could act as all-in-one-chip
> > solutions were developed in the 1970s, so except in cases where the
> > VIC-20-style keyboard scanning would be practical they provide the cheapest
> > way of interfacing keyboards.
>
> I don't think the logic is that difficult. You wouldn't have discrete
> logic chips (74 series gates etc) anyway, there can be a custom chip but
> it needn't be a microcontroller.
>
> The first keyboard I bought was accessed via a 8-bit port; I think the
> top bit indicated a key was ready.
The Apple ][ did that using discrete logic and required that the physical
keyboard grid line up with character codes. The Apple //e used a custom
chip for the keyboard so as to be software compatible while offering a
keyboard layout that better matched more recent computers (e.g. putting
parentheses on 9 and 0 rather than 8 and 9, making = a base key rather
than a shifted -, etc.)
While it's certainly possible to use custom logic for a keyboard
controller, using a microcontroller makes it easy to add things like
type-ahead buffering, programmable key repeat, etc. without having to
add circuitry. Even in the 1970s, cheap mask-ROM microcontrollers were,
well, cheap. Although many keyboard controllers were programmed before
there were any C-ish compilers for tiny 8-bit micros, someone in the
late 1970s who had one of today's C-ish compilers for the PIC16C57 (and
something to run it on) could probably have written keyboard controller
firmware more quickly than using assembly language (I no longer have my
old 1970s data book, but I think some of the 1970s General Instruments
PICs used the exact same instruction set as today's Microchip PIC16C57
except that instead of using the OPTION and TRIS instructions to control
RTC/watchdog configuration and port direction, one had to instruct the
factory what settings to use.)
Actually, if I were in charge of standards I would mark many features
like double-precision floating-point math as things that quality
implementations should seek to provide whenever possible, but allow
low-end implementations that couldn't very well provide them to be
recognized as conforming nonetheless. Many of the cases where C offers
the biggest advantages over machine code are those which involve math
larger than a CPU's register size. If x, y, and z are 16 bits, it's
a lot easier to read or write:
x=y+z;
than
movf y,w ; WREG = lower byte of y
addwf z,w ; WREG += lower byte of z
movwf x ; store lower byte of x
movf y+1,w ; WREG = upper byte of y
btfsc 3,0 ; Skip next instruction if carry not set
incf y+1,w ; WREG = 1 + upper byte of y
addwf z+1,w ; WREG += upper byte of z
movwf x+1 ; store upper byte of x
Given how useful C can be on such platforms, it seems a shame that there's
no usable standard for the language on them.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 23:10 +0100 |
| Message-ID | <k3WxB.918207$_F5.238258@fx40.am4> |
| In reply to | #120249 |
On 24/09/2017 22:54, supercat@casperkitty.com wrote: > On Sunday, September 24, 2017 at 3:53:46 PM UTC-5, Bart wrote: >> The first keyboard I bought was accessed via a 8-bit port; I think the >> top bit indicated a key was ready. > > The Apple ][ did that using discrete logic and required that the physical > keyboard grid line up with character codes. The Apple //e used a custom > chip for the keyboard so as to be software compatible while offering a > keyboard layout that better matched more recent computers (e.g. putting > parentheses on 9 and 0 rather than 8 and 9, making = a base key rather > than a shifted -, etc.) > > While it's certainly possible to use custom logic for a keyboard > controller, using a microcontroller makes it easy to add things like > type-ahead buffering, programmable key repeat, etc. My first keyboard had built-in non-programmable repeat. With sensible settings, it's preferable than programmable. (Which means, on every new computer, having to find out how to set it. And on some having to find out how to make it persistent. They always start off too slow. without having to > add circuitry. Even in the 1970s, cheap mask-ROM microcontrollers were, > well, cheap. Although many keyboard controllers were programmed before > there were any C-ish compilers for tiny 8-bit micros, someone in the > late 1970s who had one of today's C-ish compilers for the PIC16C57 (and > something to run it on) could probably have written keyboard controller > firmware more quickly than using assembly language Maybe, but how long would it have taken, compared with other design tasks such as drawing the schematics, making the PCB layout, making and debugging the prototype board (and sourcing all the actual keys and microswitches)? > Actually, if I were in charge of standards I would mark many features > like double-precision floating-point math as things that quality > implementations should seek to provide whenever possible, Double precision is a big deal. Even on x86, you would avoid 64-bit floating point if it had to be done in software. You wouldn't demand it of a microcontroller. but allow > low-end implementations that couldn't very well provide them to be > recognized as conforming nonetheless. Many of the cases where C offers > the biggest advantages over machine code are those which involve math > larger than a CPU's register size. If x, y, and z are 16 bits, it's > a lot easier to read or write: > > x=y+z; > > than > > movf y,w ; WREG = lower byte of y > addwf z,w ; WREG += lower byte of z > movwf x ; store lower byte of x > movf y+1,w ; WREG = upper byte of y > btfsc 3,0 ; Skip next instruction if carry not set > incf y+1,w ; WREG = 1 + upper byte of y > addwf z+1,w ; WREG += upper byte of z > movwf x+1 ; store upper byte of x Except that it probably wouldn't be done that way. You'd use a function, or whatever macro facilities the assembler had. (And actually in those days I'd have to write my assembler first. I would a few things to make life easier.) Programmers will always find a way of not having to do so much work. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-24 16:14 -0700 |
| Message-ID | <21b30f23-d63f-4b56-84be-7b748ebd6025@googlegroups.com> |
| In reply to | #120251 |
On Sunday, September 24, 2017 at 5:10:40 PM UTC-5, Bart wrote: > On 24/09/2017 22:54, supercat@casperkitty.com wrote: > > While it's certainly possible to use custom logic for a keyboard > > controller, using a microcontroller makes it easy to add things like > > type-ahead buffering, programmable key repeat, etc. > > My first keyboard had built-in non-programmable repeat. With sensible > settings, it's preferable than programmable. (Which means, on every new > computer, having to find out how to set it. And on some having to find > out how to make it persistent. They always start off too slow. If a system can accurately time-stamp key-press and key-release events, there isn't really a need to have they keyboard controller provide its own keyboard repeat logic. But many systems did include keyboard repeat, and it's easier to do that in software than hardware, especially if one wants to ensure that the key-repeat timer gets reset between overlapped keystrokes. > without having to > > add circuitry. Even in the 1970s, cheap mask-ROM microcontrollers were, > > well, cheap. Although many keyboard controllers were programmed before > > there were any C-ish compilers for tiny 8-bit micros, someone in the > > late 1970s who had one of today's C-ish compilers for the PIC16C57 (and > > something to run it on) could probably have written keyboard controller > > firmware more quickly than using assembly language > > Maybe, but how long would it have taken, compared with other design > tasks such as drawing the schematics, making the PCB layout, making and > debugging the prototype board (and sourcing all the actual keys and > microswitches)? A keyboard controller would be simple enough that assembly language would be reasonable, even though C would be faster. Projects of that complexity would have taken me 3-5 days in assembly language before I got C compilers, but about a day now. On the other hand, maintenance on assembly-language code is much harder than maintenance on C code for which a working C implementation is available. > > Actually, if I were in charge of standards I would mark many features > > like double-precision floating-point math as things that quality > > implementations should seek to provide whenever possible, > > Double precision is a big deal. Even on x86, you would avoid 64-bit > floating point if it had to be done in software. You wouldn't demand it > of a microcontroller. I meant to say "whenever practical". I would expect that in many cases the author of an implementation should be able to exercise good judgment about whether any effort that would be required to implement double-precision math might be better spent on other features customers might find more useful. If a program uses type "double" and doesn't include a directive waiving the precision guarantees given in the Standard, a conforming implementation should not be allowed to accept the program without honoring such guarantees, but I would make it clear that conforming implementations may *reject* such programs. From my mind, the Standard shouldn't focus on trying to maximize the number of useful tasks that implementations would be required to be capable of processing correctly, but instead maximize the number of tasks that implementations can be forbidden from performing incorrectly (while still being allowed to perform them correctly). If a program requires a feature that a compiler can't support, that would not imply that the program was "defective". If the target platform cannot efficiently handle that feature, the program may be unsuitable for use on that platform (but suitable for use on others). If the target platform could easily handle the feature but the compiler can't, that would suggest that the compiler is of low quality. Behavior would be *defined* in any case, however, whether or not an implementation was able to accept such a definition. > but allow > > low-end implementations that couldn't very well provide them to be > > recognized as conforming nonetheless. Many of the cases where C offers > > the biggest advantages over machine code are those which involve math > > larger than a CPU's register size. If x, y, and z are 16 bits, it's > > a lot easier to read or write: > > > > x=y+z; > > > > than > > > > movf y,w ; WREG = lower byte of y > > addwf z,w ; WREG += lower byte of z > > movwf x ; store lower byte of x > > movf y+1,w ; WREG = upper byte of y > > btfsc 3,0 ; Skip next instruction if carry not set > > incf y+1,w ; WREG = 1 + upper byte of y > > addwf z+1,w ; WREG += upper byte of z > > movwf x+1 ; store upper byte of x > > Except that it probably wouldn't be done that way. You'd use a function, > or whatever macro facilities the assembler had. (And actually in those > days I'd have to write my assembler first. I would a few things to make > life easier.) Code for 8-bit processors generally was done that way. I've seen some people try to use macros to simplify things, but such macros often end up with weird corner-case behaviors that can only be reasoned out by examining the generated code, in which case one may as well have simply written it. As a simple example, optimal code for 16-bit x+=y can leave the carry flag set according to the overall result, but getting an accurate carry out from x=y+z would require an extra instruction (BTW, I think the PIC architecture may have been around for over a decade before anyone figured out *how* to get an accurate carry out from 16-bit x+=y). > Programmers will always find a way of not having to do so much work. That's what C compilers are for.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-25 01:04 +0100 |
| Message-ID | <RJXxB.962520$cS2.593594@fx19.am4> |
| In reply to | #120254 |
On 25/09/2017 00:14, supercat@casperkitty.com wrote: > On Sunday, September 24, 2017 at 5:10:40 PM UTC-5, Bart wrote: >> Programmers will always find a way of not having to do so much work. > > That's what C compilers are for. I've always had problems using other people's languages and tools. 90% of the time would be spent battling against one thing or another. In the early 80s, if I'd had to use C on my Z80 computers (or even IBM PC), then I would never have got the amount of work done that I did. (Apparently they could take minutes to compile and link the simplest program.) So they wouldn't have help /me/ very much.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-24 17:23 -0700 |
| Message-ID | <7d271010-8263-4dda-9f52-64a2bc6203d9@googlegroups.com> |
| In reply to | #120258 |
On Sunday, September 24, 2017 at 7:04:09 PM UTC-5, Bart wrote: > In the early 80s, if I'd had to use C on my Z80 computers (or even IBM > PC), then I would never have got the amount of work done that I did. > (Apparently they could take minutes to compile and link the simplest > program.) > > So they wouldn't have help /me/ very much. Well-designed tools shouldn't take that long even on a floppy-based PC. The PC never good any C compilers that were as fast as its Pascal compiler, but Turbo C around 1986 was way better than its predecessors.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 08:48 +0200 |
| Message-ID | <oqa8sa$o13$1@dont-email.me> |
| In reply to | #120246 |
On 24/09/17 22:53, bartc wrote: > On 24/09/2017 21:17, supercat@casperkitty.com wrote: >> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: >>> 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.) >> >> It is possible to build a keyboard controller out of discrete logic, but >> unless one wants to have the main processor scan the keyboard using a >> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, >> and likely many other machines as well) the amount of logic required is >> fairly substantial. Microcontrollers that could act as all-in-one-chip >> solutions were developed in the 1970s, so except in cases where the >> VIC-20-style keyboard scanning would be practical they provide the >> cheapest >> way of interfacing keyboards. > > I don't think the logic is that difficult. You wouldn't have discrete > logic chips (74 series gates etc) anyway, there can be a custom chip but > it needn't be a microcontroller. > The complexity depends on the details you want from the keyboard control. Do you want to support multiple key presses, or just one (and perhaps a few dedicated shift keys)? That makes a /huge/ difference. Do you want the logic to handle debounces? Do you want it to handle repeats? Do you want it all to be turned into a serial protocol for communication to the computer - and if so, what protocol? Do you want to handle caps-lock and the like automatically on the keyboard? There are lots of options here, and different choices have been made through the ages - leading to wildly different complexity levels. > The first keyboard I bought was accessed via a 8-bit port; I think the > top bit indicated a key was ready. > > The ones my company bought for its microcomputers I think had a more > elaborate controller, but were still accessed in parallel mode (via a > flat cable as it was in the same case). I forget the details, but > certainly nothing as hairy as a floppy or hard disk controller. > > Anyway, suppose there was a programmable controller involved; how many > lines of line would be needed? Would it really be necessary to use C; > does no other language - other than the controller's machine code - > exist that works at this level? > Small microcontrollers used to be programmed mainly in assembly. These days, there is still some assembly programming being done but most is in C. For larger devices (mainly 32-bit microcontollers), C++ is also popular. And there has always been a segment that uses Forth, along with a small number of other languages (Pascal, Ada, Basic, Micropython).
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-25 11:50 -0700 |
| Message-ID | <e7a0814e-edda-4e79-8b50-9dc416aa7e0e@googlegroups.com> |
| In reply to | #120271 |
On Sunday, September 24, 2017 at 11:48:55 PM UTC-7, David Brown wrote: > On 24/09/17 22:53, bartc wrote: > > On 24/09/2017 21:17, supercat@casperkitty.com wrote: > >> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: > >>> 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.) > >> > >> It is possible to build a keyboard controller out of discrete logic, but > >> unless one wants to have the main processor scan the keyboard using a > >> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, > >> and likely many other machines as well) the amount of logic required is > >> fairly substantial. Microcontrollers that could act as all-in-one-chip > >> solutions were developed in the 1970s, so except in cases where the > >> VIC-20-style keyboard scanning would be practical they provide the > >> cheapest > >> way of interfacing keyboards. > > > > I don't think the logic is that difficult. You wouldn't have discrete > > logic chips (74 series gates etc) anyway, there can be a custom chip but > > it needn't be a microcontroller. > > > > The complexity depends on the details you want from the keyboard > control. Do you want to support multiple key presses, or just one (and > perhaps a few dedicated shift keys)? That makes a /huge/ difference. > Do you want the logic to handle debounces? Do you want it to handle > repeats? Do you want it all to be turned into a serial protocol for > communication to the computer - and if so, what protocol? Do you want > to handle caps-lock and the like automatically on the keyboard? A keyboard is - basically - just an array of "switches" - 110 (I think) on the board I'm using. The minimum information one of these "switched" could transmit is a signal whenever it changes state (pressed or released). From this POV the mouse buttons are just more keys. At this level I don't think computer control is needed. We could let the main computer handle all the details. If we had a surplus of cores we could just dedicate one. But having a separate micro-computer seems like a cheaper solution than grabbing a core. Whether that micro-controller is in the keyboard or the computer seems to be a matter of taste. I think the same comments apply to all the other peripherals (except memories - which I do not consider peripherals no matter how exterior they are).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 21:59 +0200 |
| Message-ID | <oqbn6c$pst$1@dont-email.me> |
| In reply to | #120319 |
On 25/09/17 20:50, David Kleinecke wrote: > On Sunday, September 24, 2017 at 11:48:55 PM UTC-7, David Brown wrote: >> On 24/09/17 22:53, bartc wrote: >>> On 24/09/2017 21:17, supercat@casperkitty.com wrote: >>>> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: >>>>> 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.) >>>> >>>> It is possible to build a keyboard controller out of discrete logic, but >>>> unless one wants to have the main processor scan the keyboard using a >>>> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, >>>> and likely many other machines as well) the amount of logic required is >>>> fairly substantial. Microcontrollers that could act as all-in-one-chip >>>> solutions were developed in the 1970s, so except in cases where the >>>> VIC-20-style keyboard scanning would be practical they provide the >>>> cheapest >>>> way of interfacing keyboards. >>> >>> I don't think the logic is that difficult. You wouldn't have discrete >>> logic chips (74 series gates etc) anyway, there can be a custom chip but >>> it needn't be a microcontroller. >>> >> >> The complexity depends on the details you want from the keyboard >> control. Do you want to support multiple key presses, or just one (and >> perhaps a few dedicated shift keys)? That makes a /huge/ difference. >> Do you want the logic to handle debounces? Do you want it to handle >> repeats? Do you want it all to be turned into a serial protocol for >> communication to the computer - and if so, what protocol? Do you want >> to handle caps-lock and the like automatically on the keyboard? > > A keyboard is - basically - just an array of "switches" - 110 > (I think) on the board I'm using. The minimum information one > of these "switched" could transmit is a signal whenever it > changes state (pressed or released). From this POV the mouse > buttons are just more keys. At this level I don't think computer > control is needed. We could let the main computer handle all the > details. If we had a surplus of cores we could just dedicate one. > But having a separate micro-computer seems like a cheaper > solution than grabbing a core. Whether that micro-controller is > in the keyboard or the computer seems to be a matter of taste. > > I think the same comments apply to all the other peripherals > (except memories - which I do not consider peripherals no matter > how exterior they are). > And that shows the difference between someone has designed keyboards, and who works with microcontrollers, switches, inputs, electronics, etc., and someone who sees a keyboard as just something that plugs into a computer and works by magic.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-25 14:25 -0700 |
| Message-ID | <5fc82c84-6e50-437a-98a4-b9a9822ea16d@googlegroups.com> |
| In reply to | #120323 |
On Monday, September 25, 2017 at 12:59:25 PM UTC-7, David Brown wrote: > On 25/09/17 20:50, David Kleinecke wrote: > > On Sunday, September 24, 2017 at 11:48:55 PM UTC-7, David Brown wrote: > >> On 24/09/17 22:53, bartc wrote: > >>> On 24/09/2017 21:17, supercat@casperkitty.com wrote: > >>>> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: > >>>>> 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.) > >>>> > >>>> It is possible to build a keyboard controller out of discrete logic, but > >>>> unless one wants to have the main processor scan the keyboard using a > >>>> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, > >>>> and likely many other machines as well) the amount of logic required is > >>>> fairly substantial. Microcontrollers that could act as all-in-one-chip > >>>> solutions were developed in the 1970s, so except in cases where the > >>>> VIC-20-style keyboard scanning would be practical they provide the > >>>> cheapest > >>>> way of interfacing keyboards. > >>> > >>> I don't think the logic is that difficult. You wouldn't have discrete > >>> logic chips (74 series gates etc) anyway, there can be a custom chip but > >>> it needn't be a microcontroller. > >>> > >> > >> The complexity depends on the details you want from the keyboard > >> control. Do you want to support multiple key presses, or just one (and > >> perhaps a few dedicated shift keys)? That makes a /huge/ difference. > >> Do you want the logic to handle debounces? Do you want it to handle > >> repeats? Do you want it all to be turned into a serial protocol for > >> communication to the computer - and if so, what protocol? Do you want > >> to handle caps-lock and the like automatically on the keyboard? > > > > A keyboard is - basically - just an array of "switches" - 110 > > (I think) on the board I'm using. The minimum information one > > of these "switched" could transmit is a signal whenever it > > changes state (pressed or released). From this POV the mouse > > buttons are just more keys. At this level I don't think computer > > control is needed. We could let the main computer handle all the > > details. If we had a surplus of cores we could just dedicate one. > > But having a separate micro-computer seems like a cheaper > > solution than grabbing a core. Whether that micro-controller is > > in the keyboard or the computer seems to be a matter of taste. > > > > I think the same comments apply to all the other peripherals > > (except memories - which I do not consider peripherals no matter > > how exterior they are). > > > > And that shows the difference between someone has designed keyboards, > and who works with microcontrollers, switches, inputs, electronics, > etc., and someone who sees a keyboard as just something that plugs into > a computer and works by magic. I would say it shows the difference between making useful abstractions and getting tangled up in the details. I'm a mathematician by training and I like to abstract away from irrelevant details and get to the guts of the matter. The keyboard I described is not a real-life keyboard. You might call it the Platonic ideal of a keyboard. Then real-life keyboards can be described in terms of how the deviate from the ideal. It is unclear what the ideal programming language is - but I don't think there is much to argue about concerning keyboards.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-26 09:39 +0200 |
| Message-ID | <oqd07q$vgj$1@dont-email.me> |
| In reply to | #120334 |
On 25/09/17 23:25, David Kleinecke wrote: > On Monday, September 25, 2017 at 12:59:25 PM UTC-7, David Brown wrote: >> On 25/09/17 20:50, David Kleinecke wrote: >>> On Sunday, September 24, 2017 at 11:48:55 PM UTC-7, David Brown wrote: >>>> On 24/09/17 22:53, bartc wrote: >>>>> On 24/09/2017 21:17, supercat@casperkitty.com wrote: >>>>>> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: >>>>>>> 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.) >>>>>> >>>>>> It is possible to build a keyboard controller out of discrete logic, but >>>>>> unless one wants to have the main processor scan the keyboard using a >>>>>> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, >>>>>> and likely many other machines as well) the amount of logic required is >>>>>> fairly substantial. Microcontrollers that could act as all-in-one-chip >>>>>> solutions were developed in the 1970s, so except in cases where the >>>>>> VIC-20-style keyboard scanning would be practical they provide the >>>>>> cheapest >>>>>> way of interfacing keyboards. >>>>> >>>>> I don't think the logic is that difficult. You wouldn't have discrete >>>>> logic chips (74 series gates etc) anyway, there can be a custom chip but >>>>> it needn't be a microcontroller. >>>>> >>>> >>>> The complexity depends on the details you want from the keyboard >>>> control. Do you want to support multiple key presses, or just one (and >>>> perhaps a few dedicated shift keys)? That makes a /huge/ difference. >>>> Do you want the logic to handle debounces? Do you want it to handle >>>> repeats? Do you want it all to be turned into a serial protocol for >>>> communication to the computer - and if so, what protocol? Do you want >>>> to handle caps-lock and the like automatically on the keyboard? >>> >>> A keyboard is - basically - just an array of "switches" - 110 >>> (I think) on the board I'm using. The minimum information one >>> of these "switched" could transmit is a signal whenever it >>> changes state (pressed or released). From this POV the mouse >>> buttons are just more keys. At this level I don't think computer >>> control is needed. We could let the main computer handle all the >>> details. If we had a surplus of cores we could just dedicate one. >>> But having a separate micro-computer seems like a cheaper >>> solution than grabbing a core. Whether that micro-controller is >>> in the keyboard or the computer seems to be a matter of taste. >>> >>> I think the same comments apply to all the other peripherals >>> (except memories - which I do not consider peripherals no matter >>> how exterior they are). >>> >> >> And that shows the difference between someone has designed keyboards, >> and who works with microcontrollers, switches, inputs, electronics, >> etc., and someone who sees a keyboard as just something that plugs into >> a computer and works by magic. > > I would say it shows the difference between making useful > abstractions and getting tangled up in the details. I'm a > mathematician by training and I like to abstract away from > irrelevant details and get to the guts of the matter. The > keyboard I described is not a real-life keyboard. You might > call it the Platonic ideal of a keyboard. Then real-life > keyboards can be described in terms of how the deviate from > the ideal. The discussion was about what was needed to /implement/ a keyboard - how much electronics or control is needed or desired. I gave a brief overview of a number of points that need to be considered there, and why it is actually quite a complex process. Like most people, you see a keyboard as working by magic with no concept of how it works in the electronics, or its firmware, and no concept of how an OS turns that into characters on the screen. You press the keys, and characters appear in your Usenet post or your editor - what happens in between is a mystery to you. That is, of course, absolutely fine - its the way most people work, and it is a perfectly good abstraction. But where you go completely wrong is when you then assume that because a keyboard /appears/ simple to you in use, it must be simple in its design and implementation. The detail that is irrelevant for the use of the keyboard is most certainly /not/ irrelevant to a discussion on its implementation. And being a "mathematician by training" does not give you an excuse for thinking that "abstractions" and "Platonic ideals" are all that matters - far from it. You are supposed to be interested in what is going on underneath, or at the very least in knowing that there are others who understand it so that you can use the result. > > It is unclear what the ideal programming language is - but > I don't think there is much to argue about concerning > keyboards. > It is, I think, very clear what the ideal programming language is - it is an impossibility. Different languages are useful for different tasks. The "ideal programming language" makes no more sense than "the ideal method of transport". And it is quite possible to have a discussion (not argument) about some aspects of keyboards - especially since these days they will all be programmed in C. It is harder, however, to have a reasonable discussion with someone who has no idea what he is talking about.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-26 11:50 -0700 |
| Message-ID | <64b9fe02-40f0-4690-b91f-f6a619aa40f6@googlegroups.com> |
| In reply to | #120340 |
On Tuesday, September 26, 2017 at 12:39:54 AM UTC-7, David Brown wrote: > On 25/09/17 23:25, David Kleinecke wrote: > > On Monday, September 25, 2017 at 12:59:25 PM UTC-7, David Brown wrote: > >> On 25/09/17 20:50, David Kleinecke wrote: > >>> On Sunday, September 24, 2017 at 11:48:55 PM UTC-7, David Brown wrote: > >>>> On 24/09/17 22:53, bartc wrote: > >>>>> On 24/09/2017 21:17, supercat@casperkitty.com wrote: > >>>>>> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: > >>>>>>> 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.) > >>>>>> > >>>>>> It is possible to build a keyboard controller out of discrete logic, but > >>>>>> unless one wants to have the main processor scan the keyboard using a > >>>>>> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, > >>>>>> and likely many other machines as well) the amount of logic required is > >>>>>> fairly substantial. Microcontrollers that could act as all-in-one-chip > >>>>>> solutions were developed in the 1970s, so except in cases where the > >>>>>> VIC-20-style keyboard scanning would be practical they provide the > >>>>>> cheapest > >>>>>> way of interfacing keyboards. > >>>>> > >>>>> I don't think the logic is that difficult. You wouldn't have discrete > >>>>> logic chips (74 series gates etc) anyway, there can be a custom chip but > >>>>> it needn't be a microcontroller. > >>>>> > >>>> > >>>> The complexity depends on the details you want from the keyboard > >>>> control. Do you want to support multiple key presses, or just one (and > >>>> perhaps a few dedicated shift keys)? That makes a /huge/ difference. > >>>> Do you want the logic to handle debounces? Do you want it to handle > >>>> repeats? Do you want it all to be turned into a serial protocol for > >>>> communication to the computer - and if so, what protocol? Do you want > >>>> to handle caps-lock and the like automatically on the keyboard? > >>> > >>> A keyboard is - basically - just an array of "switches" - 110 > >>> (I think) on the board I'm using. The minimum information one > >>> of these "switched" could transmit is a signal whenever it > >>> changes state (pressed or released). From this POV the mouse > >>> buttons are just more keys. At this level I don't think computer > >>> control is needed. We could let the main computer handle all the > >>> details. If we had a surplus of cores we could just dedicate one. > >>> But having a separate micro-computer seems like a cheaper > >>> solution than grabbing a core. Whether that micro-controller is > >>> in the keyboard or the computer seems to be a matter of taste. > >>> > >>> I think the same comments apply to all the other peripherals > >>> (except memories - which I do not consider peripherals no matter > >>> how exterior they are). > >>> > >> > >> And that shows the difference between someone has designed keyboards, > >> and who works with microcontrollers, switches, inputs, electronics, > >> etc., and someone who sees a keyboard as just something that plugs into > >> a computer and works by magic. > > > > I would say it shows the difference between making useful > > abstractions and getting tangled up in the details. I'm a > > mathematician by training and I like to abstract away from > > irrelevant details and get to the guts of the matter. The > > keyboard I described is not a real-life keyboard. You might > > call it the Platonic ideal of a keyboard. Then real-life > > keyboards can be described in terms of how the deviate from > > the ideal. > > The discussion was about what was needed to /implement/ a keyboard - how > much electronics or control is needed or desired. I gave a brief > overview of a number of points that need to be considered there, and why > it is actually quite a complex process. > > Like most people, you see a keyboard as working by magic with no concept > of how it works in the electronics, or its firmware, and no concept of > how an OS turns that into characters on the screen. You press the keys, > and characters appear in your Usenet post or your editor - what happens > in between is a mystery to you. That is, of course, absolutely fine - > its the way most people work, and it is a perfectly good abstraction. It is the design specification for the keyboard. Abstractly I don't care how the design is actually implemented. I care what the designed device does. Life is too short for me to address the innards of every device I use. > But where you go completely wrong is when you then assume that because a > keyboard /appears/ simple to you in use, it must be simple in its design > and implementation. The detail that is irrelevant for the use of the > keyboard is most certainly /not/ irrelevant to a discussion on its > implementation. I fail to see how I assumed the innards are simple. I can see how a extremely undesirable keyboard might be made with toggle switches. OK - that is the existence proof - keyboards can be made. It is the task of clever engineers to do the same job more gracefully. That the solution might be quite complicated is a distinct possibility. But the task done remains simple. The matter is quite like the language standards. I was describing the keyboard at the level of the standards, But we don't care how a compiler actually works provided it acts as the standard proscribes. This is the black box model of a device. What matters is what the device does - not how it does it. A specialist will handle the internal details. > And being a "mathematician by training" does not give you an excuse for > thinking that "abstractions" and "Platonic ideals" are all that matters > - far from it. You are supposed to be interested in what is going on > underneath, or at the very least in knowing that there are others who > understand it so that you can use the result. I don't think I cast any aspersions on embedded programming. > > It is unclear what the ideal programming language is - but > > I don't think there is much to argue about concerning > > keyboards. You are worried about something I consider a black box. > It is, I think, very clear what the ideal programming language is - it > is an impossibility. Different languages are useful for different > tasks. The "ideal programming language" makes no more sense than "the > ideal method of transport". > > And it is quite possible to have a discussion (not argument) about some > aspects of keyboards - especially since these days they will all be > programmed in C. It is harder, however, to have a reasonable discussion > with someone who has no idea what he is talking about. You might be surprised at how much I know about the innards of keyboards. I wasn't discussing their innards. I was discussing their use.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-25 15:44 -0500 |
| Message-ID | <p4qisc5sfflj96r720hncl4pr9e7rhgulp@4ax.com> |
| In reply to | #120319 |
On Mon, 25 Sep 2017 11:50:44 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >On Sunday, September 24, 2017 at 11:48:55 PM UTC-7, David Brown wrote: >> On 24/09/17 22:53, bartc wrote: >> > On 24/09/2017 21:17, supercat@casperkitty.com wrote: >> >> On Sunday, September 24, 2017 at 9:32:51 AM UTC-5, Bart wrote: >> >>> 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.) >> >> >> >> It is possible to build a keyboard controller out of discrete logic, but >> >> unless one wants to have the main processor scan the keyboard using a >> >> timer-tick interrupt (the approach used by the VIC-20 and Commodore 64, >> >> and likely many other machines as well) the amount of logic required is >> >> fairly substantial. Microcontrollers that could act as all-in-one-chip >> >> solutions were developed in the 1970s, so except in cases where the >> >> VIC-20-style keyboard scanning would be practical they provide the >> >> cheapest >> >> way of interfacing keyboards. >> > >> > I don't think the logic is that difficult. You wouldn't have discrete >> > logic chips (74 series gates etc) anyway, there can be a custom chip but >> > it needn't be a microcontroller. >> > >> >> The complexity depends on the details you want from the keyboard >> control. Do you want to support multiple key presses, or just one (and >> perhaps a few dedicated shift keys)? That makes a /huge/ difference. >> Do you want the logic to handle debounces? Do you want it to handle >> repeats? Do you want it all to be turned into a serial protocol for >> communication to the computer - and if so, what protocol? Do you want >> to handle caps-lock and the like automatically on the keyboard? > >A keyboard is - basically - just an array of "switches" - 110 >(I think) on the board I'm using. The minimum information one >of these "switched" could transmit is a signal whenever it >changes state (pressed or released). From this POV the mouse >buttons are just more keys. At this level I don't think computer >control is needed. We could let the main computer handle all the >details. If we had a surplus of cores we could just dedicate one. >But having a separate micro-computer seems like a cheaper >solution than grabbing a core. Whether that micro-controller is >in the keyboard or the computer seems to be a matter of taste. > >I think the same comments apply to all the other peripherals >(except memories - which I do not consider peripherals no matter >how exterior they are). Other than a few additional functions, that's what keyboards already do. The main data transmitted by a PC-style keyboard consists of make and break scancodes. It's just if you have one serial connection, and 100+ keys, by far the easiest way to handle that is by putting a microcontroller in the keyboard and letting it handle the scanning* of the keyboard array on one side and the serial communication on the other. And once you have some smarts in the keyboard, it becomes reasonable to handle things like keyboard repeat in the keyboard, although that's clearly not necessary. You can also do things like handle indicator lights fairly easily. Making the keyboard USB really only wraps that basic protocol in USB. *The work in scanning, debounce and rollover make that a non-trivial exercise.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-24 18:57 -0400 |
| Message-ID | <oq9d9e$kmq$1@jstuckle.eternal-september.org> |
| In reply to | #120230 |
On 9/24/2017 10:32 AM, bartc 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.) > Yes, and automobiles can do just fine with a carburetor and a hand crank to start. Just because keyboards 30 years ago didn't have microcontrollers means nothing. > The 'nonsense' you mention is presumably my suggestion to concentrate on > 8, 16, 32 and 64-bit data types. > And take most of the electronics in your house and car back to the 1960's. > This is the same nonsense as adopted by Java, Go, D, C# and Rust. How > are /those/ used on microcontrollers? Or do they just leave that side of > things to C! > Those languages aren't used on microcontrollers. > Well, I'm sure it's been suggested many times that C should have split > into a language still suitable for all those dozens of assorted devices, > and a one aimed at the sorts of processors we're all using when posting > to usenet or running compilers. > You can keep suggesting it. The rest of the world disagrees with you. But hey - you're free to create your own language. > 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. -- ================== 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 00:08 +0100 |
| Message-ID | <nVWxB.1093077$lQ6.913706@fx29.am4> |
| In reply to | #120252 |
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. -- bartc
[toc] | [prev] | [next] | [standalone]
Page 2 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