Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108327 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2017-04-22 09:06 +0100 |
| Last post | 2017-04-26 08:53 +0200 |
| Articles | 20 on this page of 245 — 25 participants |
Back to article view | Back to comp.lang.c
gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 09:06 +0100
Re: gcc failure (optimised/non-optimised) Andrew Cooper <amc96@cam.ac.uk> - 2017-04-22 09:49 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:52 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:37 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:07 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:33 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:32 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-28 14:53 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 07:00 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:19 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 11:30 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 16:12 +0200
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:16 +0100
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-23 05:41 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-23 14:14 -0700
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-24 04:04 -0500
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:22 +0100
Re: gcc failure (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 12:05 -0400
Re: gcc rules OK (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 17:06 -0400
Re: gcc rules OK (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 15:06 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:31 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 09:29 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 10:47 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 11:36 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:50 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 15:35 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:36 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:37 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:07 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-25 11:57 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:34 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 11:25 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:57 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:38 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:38 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-22 08:35 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 17:16 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 18:55 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 21:04 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-22 21:51 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:56 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 16:49 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-30 16:02 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:51 -0500
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 21:42 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 17:35 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:57 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 18:44 +0100
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 11:34 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 12:03 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:30 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-30 21:18 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:33 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 16:27 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 10:16 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:34 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:43 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 12:54 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 17:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 18:05 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 20:37 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 10:22 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:01 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 12:18 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:55 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:14 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 09:34 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 10:09 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:25 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 11:28 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 11:53 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 13:07 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 14:19 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 16:44 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:09 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:17 +1200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:26 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:38 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:49 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 19:58 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:32 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:53 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:51 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:58 +1200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:45 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-05 06:41 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-05 10:40 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 13:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-06 11:26 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 22:52 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:01 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:48 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:17 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 06:36 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 16:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 09:16 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 21:20 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 13:07 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 22:46 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 14:38 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:16 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:09 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 15:14 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:43 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:56 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:57 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 17:27 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 17:41 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:16 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-09 12:11 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 09:58 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:40 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 12:05 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:55 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-09 13:56 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 14:19 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-10 14:22 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:36 -0500
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 01:12 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 21:15 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:41 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-11 15:32 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 01:54 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 07:45 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 23:52 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:57 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 21:56 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:45 +0200
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-11 14:43 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-12 10:55 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-12 07:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 09:02 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-14 13:14 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 16:04 -0500
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:33 -0500
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:51 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:14 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:07 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:30 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:44 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:42 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-05 14:10 +0000
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 17:12 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 15:08 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:24 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:29 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 18:07 +0000
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 20:15 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 15:47 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 01:22 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 18:57 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 09:30 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:25 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 10:33 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 10:10 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 12:49 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-05 18:31 -0700
Re: gcc failure (optimised/non-optimised) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-05 22:18 -0600
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-07 23:58 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:33 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:04 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:51 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-08 19:01 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:39 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-10 06:42 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:53 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-05 00:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:54 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:27 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:10 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:56 -0500
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:00 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:15 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:06 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:43 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 21:52 +0200
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-01 23:16 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-02 09:19 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:28 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 13:12 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:23 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 10:08 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:32 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 13:59 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:47 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-30 21:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 11:24 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:45 -0700
Re: gcc failure (optimised/non-optimised) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-04-23 23:11 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:46 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:23 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 15:38 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 17:31 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-24 17:15 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:36 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:06 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 14:03 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:25 -0700
Re: gcc failure (optimised/non-optimised) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-27 05:51 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:08 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-01 10:48 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 11:39 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-05-01 13:54 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:55 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:18 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:03 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:13 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 19:47 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 18:51 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 14:06 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 21:05 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 16:06 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 14:19 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 08:41 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:07 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:44 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 09:03 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 09:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:41 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:51 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 08:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:13 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:11 +0000
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:04 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:57 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:38 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:43 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 18:22 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 17:48 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:24 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-27 03:03 -0700
Re: gcc failure (optimised/non-optimised) James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:12 -0400
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:48 +0000
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 10:14 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:32 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:47 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-26 08:53 +0200
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-24 12:06 -0700 |
| Message-ID | <lny3upocbe.fsf@kst-u.example.com> |
| In reply to | #108414 |
supercat@casperkitty.com writes:
> On Monday, April 24, 2017 at 11:15:21 AM UTC-5, Ben Bacarisse wrote:
>> I think it was the committee that made it undefined (who, I suppose,
>> count as language designers too) but if we take K&R1 as the view of the
>> language designers, they chose to make it a slight variation on
>> "implementation defined":
>>
>> "The action taken on overflow or underflow depends on the machine at
>> hand." (K&R 1st ed. page 38)
And on page 185, in the "C Reference Manual" appendix:
The handling of overflow and divide check in expression evaluation
is machine-dependent. All existing implementations of C ignore
integer overflows; treatment of division by 0, and all
floating-point exceptions, varies between machines, and is usually
adjustable by a library function.
Which implies, I think, that INT_MAX + 1 should yield INT_MIN on a
machine with 2's-complement arithmetic (assuming those names have their
modern meanings). K&R1 says that the action depends on the machine, not
on the compiler. The statement is not very specific, so it would be
difficult to say that a compiler that generated code that behaves
differently was non-conforming, but that seems to have been the intent.
On the other hand, I might argue that the statement that "All existing
implementations of C ignore integer overflows" implies that some future
implementation might behave differently, perhaps treating signed integer
overflow as a fatal run-time error.
> Note that Undefined Behavior explicitly lists as one of the possible
> outcomes "behaving during translation or program execution in a documented
> manner characteristic of the environment". The Standard does not specify
> in what cases quality implementations *should* behave in a such a fashion,
> but it would seem curious that the authors would have mentioned it if they
> did not expect that many implementations would behave in such fashion. The
> grammatical construction does not indicate whether the sentence should be
> interpreted as:
>
> - behaving in a fashion which an environment documents as a characteristic.
>
> - behaving in a fashion which is documented by the implementation and
> happens to be characteristic of the environment (which may or may not
> document it).
>
> Given the ambiguity, I would suggest that in cases where an environment
> documents a characteristic behavior, any quality implementation whose
> behavior would differ should document such difference.
I would suggest that *the language changed*. The statement in K&R1
was superseded by ANSI C's statement that signed integer overflow
has undefined behavior. K&R1 did not have the modern concept of
"undefined behavior". This may have broken some existing code that
depended on 2's-complement wraparound. Them's the breaks.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-24 14:03 -0700 |
| Message-ID | <26107f76-6393-4cc6-88c7-0f3ec7631744@googlegroups.com> |
| In reply to | #108424 |
On Monday, April 24, 2017 at 2:06:20 PM UTC-5, Keith Thompson wrote: > On the other hand, I might argue that the statement that "All existing > implementations of C ignore integer overflows" implies that some future > implementation might behave differently, perhaps treating signed integer > overflow as a fatal run-time error. Indeed. I would expect that some compilers probably had such options even in 1989, since there are purposes for which they would be useful. There is a huge difference, though, between saying that implementations need not behave in a particular fashion in cases where the implementer judges that there are compelling reasons to do otherwise, and saying that code which relies upon platform-specific behavior should be expected to work on implementations where there is no particular reason why it shouldn't. > I would suggest that *the language changed*. The statement in K&R1 > was superseded by ANSI C's statement that signed integer overflow > has undefined behavior. K&R1 did not have the modern concept of > "undefined behavior". This may have broken some existing code that > depended on 2's-complement wraparound. Them's the breaks. The stated purpose of C89 was to be compatible with existing programs. In cases where some platforms defined a consistent behavior, and some programs relied upon it, I see no reason to believe that the authors of the Standard meant to imply that quality general-purpose implementations for platforms that define the behaviors should not continue to treat them as defined, nor even that such code should be regarded as deprecated in cases where they did not define a better alternative (the latter having happened with things like variadic-argument processing). The notion that the authors of the Standard meant to throw compatibility with such techniques out the window is a much more recent invention, and contradicts the express stated purpose of the Standard.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-25 11:09 +0200 |
| Message-ID | <odn3ij$g0r$2@dont-email.me> |
| In reply to | #108411 |
On 24/04/17 18:15, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 24/04/17 16:38, bartc wrote: >>> On 24/04/2017 12:23, David Brown wrote: >>>> On 24/04/17 11:46, bartc wrote: >>> >>>> Different languages have different ways of defining (or leaving >>>> undefined) the behaviour of impossible or meaningless actions. If we >>>> assume 16-bit int (because the numbers are easier), and have x = 32767, >>>> then what should be the result of adding 1 to x? Standard mathematics >>>> says it should be 32768, and anything else is wrong. Typical processors >>>> say it should be -32768, because that is the easiest in the hardware >>>> design. Some algorithms would much prefer 32767, because saturation is >>>> "less wrong" than anything else. Some algorithms would prefer a NaN >>>> type indicator, or jumping to some error routine. >>>> >>>> C says "Adding 1 to x here is meaningless. There is no behaviour which >>>> can be called 'correct'. So we don't give it a meaning. The compiler >>>> can assume it never happens, if that lets it generate more efficient >>>> code for correct cases". >>> >>> You can apply the same argument to unsigned. > > Not in C. Unsigned arithmetic is defined. I think you meant you > *could* make the same argument about unsigned arithmetic by making it, > too, undefined on overflow. As things stand in C, you can't make the > same argument because the premise fails: there is behaviour that can be > called correct. > > <snip> >> It would be entirely reasonable for a language designer to say that >> signed integer overflow used two's complement wraparound. But the point >> is, that the /C/ designers did not do so - they specifically and >> explicitly made it undefined behaviour. It would be entirely reasonable >> for a language designer to make unsigned overflow undefined behaviour - >> again, the /C/ designers did not do so. They could also have made it >> implementation defined, but chose not to. > > I think it was the committee that made it undefined (who, I suppose, > count as language designers too) but if we take K&R1 as the view of the > language designers, they chose to make it a slight variation on > "implementation defined": > > "The action taken on overflow or underflow depends on the machine at > hand." (K&R 1st ed. page 38) > > <snip> > I don't know the early history of C as well as you (and a number of other group regulars) do. I used the term "language designers" in a rather general sense - including both the original K&R authors, and the committee(s) through the years.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-24 10:25 -0700 |
| Message-ID | <d2c2a277-210b-4425-a341-5c9e4d131469@googlegroups.com> |
| In reply to | #108406 |
On Monday, April 24, 2017 at 10:31:18 AM UTC-5, David Brown wrote: > You certainly could. The C language designers felt it was useful to > define unsigned arithmetic as modulo arithmetic. > > It would be entirely reasonable for a language designer to say that > signed integer overflow used two's complement wraparound. But the point > is, that the /C/ designers did not do so - they specifically and > explicitly made it undefined behaviour. It would be entirely reasonable > for a language designer to make unsigned overflow undefined behaviour - > again, the /C/ designers did not do so. They could also have made it > implementation defined, but chose not to. (Though an implementation is > always free to define the behaviour if it wants to.) Would it have made sense for implementations targeting hardware with integer semantics other than silent-wraparound two's-complement to generate whatever extra code was necessary to emulate such behavior? In most cases, it probably wouldn't, and it would have been bad for the Standard to mandate such behavior in cases where it wouldn't make sense. Would it be useful for some implementations targeting hardware with silent- wraparound integer semantics to offer modes which emulate other semantics (e.g. deterministically force Abnornal Program Termination in case of overflow)? I would say it would, and it is likewise useful that the Standard allows such implementations. Does either of the above imply that the authors of the Standard would not have expected and intended that quality general-purpose implementations targeting platforms with silent-wraparound hardware should allow programmers to reap the the benefits of such hardware except when asked to do otherwise?
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-04-27 05:51 +0000 |
| Message-ID | <slrnog31m6.1jqn.grahn+nntp@frailea.sa.invalid> |
| In reply to | #108405 |
On Mon, 2017-04-24, bartc wrote: ... > You can apply the same argument to unsigned. With the same 16 bits, > what's the result of adding 1 to 65535? Mathematics says it should be > 65536. Depends on what kind of mathematics. This kind says 0: https://en.wikipedia.org/wiki/Group_%28mathematics%29#Modular_arithmetic /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-01 09:08 +0000 |
| Message-ID | <5906f901.6797234@news.xs4all.nl> |
| In reply to | #108578 |
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > On Mon, 2017-04-24, bartc wrote: > ... > > You can apply the same argument to unsigned. With the same 16 bits, > > what's the result of adding 1 to 65535? Mathematics says it should be > > 65536. > > Depends on what kind of mathematics. This kind says 0: > > https://en.wikipedia.org/wiki/Group_%28mathematics%29#Modular_arithmetic And, crucially, that's the kind of arithmetic unsigned integers work in, in C. (Note also that the reason for the difference in treatment of signed and unsigned integers is obvious: there is no equivalent for unsigned representations of the distinction between 2'C, 1'C and S/M. The only different kind of unsigned representation you _can_ reasonably have is saturation; and that is unnatural and massively expensive to every kind of machine representation, including even mechanical odometers.) Richard
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-01 10:48 +0100 |
| Message-ID | <lvDNA.70342$NT.26954@fx33.am4> |
| In reply to | #108849 |
On 01/05/2017 10:08, Richard Bos wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > >> On Mon, 2017-04-24, bartc wrote: >> ... >>> You can apply the same argument to unsigned. With the same 16 bits, >>> what's the result of adding 1 to 65535? Mathematics says it should be >>> 65536. >> >> Depends on what kind of mathematics. This kind says 0: >> >> https://en.wikipedia.org/wiki/Group_%28mathematics%29#Modular_arithmetic > > And, crucially, that's the kind of arithmetic unsigned integers work in, > in C. > > (Note also that the reason for the difference in treatment of signed and > unsigned integers is obvious: there is no equivalent for unsigned > representations of the distinction between 2'C, 1'C and S/M. OK. Where can I buy a machine that uses ones' complement or signed magnitude integers? Or uses padding bits? Because I'd really like to try out my C code and see that all the fuss about dealing with signed integers was worthwhile. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-01 11:39 +0100 |
| Message-ID | <87ziew3lox.fsf@bsb.me.uk> |
| In reply to | #108852 |
bartc <bc@freeuk.com> writes: > On 01/05/2017 10:08, Richard Bos wrote: >> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >> >>> On Mon, 2017-04-24, bartc wrote: >>> ... >>>> You can apply the same argument to unsigned. With the same 16 bits, >>>> what's the result of adding 1 to 65535? Mathematics says it should be >>>> 65536. >>> >>> Depends on what kind of mathematics. This kind says 0: >>> >>> https://en.wikipedia.org/wiki/Group_%28mathematics%29#Modular_arithmetic >> >> And, crucially, that's the kind of arithmetic unsigned integers work in, >> in C. >> >> (Note also that the reason for the difference in treatment of signed and >> unsigned integers is obvious: there is no equivalent for unsigned >> representations of the distinction between 2'C, 1'C and S/M. > > OK. Where can I buy a machine that uses ones' complement or signed > magnitude integers? Or uses padding bits? Padding bits are easy: just declare a _Bool object. I don't think anyone makes sign and magnitude or ones' complement machines anymore. You'd have to buy a used one. > Because I'd really like to try out my C code and see that all the fuss > about dealing with signed integers was worthwhile. What fuss? I've never been bothered by those representations. What is it about them that bother you? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-05-01 13:54 +0200 |
| Message-ID | <oe77gc$qsp$1@dont-email.me> |
| In reply to | #108852 |
On 01/05/2017 11:48, bartc wrote: > OK. Where can I buy a machine that uses ones' complement or signed > magnitude integers? Or uses padding bits? You'll probably need a time machine. C was created in the early 70s. And the first version of the standard was developed 30 years old. https://en.wikipedia.org/wiki/Ones'_complement https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series#UNISYS_2200_series > Many early computers, including the CDC 6600, the LINC, the PDP-1, > and the UNIVAC 1107, used ones' complement notation. Successors of > the CDC 6600 continued to use ones' complement until the late 1980s, > and the descendants of the UNIVAC 1107 (the UNIVAC 1100/2200 series) > still do, but the majority of modern computers use two's complement.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 08:55 -0700 |
| Message-ID | <1af72506-fc09-4cd3-918a-aa8fcd9dc465@googlegroups.com> |
| In reply to | #108852 |
On Monday, May 1, 2017 at 4:48:08 AM UTC-5, Bart wrote: > OK. Where can I buy a machine that uses ones' complement or signed > magnitude integers? Or uses padding bits? Some digital signal processors have a 40-bit accumulator (many functions will exceed the range of a 32-bit accumulator, but not by so much as to require a full 64 bits). If a system has a 16-bit bus and instructions to store the bottom, middle, or upper portion of the accumulator, it would make a lot of sense to have an integer type which is stored as 40 value bits and 8 padding bits.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-01 12:18 -0500 |
| Message-ID | <a8regcd5eh265p87iapghvdsdnlvnsl6qd@4ax.com> |
| In reply to | #108852 |
On Mon, 1 May 2017 10:48:05 +0100, bartc <bc@freeuk.com> wrote: >On 01/05/2017 10:08, Richard Bos wrote: >> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >> >>> On Mon, 2017-04-24, bartc wrote: >>> ... >>>> You can apply the same argument to unsigned. With the same 16 bits, >>>> what's the result of adding 1 to 65535? Mathematics says it should be >>>> 65536. >>> >>> Depends on what kind of mathematics. This kind says 0: >>> >>> https://en.wikipedia.org/wiki/Group_%28mathematics%29#Modular_arithmetic >> >> And, crucially, that's the kind of arithmetic unsigned integers work in, >> in C. >> >> (Note also that the reason for the difference in treatment of signed and >> unsigned integers is obvious: there is no equivalent for unsigned >> representations of the distinction between 2'C, 1'C and S/M. > >OK. Where can I buy a machine that uses ones' complement or signed >magnitude integers? Or uses padding bits? Ones' complement and 9 bit bytes: http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems >Because I'd really like to try out my C code and see that all the fuss >about dealing with signed integers was worthwhile.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 11:03 -0700 |
| Message-ID | <7f8328cd-5380-458d-9450-b05702e68a01@googlegroups.com> |
| In reply to | #108900 |
On Monday, May 1, 2017 at 12:18:11 PM UTC-5, robert...@yahoo.com wrote: > Ones' complement and 9 bit bytes: > > http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems Do any of those support C99? C99 requires that implementations support an unsigned type that is at least 64 bits long, but the longest unsigned type I've seen on a ones'-complement system is 36 bits. The only practical ways I can see for a system to efficiently support an unsigned type 64 bits or longer would be to either: 1. Use a word size which is 64 bits or longer, or 2. Support efficient modular arithmetic with a power-of-two modulus. So far as I can tell, the only reason for an implementation to use ones'- complement arithmetic would be an inability to efficiently perform modular arithmetic with a power-of-two modulus. If a value is too large to be held in one word, two's-complement arithmetic will allow addition or subtraction to be performed by doing everything that will need to be done to the lower portion before examining the upper portion. Neither sign-magnitude nor ones'-complement arithmetic would allow one to know any bits of the result until one knows all of them. BTW, I'd be curious to know whether signed "long long" stores numbers in binary format. I'd expect that the most efficient way of processing numbers of that size on a 36-bit ones'-complement system would use a non-binary format where the low-order word of x+y would be unaffected by the high-order words of x and y.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-01 13:13 -0500 |
| Message-ID | <c8uegc9hhfaj778b9jpdvd5fs02ij88v5u@4ax.com> |
| In reply to | #108908 |
On Mon, 1 May 2017 11:03:30 -0700 (PDT), supercat@casperkitty.com wrote: >On Monday, May 1, 2017 at 12:18:11 PM UTC-5, robert...@yahoo.com wrote: >> Ones' complement and 9 bit bytes: >> >> http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems > >Do any of those support C99? Unless it's changed recently, there's only a C89 compiler, and it doesn't support any integer types longer than 36 bits.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-01 19:47 +0100 |
| Message-ID | <878tmg2z3f.fsf@bsb.me.uk> |
| In reply to | #108900 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Mon, 1 May 2017 10:48:05 +0100, bartc <bc@freeuk.com> wrote: <snip> >>OK. Where can I buy a machine that uses ones' complement or signed >>magnitude integers? Or uses padding bits? > > > Ones' complement and 9 bit bytes: > > http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems Aren't these Intel Xeon systems nowadays? Do Unisys still sell the old hardware? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-01 18:51 +0000 |
| Message-ID | <ysLNA.75676$9T.49561@fx39.iad> |
| In reply to | #108926 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Mon, 1 May 2017 10:48:05 +0100, bartc <bc@freeuk.com> wrote: ><snip> >>>OK. Where can I buy a machine that uses ones' complement or signed >>>magnitude integers? Or uses padding bits? >> >> >> Ones' complement and 9 bit bytes: >> >> http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems > >Aren't these Intel Xeon systems nowadays? Do Unisys still sell the old >hardware? The last custom CMOS design was introduced a few years ago. Both Libra and Dorado are now emulated on intel processors for all future generations. Old hardware is available yet, and in use.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-01 14:06 -0500 |
| Message-ID | <ei1fgctuk4k7p1lnrb9c4eem4pq2bg0v0f@4ax.com> |
| In reply to | #108926 |
On Mon, 01 May 2017 19:47:48 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Mon, 1 May 2017 10:48:05 +0100, bartc <bc@freeuk.com> wrote:
><snip>
>>>OK. Where can I buy a machine that uses ones' complement or signed
>>>magnitude integers? Or uses padding bits?
>>
>>
>> Ones' complement and 9 bit bytes:
>>
>> http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems
>
>Aren't these Intel Xeon systems nowadays? Do Unisys still sell the old
>hardware?
Yes, all the current systems are emulated on x86 hardware, although
"real" implementations are still out there. They ("real" systems) may
still even be available for purchase.
But that's a hardware implementation detail. OS/2200 still runs on
what it thinks is a 2200 ISA machine.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-01 21:05 +0100 |
| Message-ID | <871ss82vht.fsf@bsb.me.uk> |
| In reply to | #108932 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Mon, 01 May 2017 19:47:48 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Mon, 1 May 2017 10:48:05 +0100, bartc <bc@freeuk.com> wrote:
>><snip>
>>>>OK. Where can I buy a machine that uses ones' complement or signed
>>>>magnitude integers? Or uses padding bits?
>>>
>>>
>>> Ones' complement and 9 bit bytes:
>>>
>>> http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems
>>
>>Aren't these Intel Xeon systems nowadays? Do Unisys still sell the old
>>hardware?
>
>
> Yes, all the current systems are emulated on x86 hardware, although
> "real" implementations are still out there. They ("real" systems) may
> still even be available for purchase.
>
> But that's a hardware implementation detail. OS/2200 still runs on
> what it thinks is a 2200 ISA machine.
Ah, that's a twist. So something (software emulation?) ensures that
#include <stdio.h>
int main(void) { printf("%d\n", -1 & 3); }
prints 2 on these systems[1]? Obviously assuming that the program is
compiled with UCS C for OS 2200 and not, say gcc for Linux.
[1] -1 & 3 being the canonical C expression that differentiates
between C's three permissible signed integer representations.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-01 16:06 -0500 |
| Message-ID | <pi6fgc95bgjg927m8a3aibnqnhaaor1vu8@4ax.com> |
| In reply to | #108950 |
On Mon, 01 May 2017 21:05:34 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Mon, 01 May 2017 19:47:48 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>> On Mon, 1 May 2017 10:48:05 +0100, bartc <bc@freeuk.com> wrote:
>>><snip>
>>>>>OK. Where can I buy a machine that uses ones' complement or signed
>>>>>magnitude integers? Or uses padding bits?
>>>>
>>>>
>>>> Ones' complement and 9 bit bytes:
>>>>
>>>> http://www.unisys.com/offerings/technology-products-and-services/clearpath-forward-systems
>>>
>>>Aren't these Intel Xeon systems nowadays? Do Unisys still sell the old
>>>hardware?
>>
>>
>> Yes, all the current systems are emulated on x86 hardware, although
>> "real" implementations are still out there. They ("real" systems) may
>> still even be available for purchase.
>>
>> But that's a hardware implementation detail. OS/2200 still runs on
>> what it thinks is a 2200 ISA machine.
>
>Ah, that's a twist. So something (software emulation?) ensures that
>
> #include <stdio.h>
> int main(void) { printf("%d\n", -1 & 3); }
>
>prints 2 on these systems[1]? Obviously assuming that the program is
>compiled with UCS C for OS 2200 and not, say gcc for Linux.
>
>[1] -1 & 3 being the canonical C expression that differentiates
> between C's three permissible signed integer representations.
The systems support multiple partitions, some of which can run Linux
or Windows (in their normal x86-64 forms), as well as partitions that
emulate the 2200 ISA and run a more-or-less* normal OS 2200, and
unchanged 2200 binary applications. Things are set up so that the
various OS's can run as a fairly tight cluster.
I've been told that binary translation/JIT is used. FWIW, that fits
with the claimed performance (~500 single processor MIPS running on a
3.3GHz Xeon)**.
But yes (-1 & 3) really ought to be 2, at least for C applications
compiled in ones' complement mode***.
*I'm out of my depth on Unisys systems here, but I know some of the OS
level stuff is different, although much of what I've seen is
conceptually more like paravirtualization of I/O devices. There are
also version requirements for OS 2200 to run on the x86 systems, so
there was doubtless some adaptation of the OS. But they claim full
application binary compatibility.
**500MIPS should be fairly easy even for a not-very aggressive JIT,
OTOH, most public experiences with that sort of thing don't have the
impedance mismatch in the word, byte and binary format. QEMU for
RISC-V on similar hardware runs about 2000MIPS, although with an ISA
that maps much better on to the underlying hardware.
***The C compiler has a two's complement mode that uses 32-bit ints
and 8-bit chars. Obviously that will have better compatibility with
much software, but poorer integration with the traditional OS 2200
stack. The codepaths for running 32-bit-int/8-bit-byte/two's-comp
emulation on a 36-bit-word/9-bit-byte/ones'-comp system being emulated
on a 64-bit-word/8-bit-byte/two's-comp system are a bit cringeworthy
to think about.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 14:19 -0700 |
| Message-ID | <cef8929f-8b04-426e-b2d7-21701c54d29d@googlegroups.com> |
| In reply to | #108964 |
On Monday, May 1, 2017 at 4:06:43 PM UTC-5, robert...@yahoo.com wrote: > ***The C compiler has a two's complement mode that uses 32-bit ints > and 8-bit chars. Obviously that will have better compatibility with > much software, but poorer integration with the traditional OS 2200 > stack. The codepaths for running 32-bit-int/8-bit-byte/two's-comp > emulation on a 36-bit-word/9-bit-byte/ones'-comp system being emulated > on a 64-bit-word/8-bit-byte/two's-comp system are a bit cringeworthy > to think about. The latter could be avoided if the Standard defined types which would behave as an 8, 16, 32, and 64-bit integers regardless of the underlying word size, with 8 bits of data stored in each char (if CHAR_BITS > 8, then each such type would have CHAR_BITS-8 bits of padding for each char therein, which must be zeroed on write and ignored on read. If code that needs to use such types could specify them directly, then a compiler which needs to emulate the Unisys types could process the fixed-layout sizes using the system's built-in types rather than by trying to emulate them on top of emulated 9/18/36-bit ones. Such a vast majority of communications are octet-based that pretending that there's nothing special about such types alienates systems with other sizes far more than would specifying efficient means by which such systems can exchange data with octet-based ones.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-01 08:41 -0700 |
| Message-ID | <lnfugoinzh.fsf@kst-u.example.com> |
| In reply to | #108849 |
raltbos@xs4all.nl (Richard Bos) writes:
[...]
> (Note also that the reason for the difference in treatment of signed and
> unsigned integers is obvious: there is no equivalent for unsigned
> representations of the distinction between 2'C, 1'C and S/M. The only
> different kind of unsigned representation you _can_ reasonably have is
> saturation; and that is unnatural and massively expensive to every kind
> of machine representation, including even mechanical odometers.)
Saturation is not a representation. Representation is about what bits
represent what values. Saturation vs. wraparound is about the result of
operations.
--
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]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web