Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94192 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2016-09-28 09:35 -0700 |
| Last post | 2016-09-28 20:20 +0100 |
| Articles | 20 on this page of 135 — 24 participants |
Back to article view | Back to comp.lang.c
Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:35 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 09:39 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:46 -0700
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 17:53 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-09-28 21:21 +0200
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-28 20:36 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 13:55 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:02 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:03 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:13 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:22 +1300
Re: Is there any place to talk about language features? Robert Latest <boblatest@yahoo.com> - 2016-10-03 08:47 +0000
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 07:44 -0400
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 04:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:18 +0100
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-10-03 12:43 -0500
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-03 21:43 +0000
Re: Is there any place to talk about language features? John Gordon <gordon@panix.com> - 2016-10-03 22:28 +0000
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 04:51 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:10 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 05:48 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 14:03 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 14:24 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 19:16 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:16 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:45 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:57 -0700
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 08:21 -0400
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 05:31 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 06:43 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-03 15:08 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:22 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 15:16 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 16:08 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 16:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 14:19 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:50 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:03 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-29 01:08 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:33 -0700
Re: Is there any place to talk about language features? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-29 01:02 +0000
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 01:39 -0500
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-29 00:48 -0700
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 11:59 -0500
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 08:09 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 12:14 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 09:07 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 13:53 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-09-30 22:13 +0100
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:36 +0000
Re: Is there any place to talk about language features? Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-01 13:04 -0400
Re: Is there any place to talk about language features? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-30 14:20 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-30 22:30 +0100
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:30 +0000
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 01:51 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 10:31 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 23:22 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 06:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 15:28 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 10:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 19:52 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-02 20:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 03:37 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 08:35 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 15:17 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 18:29 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 01:09 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-04 08:21 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 13:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 14:34 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 00:47 -0700
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-04 07:49 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 07:50 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-04 08:57 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 10:42 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 15:47 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 20:58 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 18:14 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 02:15 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 22:44 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:12 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:50 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:25 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 21:19 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 18:11 +1300
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-06 06:38 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-06 00:36 -0700
Re: Is there any place to talk about language features? gwowen <gwowen@gmail.com> - 2016-10-06 07:33 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 09:00 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:32 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:05 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-07 08:13 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:20 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-07 17:01 +0100
Re: Is there any place to talk about language features? Les Cargill <lcargill99@comcast.com> - 2016-10-05 12:45 -0500
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 11:12 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:41 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 08:01 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 08:41 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 10:29 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 12:29 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 11:08 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:35 +0100
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 18:15 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 10:38 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 19:14 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 11:56 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 11:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-05 12:18 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-05 21:49 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 13:07 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-05 16:23 -0400
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 14:26 +0200
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 13:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-06 14:17 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 15:53 +0200
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-06 09:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 11:28 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:31 +1300
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:32 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:43 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:05 +1300
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:24 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-09-30 16:17 -0700
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:39 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-01 14:11 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 07:47 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 10:25 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-28 12:59 -0400
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 18:30 +0100
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 12:10 -0700
Re: Is there any place to talk about language features? James Harris <james.harris.1@gmail.com> - 2016-09-28 20:20 +0100
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-03 05:48 -0700 |
| Message-ID | <1efd49d0-a110-4231-be01-0c94b27cef31@googlegroups.com> |
| In reply to | #94414 |
On Monday, October 3, 2016 at 1:10:58 PM UTC+1, Bart wrote: > > (One example: your source language always interprets an 'int' type as 32 > bits wide by default. But do you translate it as 'int', which may have > different widths depending on the target C implementation, or as the > less readable 'int32_t'?) > B64 is designed to get round that type of problem. Operations on integers are always 64 bits. So as long as the integers actually count or index something sensible, there will never be an arithmetical overflow. But there's also going to be a concept of "bit buffers". So if you use 32 bit little endian integers, you can set them up in bit buffers and B64 will accept the data in that format and give you the results back in that format. By defining interfaces in terms of bits rather than types, we get rid of the problem of incompatible programming languages. As long as you can set up bits and read bits, you can inter-operate with B64.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-03 14:03 +0100 |
| Message-ID | <nstktu$1on$1@dont-email.me> |
| In reply to | #94418 |
On 03/10/2016 13:48, Malcolm McLean wrote: > On Monday, October 3, 2016 at 1:10:58 PM UTC+1, Bart wrote: >> >> (One example: your source language always interprets an 'int' type as 32 >> bits wide by default. But do you translate it as 'int', which may have >> different widths depending on the target C implementation, or as the >> less readable 'int32_t'?) >> > B64 is designed to get round that type of problem. > Operations on integers are always 64 bits. So as long as the integers actually count or > index something sensible, there will never be an arithmetical overflow. Let's say you get around to implementing this and decide at first to target standard C. Will a 'B64' integer type be represented as int64_t, uint64_t, or as [signed/unsigned] long long int? (Also, to add to the other issues discussed in the past, you want to run this simple language on a Raspberry Pi, which uses a 32-bit processor. How efficient is it going to be, on this already slow machine, if everything needs to be calculated with 64 bits? I'm actually facing some questions like that now: I need to use 64-bits to solve some problems, which is fine on a desktop, even 32 bits, but is going to be inefficient on 32-bit ARM.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-03 14:24 +0100 |
| Message-ID | <87h98t4lbh.fsf@bsb.me.uk> |
| In reply to | #94419 |
BartC <bc@freeuk.com> writes: > On 03/10/2016 13:48, Malcolm McLean wrote: >> On Monday, October 3, 2016 at 1:10:58 PM UTC+1, Bart wrote: >>> >>> (One example: your source language always interprets an 'int' type as 32 >>> bits wide by default. But do you translate it as 'int', which may have >>> different widths depending on the target C implementation, or as the >>> less readable 'int32_t'?) >>> >> B64 is designed to get round that type of problem. Having only one integer type does not get round the problem. Rather than have a suitable target type, you now have to generate code that emulates the size demanded by the source language. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-03 07:07 -0700 |
| Message-ID | <a3da4c90-3f19-4e61-8730-07fa4cc7fe8c@googlegroups.com> |
| In reply to | #94421 |
On Monday, October 3, 2016 at 2:24:42 PM UTC+1, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > > >> B64 is designed to get round that type of problem. > > Having only one integer type does not get round the problem. Rather > than have a suitable target type, you now have to generate code that > emulates the size demanded by the source language. > It largely does. Data comes in as, say, 32 bit little endian, and goes out as, just for fun, 16 bit big endian. All intermediate calculations are carried out in 64 bits, and if the result overflows 16 bits what do we do? I haven't decided on that one. So it works, unless user wants to use the size as a free modulus operation. Which to be fair some people do for char differences. All other code should just work.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-03 19:16 +0100 |
| Message-ID | <87ponh2t7v.fsf@bsb.me.uk> |
| In reply to | #94423 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, October 3, 2016 at 2:24:42 PM UTC+1, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> > >> >> B64 is designed to get round that type of problem. >> >> Having only one integer type does not get round the problem. Rather >> than have a suitable target type, you now have to generate code that >> emulates the size demanded by the source language. >> > It largely does. I see. I am beginning to understand how you use language. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-03 07:16 -0700 |
| Message-ID | <047a0153-7e66-418a-a778-0bd4271a7876@googlegroups.com> |
| In reply to | #94419 |
On Monday, October 3, 2016 at 2:03:16 PM UTC+1, Bart wrote: > On 03/10/2016 13:48, Malcolm McLean wrote: > > On Monday, October 3, 2016 at 1:10:58 PM UTC+1, Bart wrote: > >> > >> (One example: your source language always interprets an 'int' type as 32 > >> bits wide by default. But do you translate it as 'int', which may have > >> different widths depending on the target C implementation, or as the > >> less readable 'int32_t'?) > >> > > B64 is designed to get round that type of problem. > > Operations on integers are always 64 bits. So as long as the integers actually count or > > index something sensible, there will never be an arithmetical overflow. > > Let's say you get around to implementing this and decide at first to > target standard C. > > Will a 'B64' integer type be represented as int64_t, uint64_t, or as > [signed/unsigned] long long int? > > (Also, to add to the other issues discussed in the past, you want to run > this simple language on a Raspberry Pi, which uses a 32-bit processor. > How efficient is it going to be, on this already slow machine, if > everything needs to be calculated with 64 bits? > > I'm actually facing some questions like that now: I need to use 64-bits > to solve some problems, which is fine on a desktop, even 32 bits, but is > going to be inefficient on 32-bit ARM.) > Yes, B64 makes sense in a world where processors can address more then 4GB of memory so have a fast 64 bit integer type. If that's not the case, then we've got problems, because reals often need to be 64 bits for precision reasons, and whilst most integers count or index things in memory, that's not universally the case, and a count of "something sensible" can go above 2 billion, e.g. people in the world. So we can't make all types the same size, and once you've lost that, you've destroyed half of the vision of B64.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-03 07:45 -0700 |
| Message-ID | <07830ed9-3a8b-4077-8ccb-9965a30a4620@googlegroups.com> |
| In reply to | #94424 |
On Monday, October 3, 2016 at 9:16:22 AM UTC-5, Malcolm McLean wrote: > Yes, B64 makes sense in a world where processors can address more then 4GB > of memory so have a fast 64 bit integer type. If that's not the case, then we've > got problems, because reals often need to be 64 bits for precision reasons, > and whilst most integers count or index things in memory, that's not universally > the case, and a count of "something sensible" can go above 2 billion, e.g. > people in the world. So we can't make all types the same size, and once you've > lost that, you've destroyed half of the vision of B64. I would suggest that it is very useful to be able to use types smaller than 64 bits within aggregates and have the compiler take care of loading and storing them. I would also suggest that if you want to facilitate optimization, you should distinguish between types which guarantee that any value stored into them will be either zero- or sign-extended past a certain length, and types which promise to hold at least a certain number of bits, and where storing in-range values will cause upper bits to read consistently as written, but where the upper bits of out-of-range values may behave in non-deterministic fashion [allowing such behavior would allow 99% of the useful optimizations that can be achieved by making such behavior UB, but avoid the costs of having to guard against out-of-range values in cases where such non-deterministic behavior might be acceptable].
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-03 07:57 -0700 |
| Message-ID | <8acd8cc0-f077-411d-a62c-9425694c3ab1@googlegroups.com> |
| In reply to | #94424 |
On Monday, October 3, 2016 at 9:16:22 AM UTC-5, Malcolm McLean wrote:
> Yes, B64 makes sense in a world where processors can address more then 4GB
> of memory so have a fast 64 bit integer type.
Even on smaller processors, having all calculations be performed as 64-bit
two's-complement signed integers may be just fine if the language includes
types which promise *at least* 8, 16, or 32 bits but allow for the possibility
of larger types. While achieving good performance on a 32-bit machine may
require that some intermediate expression results be cast to an "at least 32
bit" type to let the compiler know it doesn't have to keep track of the upper
bits, in most contexts a compiler would be able to figure that out for itself.
For example, if "u32" means "Unsigned, at least 32 bits", and "u32x" means
"unsigned, exactly 32 bits", then given something like:
u32 a,b,c,v1,v2,v3; ...
v1=(a*b+c)/4;
v2=(u32)(a*b+c)/4;
v3=(u32x)(a*b+c)/4;
computation of v1 would require that a compiler keep the result of the
multiply and addition as 64 bits, computation of v2 would allow the
compiler to process the intermediate results non-deterministically as 32
or 64 bits at its leisure, and computation of v3 would require the compiler
to truncate the result of the addition to 32 bits (implying that there
would be no need to perform the multiplication and addition as 64 bits,
though a compiler could do so if so inclined).
Note that unlike C, where casts are needed to ensure correctness of code
that works with large numbers on small processors, here casts would only
be needed if code is running on smaller processors *and* code was
unacceptably inefficient on smaller processors. Consequently, the language
could be better than C *even on small processors*.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-10-03 08:21 -0400 |
| Message-ID | <nstifi$p9b$1@dont-email.me> |
| In reply to | #94412 |
On 10/03/2016 07:51 AM, Thiago Adams wrote: > On Monday, October 3, 2016 at 5:48:09 AM UTC-3, Robert Latest wrote: >> Ian Collins wrote: >>> I do find the >> >> [...] >> >>> syntax very useful in C++ and adding it to C wouldn't break any existing >>> code. >> >> The problem with adding new features to any language is not about breaking >> existing code. It's about breaking existing compilers. For C, there is a >> plethora of compilers out there, many still used for embedded systems where >> support ceased decades ago. > > I think the solution for this dilemma could be: > > - Leave C language focused on generate code. > > - Open the door for standard annotations. For instance, create a syntax that is a kind of comment without affect code generation. (Kind of #pragma) (C++ has now [[attributes]]) > So compilers will with this features will work with unknown annotations (future) that doesn't affected the generated code. > > - Experimentation with more generic macros. This could allow experimentation with new features without broke compilers (Hygienic macros). > > - For last, transpilers C to OlD C. This would require tooling. Could you explain how this would work and how it would be different from the current state of affairs? We already have #pragma, and implementations are already free to choose which version of the standard to conform to (and to give users the option to control the version). Let's take a recent case - C2011 added support for multi-threaded code. They not only added <threads.h> and <stdatomic.h>, they also added new language features (_Atomic, _Thread_local). They extensively changed the wording to be more precise about sequencing, in order to more precisely specify what it is that multi-threaded code is allowed to do with regard to modifying the sequence in which events occur. Let's pretend that C2016 adds whatever feature(s?) your idea requires it it add. Using the approach you're suggesting, how would a program making extensive used of threading, a program who's functionality depends upon multi-threaded code working as specified by C2011, be transpiled from C2016 to C90?
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-03 05:31 -0700 |
| Message-ID | <2ce51b4c-f9dc-4c66-a7a1-2c8fe3070c8c@googlegroups.com> |
| In reply to | #94416 |
On Monday, October 3, 2016 at 9:21:26 AM UTC-3, James Kuyper wrote: > On 10/03/2016 07:51 AM, Thiago Adams wrote: > > On Monday, October 3, 2016 at 5:48:09 AM UTC-3, Robert Latest wrote: > >> Ian Collins wrote: > >>> I do find the > >> > >> [...] > >> > >>> syntax very useful in C++ and adding it to C wouldn't break any existing > >>> code. > >> > >> The problem with adding new features to any language is not about breaking > >> existing code. It's about breaking existing compilers. For C, there is a > >> plethora of compilers out there, many still used for embedded systems where > >> support ceased decades ago. > > > > I think the solution for this dilemma could be: > > > > - Leave C language focused on generate code. > > > > - Open the door for standard annotations. For instance, create a syntax that is a kind of comment without affect code generation. (Kind of #pragma) (C++ has now [[attributes]]) > > So compilers will with this features will work with unknown annotations (future) that doesn't affected the generated code. > > > > - Experimentation with more generic macros. This could allow experimentation with new features without broke compilers (Hygienic macros). > > > > - For last, transpilers C to OlD C. This would require tooling. > > Could you explain how this would work and how it would be different from > the current state of affairs? We already have #pragma, and > implementations are already free to choose which version of the standard > to conform to (and to give users the option to control the version). > > Let's take a recent case - C2011 added support for multi-threaded code. > They not only added <threads.h> and <stdatomic.h>, they also added new > language features (_Atomic, _Thread_local). They extensively changed the > wording to be more precise about sequencing, in order to more precisely > specify what it is that multi-threaded code is allowed to do with regard > to modifying the sequence in which events occur. > > Let's pretend that C2016 adds whatever feature(s?) your idea requires it > it add. Using the approach you're suggesting, how would a program making > extensive used of threading, a program who's functionality depends upon > multi-threaded code working as specified by C2011, be transpiled from > C2016 to C90? All these features works in a limited way. My compiler (Visual C) doesn't have _Atomic. But I can use some interlocked functions.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-03 06:43 -0700 |
| Message-ID | <dcb6df25-b549-4dd6-b0e7-79423eebd7a4@googlegroups.com> |
| In reply to | #94416 |
On Monday, October 3, 2016 at 7:21:26 AM UTC-5, James Kuyper wrote: > Let's pretend that C2016 adds whatever feature(s?) your idea requires it > it add. Using the approach you're suggesting, how would a program making > extensive used of threading, a program who's functionality depends upon > multi-threaded code working as specified by C2011, be transpiled from > C2016 to C90? If C had added threading support with old-compiler compatibility in mind, then a lot of the required features could be supported on existing systems merely through a combination of macros, libraries, and having a compiler refrain from making certain optimizations (which in the case of older compilers may be the natural state of affairs).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-03 15:08 +0200 |
| Message-ID | <nstl87$2um$1@dont-email.me> |
| In reply to | #94410 |
On 03/10/16 10:47, Robert Latest wrote: > Ian Collins wrote: >> I do find the > > [...] > >> syntax very useful in C++ and adding it to C wouldn't break any existing >> code. > > The problem with adding new features to any language is not about breaking > existing code. It's about breaking existing compilers. For C, there is a > plethora of compilers out there, many still used for embedded systems where > support ceased decades ago. Suppose someone were starting to learn "C with > features" down the road, only to find that the system they're targeting > doesn't support these features? If I had a job teaching (or writing books > about) C, I'd teach C89, giving my students the widest possible base for > future jobs (at the expense of a few inconveniences). As someone who writes embedded software, and sometimes has to deal with legacy software and ancient tools, I don't find this a problem. And I would definitely /not/ recommend anyone write in C89 unless they have no choice. In the embedded world, limited tools are sometimes a fact of life. The compiler may be old, it may be poor at optimising, it may be non-standard in order to make more efficient code on a particular odd microcontroller, or it may simply be full of bugs, limitations or odd behaviour. When you have to deal with such tools, you have to write your code in a way that works with them. But such tools are mostly a thing of the past. The solid majority of modern toolchains for modern cpus have good support for standard C with modern features. Certainly they will support all meaningful parts of C99 - many have at least some C11 features. (And they will typically also support C++11 or C++14.) The ability to use full-featured optimising compilers with modern language support, rather than a weird and restricted sort-of-C, is one of the reasons for the popularity of 32-bit cores like ARM, and one of the reasons for manufacturers to support gcc (and sometimes clang/llvm) for their processors. So if you are learning to program embedded systems now, or starting on a new project on a new device, you would not want to be limited to C89. That is basically for legacy systems, maintenance of old projects, and /occasionally/ for highly portable code. Rather, I would advise people to target their code for as many different compilers and targets as is realistic - but no wider than that. And for a great deal of new embedded code, that means 32-bit (or more) targets and a compiler that supports C99 and perhaps C11, with support for a range of gcc extensions. Since the job of the embedded programmer is to write the best code they can for the target in question, make full use of any of these features if it means better quality code. C89 is the COBOL of C programming. > > On the point, I agree that C has quite a few aspects that range from mere > oddities all the way to design flaws, but being aware of those and dealing > with them is part of using the language. If you can't, use a different > language. > > I mostly use Python, R, and C, and I always enjoy switching between > languages (and the C compiler enjoys bitching about missing semicolons and > the '<-' operator). But C is always where I feel most at home. > > robert >
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-28 14:22 -0700 |
| Message-ID | <23f97d5a-277e-4780-9fa2-8ed7f6310f6a@googlegroups.com> |
| In reply to | #94220 |
More differences:
- non-class types
typedef const char* String = NULL;
and we could have
typedef enum { NONE, A, B } E = NONE;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-28 15:16 -0700 |
| Message-ID | <lnzimrr7ox.fsf@kst-u.example.com> |
| In reply to | #94223 |
Thiago Adams <thiago.adams@gmail.com> writes:
> More differences:
>
> - non-class types
> typedef const char* String = NULL;
Referring to `char*` or `const char*` as "string" or "String" is IMHO a
bad idea. A `char*` value is not a string. It may or may not be a
pointer to a string.
> and we could have
>
> typedef enum { NONE, A, B } E = NONE;
In both cases, do you intend the initializer to apply to the typedef,
and not to the original type?
Currently a typedef does not create a new type; it merely
creates a new name for an existing type. (Admittedly "typedef" isn't
the best name for this feature; "typealias" might have been better.)
Introducing a semantic difference between a name defined by a typedef
and the name of the original type would be a substantial language
change.
Please provide some context when posting a followup. See most of the
articles here for examples.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-28 16:08 -0700 |
| Message-ID | <50f3f9fe-ced4-4cc2-92a6-16cdf35725e9@googlegroups.com> |
| In reply to | #94225 |
On Wednesday, September 28, 2016 at 7:15:58 PM UTC-3, Keith Thompson wrote:
> Thiago Adams writes:
> > More differences:
> >
> > - non-class types
> > typedef const char* String = NULL;
>
> Referring to `char*` or `const char*` as "string" or "String" is IMHO a
> bad idea. A `char*` value is not a string. It may or may not be a
> pointer to a string.
I use this typedef const char* String to represent ownership;
When I use String, it's because the pointer owns the string.
struct S
{
String name;
};
void S_Init(struct S* p) { String_Init(&p->name); }
void S_Destroy(struct S* p) { String_Destroy(&p->name); }
Also, this type take care of the resource.
String_Set(&p->name, "new value");
This function will release the previous memory.
I don't use void UseName(String*);
I use in this case void UseName(const char*);
and call
UseName(p->Name);
This is because UseName don't need to know anything about ownership.
I don't know how others do to known/mark/see ownership.
> > and we could have
> >
> > typedef enum { NONE, A, B } E = NONE;
>
> In both cases, do you intend the initializer to apply to the typedef,
> and not to the original type?
> Currently a typedef does not create a new type; it merely
> creates a new name for an existing type. (Admittedly "typedef" isn't
> the best name for this feature; "typealias" might have been better.)
For enums we could have:
enum E { NONE ,A, B} = NONE;
typedef enum {NONE, A, B} = NONE E;
For integers, I would postpone the solution, and maybe analyze typedefs together. :)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-28 16:57 -0700 |
| Message-ID | <lnvaxfr31q.fsf@kst-u.example.com> |
| In reply to | #94228 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Wednesday, September 28, 2016 at 7:15:58 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams writes:
>> > More differences:
>> >
>> > - non-class types
>> > typedef const char* String = NULL;
>>
>> Referring to `char*` or `const char*` as "string" or "String" is IMHO a
>> bad idea. A `char*` value is not a string. It may or may not be a
>> pointer to a string.
>
> I use this typedef const char* String to represent ownership;
> When I use String, it's because the pointer owns the string.
Ok, if it works for you that's fine. But I've seen things like
typedef char *string;
elsewhere, and such typedefs are often used by people who don't know the
difference.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-28 14:19 -0700 |
| Message-ID | <ln7f9vsowr.fsf@kst-u.example.com> |
| In reply to | #94216 |
Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> The feature I am thinking about is "default initializers"
>
> Today we can do:
>
> struct Point { int x; int y; };
> struct Point pt1 = { 1, 2 };
>
> and this is useful when the initialization change by instance basis.
> But, for some types the initialization is the same or it have common
> initiation part for all instances. To avoid specify the common
> initialization everywhere the solution is create a macro.
>
> struct Z { int type; };
> #define Z_INIT { 4 }
>
> struct Z z1 = Z_INIT;
A minor point: this can be done without a macro:
struct Z { int type; };
const struct Z Z_INIT = { 4 };
struct Z z1 = Z_INIT;
[...]
(comp.std.c might be a more appropriate place for this, but IMHO
comp.lang.c is ok.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-28 14:50 -0700 |
| Message-ID | <5b93213c-4a2a-442d-96ca-c79bd09ed470@googlegroups.com> |
| In reply to | #94221 |
On Wednesday, September 28, 2016 at 6:19:03 PM UTC-3, Keith Thompson wrote:
> Thiago Adams writes:
> [...]
> > The feature I am thinking about is "default initializers"
> >
> > Today we can do:
> >
> > struct Point { int x; int y; };
> > struct Point pt1 = { 1, 2 };
> >
> > and this is useful when the initialization change by instance basis.
> > But, for some types the initialization is the same or it have common
> > initiation part for all instances. To avoid specify the common
> > initialization everywhere the solution is create a macro.
> >
> > struct Z { int type; };
> > #define Z_INIT { 4 }
> >
> > struct Z z1 = Z_INIT;
>
> A minor point: this can be done without a macro:
>
> struct Z { int type; };
> const struct Z Z_INIT = { 4 };
> struct Z z1 = Z_INIT;
This is very nice, but it also opens a new feature discussion. :)
I think I will mix everything here but..
When something is const in a type that means that it probably doesn't need to exist.
I don't know if the compiler will generate this value at memory
const struct Z Z_INIT = { 4 };
For this, I think we need a way to add information on a type.
Let's say C already have one. It's sizeof, but the value of sizeof is set by the compiler.
My first thought about this is:
struct Z
{
inline int Type = 1; //or "" or function pointer
inline const char* Name = "Z";
inline struct Z Z_INIT = { 4 };
int type = Type;
};
Here Type is something that exist only at compiler memory.
and then we could have a new kind of "sizeof" but to inquire about type values.
struct Z z;
type_value(Type, z) ; //returns 1
type_value(Type, struct Z) ; //returns 1
type_value(Name, struct Z) ; //returns "Z"
type_value(Type, int) ; //compiler error
I don't think this would complicated too much the compiler.
So, the {default} is also something that is associated with a type, and like sizeof is compiler generated.
struct Z
{
inline struct Z __magic_hidden__ = { /*default-initialization*/};
inline struct Z __magic_sizeof_hidden__ = 2; //compiler generates
}
(struct Z){default} is similar of
type_value(__magic_hidden__ , struct Z);
and sizeof (Z) is similar of
type_value(__magic_sizeof_hidden__ , struct Z);
Also functions could be associated with types.
struct Z
{
//this is NOT function inline, but variable inline
inline void (*Destructor )(struct Z*) = Z_Destructor; //doenst change sizeof
};
struct Z z;
type_value(Destructor, z)(&z);
or we could have some syntax sugar..
_Call Destructor(&z);
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-28 17:03 -0700 |
| Message-ID | <c65a0392-4488-4c83-80ce-cd0a0d902050@googlegroups.com> |
| In reply to | #94224 |
On Wednesday, September 28, 2016 at 6:50:51 PM UTC-3, Thiago Adams wrote:
>
> Also functions could be associated with types.
>
> struct Z
> {
> //this is NOT function inline, but variable inline
> inline void (*Destructor )(struct Z*) = Z_Destructor; //doenst change sizeof
> };
>
> struct Z z;
> type_value(Destructor, z)(&z);
>
> or we could have some syntax sugar..
>
> _Call Destructor(&z);
What could be useful is to call all members that have the same function in their types.(same signature also)
struct X
{
inline void (*Destroy)(struct X* ) = X_Destroy;
};
struct Y
{
struct X x;
inline void (*Destroy)(struct X* ) = Y_Destroy;
};
struct Y y;
_CallAll Destructor(&y); //calls X_Destroy , Y_Destroy
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-29 01:08 +0100 |
| Message-ID | <nshm21$9o2$1@dont-email.me> |
| In reply to | #94224 |
On 28/09/2016 22:50, Thiago Adams wrote:
> On Wednesday, September 28, 2016 at 6:19:03 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams writes:
>> [...]
>>> The feature I am thinking about is "default initializers"
>>>
>>> Today we can do:
>>>
>>> struct Point { int x; int y; };
>>> struct Point pt1 = { 1, 2 };
>>>
>>> and this is useful when the initialization change by instance basis.
>>> But, for some types the initialization is the same or it have common
>>> initiation part for all instances. To avoid specify the common
>>> initialization everywhere the solution is create a macro.
>>>
>>> struct Z { int type; };
>>> #define Z_INIT { 4 }
>>>
>>> struct Z z1 = Z_INIT;
>>
>> A minor point: this can be done without a macro:
>>
>> struct Z { int type; };
>> const struct Z Z_INIT = { 4 };
>> struct Z z1 = Z_INIT;
>
> This is very nice, but it also opens a new feature discussion. :)
> I think I will mix everything here but..
> When something is const in a type that means that it probably doesn't need to exist.
>
> I don't know if the compiler will generate this value at memory
> const struct Z Z_INIT = { 4 };
>
>
> For this, I think we need a way to add information on a type.
> Let's say C already have one. It's sizeof, but the value of sizeof is set by the compiler.
>
> My first thought about this is:
>
> struct Z
> {
> inline int Type = 1; //or "" or function pointer
> inline const char* Name = "Z";
> inline struct Z Z_INIT = { 4 };
> int type = Type;
> };
>
> Here Type is something that exist only at compiler memory.
> and then we could have a new kind of "sizeof" but to inquire about type values.
>
> struct Z z;
> type_value(Type, z) ; //returns 1
> type_value(Type, struct Z) ; //returns 1
> type_value(Name, struct Z) ; //returns "Z"
> type_value(Type, int) ; //compiler error
>
>
> I don't think this would complicated too much the compiler.
> So, the {default} is also something that is associated with a type, and like sizeof is compiler generated.
>
> struct Z
> {
> inline struct Z __magic_hidden__ = { /*default-initialization*/};
> inline struct Z __magic_sizeof_hidden__ = 2; //compiler generates
> }
>
> (struct Z){default} is similar of
>
> type_value(__magic_hidden__ , struct Z);
>
> and sizeof (Z) is similar of
>
> type_value(__magic_sizeof_hidden__ , struct Z);
>
> Also functions could be associated with types.
>
> struct Z
> {
> //this is NOT function inline, but variable inline
> inline void (*Destructor )(struct Z*) = Z_Destructor; //doenst change sizeof
> };
>
> struct Z z;
> type_value(Destructor, z)(&z);
>
> or we could have some syntax sugar..
>
> _Call Destructor(&z);
Is this stuff already in C++? If so, why not just use that?
(I can't comment on your proposals as I can't make head or tail of them.
Perhaps that's why I hang out here rather than in comp.lang.c++.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web