Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93363 > unrolled thread
| Started by | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| First post | 2016-09-10 14:23 -0700 |
| Last post | 2016-09-13 07:47 -0700 |
| Articles | 11 on this page of 171 — 17 participants |
Back to article view | Back to comp.lang.c
Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-10 14:23 -0700
Re: Portable 16 bit binary integer write Barry Schwarz <schwarzb@dqel.com> - 2016-09-10 17:11 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 07:00 -0700
Re: Portable 16 bit binary integer write Richard Damon <Richard@Damon-Family.org> - 2016-09-13 08:41 -0400
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 06:24 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-13 16:19 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 10:20 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 11:07 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 20:47 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-14 08:24 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:17 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 11:27 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 09:03 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 11:21 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 18:39 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 12:26 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 23:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:17 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 11:10 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:43 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 19:59 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 13:34 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 16:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 15:31 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 19:06 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 23:27 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 15:04 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 00:09 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 19:36 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 15:29 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:20 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 09:48 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 19:38 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 15:33 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:58 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 14:15 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-18 23:15 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 15:46 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-19 17:03 +1200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:40 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:54 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:51 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:03 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:44 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:02 +0200
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 21:12 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:58 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 02:37 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 13:20 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 06:22 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 12:46 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 16:20 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:32 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:26 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 09:10 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 09:33 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:54 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:14 +0200
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 14:32 -0700
Re: Portable 16 bit binary integer write Robert Wessel <robertwessel2@yahoo.com> - 2016-09-19 22:58 -0500
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:45 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 07:49 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 19:43 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 11:15 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 22:36 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 21:30 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 23:58 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-23 19:45 +1200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:17 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-28 09:59 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-29 07:59 +1300
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-28 19:26 +0000
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-28 12:37 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:46 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:53 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-21 21:03 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-21 22:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 08:09 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:31 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:56 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:03 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:39 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-22 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 08:34 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 17:44 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:16 +0000
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 18:26 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:33 +0000
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:23 +0200
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 13:43 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 14:58 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 18:14 -0700
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-22 20:28 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 00:12 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 10:57 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:18 +0200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 11:48 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 15:58 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:21 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:42 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 23:38 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:13 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-24 23:03 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:29 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:02 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:17 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:52 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 13:59 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 15:50 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-24 16:06 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:53 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:16 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:18 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:39 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 23:33 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 02:08 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 10:25 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 03:05 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 11:09 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 09:29 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 17:37 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 12:29 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-26 11:12 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-26 13:19 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 18:34 -0700
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-27 06:43 +0000
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 00:51 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-27 08:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-22 11:40 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:34 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 00:06 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 17:32 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 15:57 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:46 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 16:08 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 10:03 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-17 23:59 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 16:49 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 01:19 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:16 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 10:19 -0400
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-18 13:26 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 17:04 -0400
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 01:21 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:07 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 00:32 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:30 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-15 22:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 22:17 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-16 18:12 +1200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 00:46 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-16 10:23 +0100
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-16 10:59 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 04:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:58 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 10:16 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 09:11 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 20:14 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 20:37 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 07:47 -0700
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-09-16 18:12 +1200 |
| Message-ID | <e41gqcFq92qU1@mid.individual.net> |
| In reply to | #93599 |
On 09/16/16 05:17 PM, supercat@casperkitty.com wrote:
> On Friday, September 16, 2016 at 12:00:36 AM UTC-5, Malcolm McLean wrote:
>> The general rule is "write the thing in C or it's a thundering
>> nuisance to anyone else trying to use your code". The main portability
>> problem is type aliasing. It's common to see geometrical functions
>> which expose something like struct{double x, double y} Point, then
>> you've got a few functions like "length". For the sake of a few
>> trivial subroutines, something quite sophisticated, like a Voroni
>> finder, is broken and unusable, and needs rewriting before it can
>> be used.
>
> It's a shame that some people think programmers should have to jump through
> hoops to exchange data between a function that expects a pointer to a
>
> struct point {double x, double y; };
>
> and another function that expects a pointer to a
>
> struct point2d {double x, double y; };
>
> even when both structures contain members with the same names and types.
> It's good that compilers require casts when converting between pointers
> to layout-compatible types, since types may be layout compatible but have
> different semantics, but that doesn't mean there shouldn't be a usable way
> to convert pointers.
>
> In C89, it was at least possible to use memmove() to block aliasing
> assumptions, and a smart implementation might notice at runtime that the
> two pointers were equal and skip the actual copy operation (but retain
> the alias-blocking semantics). Since C99 changed the semantics of memmove
> so that it is no longer a barrier to aliasing analysis, however, I don't
> think there is an efficient way to force the compiler that some storage
> which had been accessed as one type is going to be accessed as another.
You should start a blog so you can make these points without re-writing
them every time.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-16 00:46 -0700 |
| Message-ID | <a93d20f0-4d32-443e-9fe2-b6d25f34e379@googlegroups.com> |
| In reply to | #93601 |
On Friday, September 16, 2016 at 7:12:38 AM UTC+1, Ian Collins wrote: > > You should start a blog so you can make these points without re-writing > them every time. > Or help me specify B64. It's something I want to start when I get around to it. All types will be 64 bits, except strings which will be zero-padded multiples of 64 bits (so strcmp() becomes in almost all cases a single machine instruction), maybe we won't have any types at all, I haven't decided. . But we certainly must avoid any pitfalls in the rules that would allow an aggressive B64 optimiser to emit counter-intuitive code.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-16 10:23 +0100 |
| Message-ID | <87poo4kxk4.fsf@bsb.me.uk> |
| In reply to | #93602 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, September 16, 2016 at 7:12:38 AM UTC+1, Ian Collins wrote: >> >> You should start a blog so you can make these points without re-writing >> them every time. >> > Or help me specify B64. What is the case for yet another language given that BCPL and the newer MCPL seem to be the sort of thing you are talking out? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-16 10:59 +0100 |
| Message-ID | <nrgfpp$i3l$1@dont-email.me> |
| In reply to | #93602 |
On 16/09/2016 08:46, Malcolm McLean wrote: > On Friday, September 16, 2016 at 7:12:38 AM UTC+1, Ian Collins wrote: >> >> You should start a blog so you can make these points without re-writing >> them every time. >> > Or help me specify B64. > > It's something I want to start when I get around to it. All types will > be 64 bits, except strings which will be zero-padded multiples of > 64 bits (so strcmp() becomes in almost all cases a single machine > instruction), Until you want to compare a slice or tail end of a larger string (and with a slice of another). The idea is intriguing but after decades of using byte-addressable machines, going back to word-addressed - and enforced by a language even though the hardware is perfectly byte-capable - is going to be hard. Especially when you need to communicate with software /on the same machine/ which uses struct members that have sizes and offets that are byte-aligned. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-16 04:13 -0700 |
| Message-ID | <f1537d56-fadc-451c-a2a6-03351a0487a7@googlegroups.com> |
| In reply to | #93609 |
On Friday, September 16, 2016 at 10:59:35 AM UTC+1, Bart wrote: > On 16/09/2016 08:46, Malcolm McLean wrote: > > On Friday, September 16, 2016 at 7:12:38 AM UTC+1, Ian Collins wrote: > >> > >> You should start a blog so you can make these points without re-writing > >> them every time. > >> > > Or help me specify B64. > > > > It's something I want to start when I get around to it. All types will > > be 64 bits, except strings which will be zero-padded multiples of > > 64 bits (so strcmp() becomes in almost all cases a single machine > > instruction), > > Until you want to compare a slice or tail end of a larger string (and > with a slice of another). > > The idea is intriguing but after decades of using byte-addressable > machines, going back to word-addressed - and enforced by a language even > though the hardware is perfectly byte-capable - is going to be hard. > You discourage that. Of course there will be a relatively slow function for taking a substring of another string and for extracting characters. Bitwise operations on two adjacent 64 bit values are not in any sense prohibited. Once B64 takes over the world, hardware will be built to optimise for it. Whilst I don't know much about chip design, I believe that simplifying the instruction set so you only have 64 bit reads and writes, you can also reduce the amount of circuitry on the chip, making it cheaper, smaller, and less power-hungry. > > Especially when you need to communicate with software /on the same > machine/ which uses struct members that have sizes and offets that are > byte-aligned. > That will be a bit buffer. You build bit buffers either to communicate with non- B64 functions or when the operation is logically bit-based rather than based on data consisting of integers, real numbers and strings. Since our integers have 64 bits, we can make bits index-addressable. Since it is the rare datum that consists of more than 64 bits, we can extract embedded integers, characters and reals very cleanly. The only fiddle is with strings, where you'll have to copy to a B64 aligned buffer if you want to use the native string routines.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-16 08:58 -0700 |
| Message-ID | <03e3481f-5637-4942-a3a4-0bfd109ef4a4@googlegroups.com> |
| In reply to | #93609 |
On Friday, September 16, 2016 at 4:59:35 AM UTC-5, Bart wrote:
> > It's something I want to start when I get around to it. All types will
> > be 64 bits, except strings which will be zero-padded multiples of
> > 64 bits (so strcmp() becomes in almost all cases a single machine
> > instruction),
>
> Until you want to compare a slice or tail end of a larger string (and
> with a slice of another).
A solution for that is to either pass around strings as base+offset+
length (if strings don't need to exceed 4GB, one could combine the
latter two values in a single register), or as pointer to descriptors
which contain that information. Zero-terminated strings have three
advantages over length-prefixed strings:
1. There's no hard-coded upper limit on length
2. Z-strings are more compact than prefixed strings whose length
field is longer than one byte.
3. One can cheaply get a pointer to a string starting at offset N
of a string *which is known to be at least N characters long*.
The only reason I see for using them in C is that most implementations
don't allow in-line construction of static character sequences in any
other format. I don't see any of them as compelling in B64.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-16 10:16 -0700 |
| Message-ID | <303f7970-041d-4b88-ac10-c61a4f8ab788@googlegroups.com> |
| In reply to | #93632 |
On Friday, September 16, 2016 at 4:58:33 PM UTC+1, supe...@casperkitty.com wrote: > On Friday, September 16, 2016 at 4:59:35 AM UTC-5, Bart wrote: > > > It's something I want to start when I get around to it. All types will > > > be 64 bits, except strings which will be zero-padded multiples of > > > 64 bits (so strcmp() becomes in almost all cases a single machine > > > instruction), > > > > Until you want to compare a slice or tail end of a larger string (and > > with a slice of another). > > A solution for that is to either pass around strings as base+offset+ > length (if strings don't need to exceed 4GB, one could combine the > latter two values in a single register), or as pointer to descriptors > which contain that information. Zero-terminated strings have three > advantages over length-prefixed strings: > > 1. There's no hard-coded upper limit on length > > 2. Z-strings are more compact than prefixed strings whose length > field is longer than one byte. > > 3. One can cheaply get a pointer to a string starting at offset N > of a string *which is known to be at least N characters long*. > > The only reason I see for using them in C is that most implementations > don't allow in-line construction of static character sequences in any > other format. I don't see any of them as compelling in B64. > B64 will be a near-subset of ANSI C, where all the types are 64 bits. So we only have one integer type (I used to be a T-shirt salesman, we couldn't handle stock of different sizes, so to make things easier for ourselves all the T-shirts were extra large. WE then convinced the public that wearing on oversized T-shirt was a fashionable thing to do). Reals aren't an issue - float is too small to be safe, and the only justification for it is micro-efficiency. Characters aren't a problem either, an individual variable that holds a character is just 64 bits. but strings are a bit more difficult. Storing them as arrays of 64-bit character types that hold 7-bit Ascii values is too extravagant, and not binary-compatible with what will be legacy code written in C. The obvious solution is to pad 64 bit values with extra trailing zeroes, and pack the string in. Then you have a slight inefficiency for character-based access, but the payoff is faster comparisons, and more programs that do heavy string handling spend most of their time in sorts. However a string has to start on a 64-bit boundary. So in-place string slicing is difficult. You can of course pass around base plus offset and length, but it's rather fiddly.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-16 09:11 -0700 |
| Message-ID | <kfny42rg6yc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93585 |
David Brown <david.brown@hesbynett.no> writes:
> On 15/09/16 21:07, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 14/09/16 05:47, Tim Rentsch wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>> [...]
>>> And when you are thinking about portability, what should be your aims?
>>> Do you concern yourself with systems that are conforming C but almost
>>> non-existent in reality (such as one's complement platforms)? Do you
>>> concern yourself with systems that are totally hypothetical but could
>>> exist (such as a system with CHAR_BIT == 27)? Do you concern yourself
>>> with systems that are /not/ conforming, but /do/ exist?
>>
>> (My comments are not meant to address any matters outside the
>> realm of conforming C. I hope we can confine the discussion to
>> that domain.)
>
> I realise you prefer to stick to conforming C in discussions - it can
> be very difficult to reason about something that breaks the rules
> unless we can limit exactly /which/ rules are broken, and in which
> ways (i.e., we can provide new rules). Certainly it is impossible to
> write code that will work on a particular near-C compiler unless we
> know exactly how it works.
>
> So I am not suggesting that code should be written in a way that will
> work with any near-C compiler. I am merely raising the question,
> should some of these compilers be considered when writing code that
> should be portable?
>
> As an example, portable embedded code is sometimes written with
> explicit initialisation for all global or file-scope variables, even
> if their initial value is 0:
>
> static int x = 0;
>
> rather than
>
> static int x;
>
> They do this because there are embedded compilers (notably TI's "Code
> composer" compilers - sometimes referred to as "Code composter") which
> do not zero-initialise such variables.
I still hope we can confine the discussion to the realm of
conforming C.
>>> So if I need a function that turns an int into an unsigned 16-bit
>>> integer, I would normally write:
>>>
>>> uint16_t toUint16(int x) {
>>> return x;
>>> }
>>>
>>> It would be more portable if I wrote:
>>>
>>> uint_least16_t toUint16(int x) {
>>> uint_least16_t y = x;
>>> return y & 0xffff;
>>> }
>>>
>>> But the first version will run on almost all real-life systems,
>>> including most processors we are likely to see in the future. And on
>>> the few devices that don't support such code, like the Analog Devices
>>> SHARC dsps, you'll get a clear compile-time error - there is no risk of
>>> silently producing incorrect code.
>>>
>>> And on many real-life systems, the first version will give more
>>> efficient run-time code - and it will never give /worse/ code.
>>
>> It isn't hard to supply this functionality in a way that is
>> portable to platforms that do not have a uint16_t type, but still
>> is just as efficient on those platforms where it can be. As the
>> amount of effort needed is comparable in the two approaches, ISTM
>> that a more portable version is a better choice. Furthermore
>> cases like this can be accumulated in a general library so the
>> effort involved is amortized over all the code bases where such
>> things are needed.
>
> It is possible that it would surprise you just how inefficient some
> compilers are. [...]
It is possible that it would surprise you just how extensive my
background and experience are. I have after all been programming
for almost 50 years, which may not show through - when writing in
comp.lang.c I try to observe the topicality guidelines.
Rather than wonder about what would surprise me, why don't you
take a run at supplying the aforementioned functionality in a
way that is both portable and efficient? If you did, that
would give us something to talk about.
> And in terms of "portability", one might consider "portable to
> different programmers" as well as "portable to different compilers and
> targets". There is a depressingly large proportion of C programmers
> who don't know much about their tools, and fail to enable even basic
> optimisations. Should we write code in a way that minimises the
> inefficiency this causes, or should we just say that if those users
> don't care about their runtime efficiency, we shouldn't care about
> their runtime efficiency either? I am not trying to answer that
> question, merely raising it.
Ignorant programmers should be educated. Incompetent programmers
should be fired. Any place that doesn't do that should put less
emphasis on programming problems and more on management problems.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-16 20:14 +0200 |
| Message-ID | <nrhcqk$ou4$1@dont-email.me> |
| In reply to | #93636 |
On 16/09/16 18:11, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
<snip>
>>
>> They do this because there are embedded compilers (notably TI's "Code
>> composer" compilers - sometimes referred to as "Code composter") which
>> do not zero-initialise such variables.
>
> I still hope we can confine the discussion to the realm of
> conforming C.
Perhaps the discussion can be limited to conforming C compilers - but
you should be aware that a lot of real-world programming is done with
almost-C compilers. You might not want to think about it, but you are
surrounded by devices programmed using such tools - and every time you
press the break pedal on your car, or visit the hospital, your life
depends on people writing correct and efficient code with these almost-C
tools. But I will try not to bring it into the thread again unless I
have a concrete and relevant example.
>
>>>> So if I need a function that turns an int into an unsigned 16-bit
>>>> integer, I would normally write:
>>>>
>>>> uint16_t toUint16(int x) {
>>>> return x;
>>>> }
>>>>
>>>> It would be more portable if I wrote:
>>>>
>>>> uint_least16_t toUint16(int x) {
>>>> uint_least16_t y = x;
>>>> return y & 0xffff;
>>>> }
>>>>
>>>> But the first version will run on almost all real-life systems,
>>>> including most processors we are likely to see in the future. And on
>>>> the few devices that don't support such code, like the Analog Devices
>>>> SHARC dsps, you'll get a clear compile-time error - there is no risk of
>>>> silently producing incorrect code.
>>>>
>>>> And on many real-life systems, the first version will give more
>>>> efficient run-time code - and it will never give /worse/ code.
>>>
>>> It isn't hard to supply this functionality in a way that is
>>> portable to platforms that do not have a uint16_t type, but still
>>> is just as efficient on those platforms where it can be. As the
>>> amount of effort needed is comparable in the two approaches, ISTM
>>> that a more portable version is a better choice. Furthermore
>>> cases like this can be accumulated in a general library so the
>>> effort involved is amortized over all the code bases where such
>>> things are needed.
>>
>> It is possible that it would surprise you just how inefficient some
>> compilers are. [...]
>
> It is possible that it would surprise you just how extensive my
> background and experience are. I have after all been programming
> for almost 50 years, which may not show through - when writing in
> comp.lang.c I try to observe the topicality guidelines.
>
> Rather than wonder about what would surprise me, why don't you
> take a run at supplying the aforementioned functionality in a
> way that is both portable and efficient? If you did, that
> would give us something to talk about.
We are talking about a function "toUint16" that takes a signed integer
of type "int_least16_t" (or bigger signed integer type), known to be
between -32768 and 32767, and returns an unsigned integer of type
"uint_least16_t" such that 0..32767 maps to 0..32767, and -32768..-1
maps to 32768..65535 ?
I can't think of any solution that is independent of the size of the
types, and does not involve additional operations such as "& 0xffff" or
conditionals (which would lead to less efficient code on some
implementations).
If I haven't misunderstood the problem you are suggesting, then I am
very curious to know your suggested solution.
>
>> And in terms of "portability", one might consider "portable to
>> different programmers" as well as "portable to different compilers and
>> targets". There is a depressingly large proportion of C programmers
>> who don't know much about their tools, and fail to enable even basic
>> optimisations. Should we write code in a way that minimises the
>> inefficiency this causes, or should we just say that if those users
>> don't care about their runtime efficiency, we shouldn't care about
>> their runtime efficiency either? I am not trying to answer that
>> question, merely raising it.
>
> Ignorant programmers should be educated. Incompetent programmers
> should be fired. Any place that doesn't do that should put less
> emphasis on programming problems and more on management problems.
>
Yes, that's all true - in an ideal world. Sometimes people have to live
with what they have got, even if it is sub-par programmers (and sub-par
management).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-16 20:37 -0700 |
| Message-ID | <12bc7afe-678b-440b-869a-2fdb1a9f4c5a@googlegroups.com> |
| In reply to | #93646 |
On Friday, September 16, 2016 at 7:14:59 PM UTC+1, David Brown wrote: > On 16/09/16 18:11, Tim Rentsch wrote: > us something to talk about. > > We are talking about a function "toUint16" that takes a signed integer > of type "int_least16_t" (or bigger signed integer type), known to be > between -32768 and 32767, and returns an unsigned integer of type > "uint_least16_t" such that 0..32767 maps to 0..32767, and -32768..-1 > maps to 32768..65535 ? > > I can't think of any solution that is independent of the size of the > types, and does not involve additional operations such as "& 0xffff" or > conditionals (which would lead to less efficient code on some > implementations). > Yes, but it's a data reformatting problem. The actual question was how to implement fput16le. In ANSI C, that function is making two subroutine calls to fputc(). So a logical and is not going to make the slightest difference. Generally, data will come in as little-endian, big-endian, 16 bits, 8 bits, ten bits with a twiddle bit just for fun. You can't control that because by definition data is "given", it comes ultimately from some source outside of the program. And it goes out as big endian, little endian, whatever. Often you can't control that either. If the output is a Microsoft bitmap file, the image dimensions must be little-endian and the pixels must be BGR. Stupidly unconventional, but that's what the format says But once we've written our import and export routines, the data is ours. We control the representation. As long as we are clear what the bits are and what they mean, and as long as we have enough precision, there's no reason to keep images in the little-endian, BGR format. We can pass them about as rgba buffers. Alpha is redundant - it will always be 255 - but it's usually just easier to have all your images in the system in the same internal format. So these are once only functions. Unless you're doing digital signals processing or something where sheer throughput is a challenge, the functions are called twice on each datum, once on import, once on export, and a logical and operation is not going to matter.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-13 07:47 -0700 |
| Message-ID | <44577f00-4d57-4771-8a62-8c58c002c4a9@googlegroups.com> |
| In reply to | #93413 |
On Tuesday, September 13, 2016 at 8:24:31 AM UTC-5, Malcolm McLean wrote: > Yes, it seems the problem doesn't really exist. There's already a mechanism > built in to solve it. The read is a bit tricky, but the write is easy, even on > one's complement machines. (The snag with these routines is that you can't > get hold of a non-two's complement, non CHAR_BIT == 8 implementation > to test them). If the authors of the C Standard want to actually promote portability, they should specify a family of conditionally-supported integer types whose layout and behavioral specifics are given in user code. Platforms which have types that match what user code specifies could use native types directly; those which don't could either emulate such types or refuse compilation. That would allow someone with code that's written for a 36-bit ones'-complement machine to port it to modern hardware by adding a few directives and changing some declarations. Such code wouldn't run nearly as well on a modern machine as it could run if ported to use more "modern" types, but it would still be likely to run better than it did on the original hardware.
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web