Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28006 > unrolled thread
| Started by | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| First post | 2014-01-22 13:52 -0800 |
| Last post | 2014-01-26 01:59 +0100 |
| Articles | 20 on this page of 412 — 34 participants |
Back to article view | Back to comp.lang.forth
CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 13:52 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-22 21:57 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:10 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:11 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 00:14 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 14:28 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-23 20:22 +1100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 12:34 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-25 22:44 +1100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-25 08:49 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 19:40 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 23:01 +1100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 03:43 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:10 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 10:31 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 11:35 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 13:27 +0000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 15:50 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:51 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:00 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:08 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:26 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:23 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:41 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 00:49 +1100
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 03:01 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 08:21 -0600
Re: CASE mis-understanding? BF <foxaudioresearch@gmail.com> - 2014-01-23 06:54 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-01-23 16:00 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:21 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:33 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:33 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:14 +0000
Re: CASE mis-understanding? Ron Aaron <rambamist@gmail.com> - 2014-01-24 10:49 +0200
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 03:26 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:25 -0500
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 22:09 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 22:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 03:22 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 06:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 16:03 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 10:14 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:42 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 10:42 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:01 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 12:16 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 07:16 -0600
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:43 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-24 10:57 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 03:58 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:24 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-27 19:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-28 03:34 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:50 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:15 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-24 21:00 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 20:47 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:36 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-24 00:44 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:20 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:02 +0000
Re: CASE mis-understanding? Elizabeth D Rather <erather@forth.com> - 2014-01-23 09:05 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 00:43 +1100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-26 18:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-26 11:27 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-26 22:09 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-26 15:35 -0600
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 01:57 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-28 13:46 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-28 12:12 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 17:19 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:40 +1100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-31 06:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-31 12:13 -0600
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:36 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 00:06 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-31 15:34 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 16:18 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-01 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-02 13:10 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-02 16:06 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-02 10:43 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-02 18:39 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:18 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:49 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:35 +0000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-03 09:56 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-03 02:50 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-03 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 14:31 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:17 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-04 12:23 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:26 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-04 08:05 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 19:07 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:59 +0000
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:34 +0100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:38 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-30 15:51 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 15:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-09 10:56 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 15:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-10 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:22 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-11 05:23 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-12 10:54 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-10 18:12 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 05:13 -0600
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 15:44 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 10:40 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-10 17:47 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 16:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 11:09 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 17:20 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 12:14 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-10 22:38 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 03:46 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:30 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:24 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-12 15:02 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 11:23 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:54 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:41 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-13 14:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 08:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 15:29 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 12:07 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 16:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:22 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-17 12:28 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-17 14:05 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 09:49 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 19:06 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 12:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 22:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:36 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 09:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 05:01 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:19 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 08:28 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 17:14 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 11:46 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:20 -0500
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-19 17:10 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-19 23:17 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-20 09:55 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:15 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:08 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 14:45 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:29 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:29 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:33 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:13 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 17:30 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 14:38 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-26 20:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 04:54 -0600
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 12:56 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 06:30 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 05:29 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 15:48 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:13 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-28 11:21 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 16:20 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 01:51 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 23:36 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 12:45 +0000
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-01 13:59 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 13:03 +0000
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-03-01 07:53 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:12 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:46 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:56 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 10:08 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 11:01 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:12 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 19:53 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 07:48 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 16:05 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:27 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:45 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 20:51 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 08:46 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-03-01 16:53 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-01 15:06 -1000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:50 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-03 17:18 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-04 03:20 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-04 19:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-05 03:51 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 10:11 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-05 14:09 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 15:43 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 22:16 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-02 04:56 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-02 14:07 +0000
Re: CASE mis-understanding? Mark Wills <markwills1970@gmail.com> - 2014-03-03 00:59 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-02 08:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-03 03:03 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:09 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-06 17:26 -0600
WITHIN (was: CASE mis-understanding?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:51 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-07 12:13 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 05:07 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 15:43 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 08:23 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:37 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 10:18 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 10:48 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:02 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-09 01:24 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-09 18:16 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 21:46 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:28 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 19:36 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:25 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 23:52 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 10:15 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 08:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 09:36 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-03-02 20:16 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:18 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 08:26 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:37 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:31 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:18 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 11:17 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-03-09 20:49 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:22 -0500
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 15:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 18:32 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 03:39 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:19 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 13:03 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-24 01:25 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:36 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 02:04 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:15 +0100
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-22 21:09 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:55 -0800
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-23 00:47 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 01:45 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-20 17:07 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-20 16:03 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:11 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-21 03:26 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:49 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-22 13:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:13 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:45 -0500
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-21 20:18 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-22 15:24 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:37 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 03:20 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:15 -0400
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-12 00:10 -0700
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:28 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 08:56 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 01:27 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:33 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 08:11 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 21:44 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:48 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:23 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 16:05 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 18:15 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 18:45 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 19:18 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:40 +0000
Re: CASE mis-understanding? Tristan Plumb <st@trstn.net> - 2014-02-26 15:27 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:31 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 16:30 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 11:48 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-22 18:28 -0800
Re: CASE mis-understanding? Gary Bergstrom <forthprgrmr@gmail.com> - 2014-02-24 08:39 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-24 21:29 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:44 +0000
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:45 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:35 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 12:31 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:19 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:06 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 12:51 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:40 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 08:17 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:48 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 13:56 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:15 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:24 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-19 03:46 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:10 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 13:09 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 15:03 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 15:53 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-14 00:39 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-14 06:38 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 15:37 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:33 -0600
Re: CASE mis-understanding? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-02-11 10:50 +0100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:57 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-11 02:35 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:47 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 13:08 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:42 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 10:54 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 05:31 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 10:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:27 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:49 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:54 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:26 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:41 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-07 01:08 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:56 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-07 12:15 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:39 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-31 07:29 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-04 23:45 +1100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-31 16:31 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 12:35 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:32 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:31 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:40 -1000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 22:03 -0800
Re: CASE mis-understanding? julian.fondren@gmail.com - 2014-01-29 17:19 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-30 11:15 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 13:57 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:01 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:49 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 10:07 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 21:54 -0800
Re: CASE mis-understanding? Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-01-29 00:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-29 03:37 -0600
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-30 21:51 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-31 18:44 -0500
Re: CASE mis-understanding? David Thompson <dave.thompson2@verizon.net> - 2014-02-09 00:34 -0500
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-09 22:14 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:25 +0000
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-01-31 17:44 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 16:03 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 01:55 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-01 11:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-01 08:11 -1000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-02 14:28 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:28 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:34 +1100
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-07 03:52 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:41 +1100
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-07 18:33 -0500
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-08 00:31 +0100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:21 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-08 15:03 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-08 19:58 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 08:33 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-09 19:50 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 08:42 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 16:32 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-14 02:36 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:04 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:40 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-14 04:37 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-14 09:42 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-15 16:52 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-16 07:46 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 08:11 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-16 16:15 -0800
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-17 09:03 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 22:12 -1000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-17 02:29 -0800
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 04:27 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:36 -1000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:22 -1000
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 12:06 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-17 20:18 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:48 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:10 -0400
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-14 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-06 17:03 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:39 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-07 20:12 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 21:33 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:38 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 16:17 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 08:54 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:25 -1000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 20:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 11:13 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:39 -0500
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:05 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-25 11:46 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-25 16:15 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:59 +0100
Page 8 of 21 — ← Prev page 1 … 6 7 [8] 9 10 … 21 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-17 12:52 -0600 |
| Message-ID | <waidnb0UgsHox5_OnZ2dnUVZ_uKdnZ2d@supernews.com> |
| In reply to | #28501 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Yes, and be pretty conservative about it. >> >> But "pretty conservative" is not a specification. That's my core >> point. There is no way to turn what you suggest into a specification >> that can be implemented. Somehow the compiler author has to guess >> about the knowledge level of the programmer. It is an impossible >> task, because the beginner is surprised by pretty much everything that >> a compiler does. So, a compiler author would have to guess about the >> knowledge level of their target audience, and aim low. > > My core point is that you, as compiler writer, are responsible for > the specification, you need to document it and stay with what you > documented. Well, yes. > As a rule, you have an underlying machine model (e.g. two's > complement signed arithmetics) for statements like x<x-1, and for > this machine modell, the statement makes sense and delivers a > predictable result on overflow. But that's not the C model: that's the Java model. When we did GCJ we added -fwrapv to provide this feature because Java needs it, but it's there for C too. So, if you really want code like that to work, there is an option that supports it. What more do you want, except to force everyone else to use it too? > The problem with taking a weasel-worded standard like the C standard > is that the standard can't tell you if the system is two's > complement, one's complement or even something else. I haven't noticed that in this case C is weasel-worded at all: the expression you're talking about is explicitly undefined. > That's ok, though a standard team should realize when one > representation has won: The one's complement dinosaurs are extinct. > Then you can tighten up your spec. I don't think there's much chance of that happening because it would disable a class of loop optimizations, and the authors of the standard seem to prefer optimizations to well-defined behaviour on integer overflow. > If you take GCC's approach on ANS Forth, you would deliberately > miscompile all code that wouldn't produce identical results on mixed > and separate FP stacks, because that code "is obviously > non-standard" and therefore broken. This is your attitude. No, it's not. If the code is well-defined and has an environmental dependency on separate FP stacks, and the system has a separate stacks, the everything is fine. You know why? Because that's what the standard says. And that's the only reason. > A statement like if(x<x-1) works only if you have a non-throwing > wraparound overflow behavior. So this has an evironmental > restriction to non-throwing wraparound overflow. > What does x86 do on overflows? Yes: it doesn't throw an exception, > and it wraps around. Fine, so now you know what your system does. > You have to stick to that behavior when you optimize! Well, no, you don't. This is something you just made up. > C is a relatively small programming language, it has few types > (integer in two signness flavors and up to 6 sizes, with bit being > the smallest), float in three sizes, pointers), a few storage types > (local variables, thread- local memory, thread-shared memory with > atomic operations), and the operations on those are not too many, > too. It takes perhaps a day or so to write down a formal VM > specification on all those operations. That would be my starting > point when I wrote a compiler suite: define a common, sane VM. And > then, you can prove that your optimizations only improve speed, but > don't alter semantics. OK, that would at least be possible for someone to implement. Written carefully, it could be a C implementation as well. But I think you would find that your "written in a day or so" specification would need a considerable amount of clarification, particularly in the area of concurrency. And if you nailed it down too hard you wouldn't leave much room for optimization. In contrast, I have no idea what really Anton expects C to do, and I doubt that he really does either. It's an "intuitionist school of programming languages" where a language implementation should do whatever Joe Random thinks it ought to do, and the poor compiler writer had better guess. It's very easy to pick extreme cases and say "GCC shouldn't do this". It much harder to specify around the boundaries exactly what it is allowed to do. Having said that, there have been cases of behaviour that was allowed by the C standard but was so dangerous that it shouldn't ever be implemented: one example I remember was speculative stores into conditionals. So I'm not totally opposed to the "it shouldn't do that even if it's allowed to in theory" argument in some specific cases, when there is an extremely good argument. But that argument needs to be better than "x86 does do it". Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-17 22:51 +0100 |
| Message-ID | <ldu09r$b6r$1@online.de> |
| In reply to | #28503 |
Andrew Haley wrote: >> As a rule, you have an underlying machine model (e.g. two's >> complement signed arithmetics) for statements like x<x-1, and for >> this machine modell, the statement makes sense and delivers a >> predictable result on overflow. > > But that's not the C model: that's the Java model. When we did GCJ we > added -fwrapv to provide this feature because Java needs it, but it's > there for C too. So, if you really want code like that to work, there > is an option that supports it. What more do you want, except to force > everyone else to use it too? Er, if you want to miscompile code, don't do it by default. >> The problem with taking a weasel-worded standard like the C standard >> is that the standard can't tell you if the system is two's >> complement, one's complement or even something else. > > I haven't noticed that in this case C is weasel-worded at all: the > expression you're talking about is explicitly undefined. You still don't seem to understand why a standard "undefines" particular behavior: It undefines it, because it wants to support different machines, where one supports wrapv behavior, and the other doesn't. The usual suspects of C targets all are two's complement wrapv machines, but I'm sure there are (or were) some obscure machines that behave differently. >> That's ok, though a standard team should realize when one >> representation has won: The one's complement dinosaurs are extinct. >> Then you can tighten up your spec. > > I don't think there's much chance of that happening because it would > disable a class of loop optimizations, and the authors of the standard > seem to prefer optimizations to well-defined behaviour on integer > overflow. Ok. That's our main point of bad attitude. That's the Seymour Cray attitude: better be fast than be correct. Ok for supercomputers. >> A statement like if(x<x-1) works only if you have a non-throwing >> wraparound overflow behavior. So this has an evironmental >> restriction to non-throwing wraparound overflow. >> What does x86 do on overflows? Yes: it doesn't throw an exception, >> and it wraps around. Fine, so now you know what your system does. >> You have to stick to that behavior when you optimize! > > Well, no, you don't. This is something you just made up. I made up that x86 wraps around on overflow? The mind boggles! It does wraparound, and so do all other significant processors today. You C guys made up that this is undefined. Come on, get real, and study what the machines you compile code for actually do! Actually, GCC 4.8 is a significant slowdown for performance critical things, e.g. both Keccak (SHA-3) reference code and ed25519-donna are about 20% slower than on GCC 4.7 or 4.6. And for optimizing, GCC 4.8 miscompiled at one point in time even a SPEC entry (h.264 reference code). If you really cared about performance, you would actually produce faster code, wouldn't you? Why is the code then significantly slower? As to forcing people: Why does GCC ignore -fomit-frame-pointer in -fPIC mode? This causes a significant slowdown on Gforth for x86 in library mode, because we have one scarce register less (it worked once apon a time, and the documentation only tells you "you shouldn't do this because it doesn't provide good backtraces" - yeah, C backtraces in Gforth don't produce useful results in any case, you need the Forth backtrace). I do care about performance. I don't get it. And I get broken code, with the excuse that this is there for performance boosts. I could accept that if I did get a considerable performance boost, but I get a slowdown. I understand that the C people don't want to hear that their language is no good except as portable assembler. They want to be a real language, with real types instead of just different register widths and so. Please, get those people over to GHC, which needs more people of that attitude - a slow and bloated compiler (with a maintenance nightmare source code) producing slow bloated results, but for a language that is very detached from computer reality (but close to computer science imagination ;-). > OK, that would at least be possible for someone to implement. Written > carefully, it could be a C implementation as well. But I think you > would find that your "written in a day or so" specification would need > a considerable amount of clarification, particularly in the area of > concurrency. And if you nailed it down too hard you wouldn't leave > much room for optimization. Hm, for concurrency, I would need to specify which operations are atomic; you would have to specify them explicitely as atomic, and I need a sane "volatile" spec. One of the troubles C has with concurrency is that "volatile" is deliberately misspecified, as well (why are you C guys doing this sort of stuff?), so you can't use it for inter-thread communication (if the compiler actually implements it with the limitations of the spec). Again: IMHO, Java's volatile definition is sane, C's isn't; if you implement Java's volatile, the result of compiling C code is still standard, but it is actually useful. Yes, a number of optimizations with volatile stuff is not possible. That are those optimizations that break concurrent code. The "volatile" statement is only useful for concurrent code and hardware registers, otherwise you wouldn't declare your variables "volatile". I'm suggesting that a considerable amount of the one-day's work of specifying a C implementation machine model would be cut&paste from other sources that already did a good job. I'm not in the NIH camp, I only do things myself when they lack the quality I want. I'm far from being a Java fan, but I have to admit that some parts of Java are simply done right, or at least "good enough". > Having said that, there have been cases of behaviour that was allowed > by the C standard but was so dangerous that it shouldn't ever be > implemented: one example I remember was speculative stores into > conditionals. So I'm not totally opposed to the "it shouldn't do that > even if it's allowed to in theory" argument in some specific cases, > when there is an extremely good argument. But that argument needs to > be better than "x86 does do it". The argument is "the actual hardware does it", and if you take the wrapv behavior, this is far broader than x86. This is the de facto industry standard on integer arithmetics. GCC has several optimization levels. If you compile your program with agressive optimization, like -O3, IMHO you are allowed to do dangerous optimizations which may break programs. -fwrapv however is disabled by default even without optimization (-O0). Some stuff is simply foolish. -fgcse is said to be dangerous when used with computed gotos, and indeed, when it was introduced, we looked horrified at the result, and found that this stuff simply doesn't work with computed gotos. The obvious cure would be to simply to treat a computed goto as barrier for global common subexpression elimination (and while we are at it: also as barrier to control flow optimization. This is a GCC extension, the people who use it know what they do, and all attempts to optimize that turned into a debacle and severe performance degradation - optimize to get worse results? WTF?). Or to not enable it by default (maybe only for -O3). There's the same thing we tell Hugh here: If you do something, measure it and look at the results. If the results aren't good, it wasn't a good idea. Any arguments about theoretical benefits are always dwarfed by real measurements. In general, I prefer a robust but simple compiler to a fragile, and complex compiler, even if the fragile and complex compiler in theory could produce better code. In practice, it produces worse code, and has way more bugs. In the 90s, GCC produced considerably slower code on SPEC benchmarks than the competitors, which sometimes simply miscompiled the SPEC benchmarks just to be faster (AFAIK, Intel and DEC hat to roll back some insane optimizations, because they only looked like they were producing the same results - but the test cases in SPEC were insufficient). But when you knew what you were doing, GCC was reliably producing code as good as hand-written assembler. This is no longer the case, GCC is considerably worse now. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-18 04:36 -0600 |
| Message-ID | <YLCdnXmF2Z47qp7OnZ2dnUVZ_umdnZ2d@supernews.com> |
| In reply to | #28507 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >>> As a rule, you have an underlying machine model (e.g. two's >>> complement signed arithmetics) for statements like x<x-1, and for >>> this machine modell, the statement makes sense and delivers a >>> predictable result on overflow. >> >> But that's not the C model: that's the Java model. When we did GCJ we >> added -fwrapv to provide this feature because Java needs it, but it's >> there for C too. So, if you really want code like that to work, there >> is an option that supports it. What more do you want, except to force >> everyone else to use it too? > > Er, if you want to miscompile code, don't do it by default. So, you want *your* interpretation of the semantics to be the default. Note that I'm not calling it a "misinterpretation" because I respect your right to an opinion, however misguided. >>> The problem with taking a weasel-worded standard like the C standard >>> is that the standard can't tell you if the system is two's >>> complement, one's complement or even something else. >> >> I haven't noticed that in this case C is weasel-worded at all: the >> expression you're talking about is explicitly undefined. > > You still don't seem to understand why a standard "undefines" > particular behavior: It undefines it, because it wants to support > different machines, where one supports wrapv behavior, and the other > doesn't. I think there are other reasons for leaving things undefined. In stating that I don't understand you are being unnecessarily rude: I do understand your point, but I respectfully disagree with it. >>> That's ok, though a standard team should realize when one >>> representation has won: The one's complement dinosaurs are extinct. >>> Then you can tighten up your spec. >> >> I don't think there's much chance of that happening because it would >> disable a class of loop optimizations, and the authors of the standard >> seem to prefer optimizations to well-defined behaviour on integer >> overflow. > > Ok. That's our main point of bad attitude. That's the Seymour Cray > attitude: better be fast than be correct. Ok for supercomputers. Don't get me wrong: I think you may have a point. You're just addressing it to the wrong people. The place to fix this, if it is to be fixed, is in the place where a language is defined. >>> A statement like if(x<x-1) works only if you have a non-throwing >>> wraparound overflow behavior. So this has an evironmental >>> restriction to non-throwing wraparound overflow. >>> What does x86 do on overflows? Yes: it doesn't throw an exception, >>> and it wraps around. Fine, so now you know what your system does. >>> You have to stick to that behavior when you optimize! >> >> Well, no, you don't. This is something you just made up. > > I made up that x86 wraps around on overflow? That's not what you said. You were specifically talking about the phrase "if(x<x-1)", not any particular x86 instruction. If you need precise x86 behaviour you need either a language whcih defines that behaviour, or assembly language. The place to fix this, if it is to be fixed, is in the place where a language is defined. > Actually, GCC 4.8 is a significant slowdown for performance critical > things, e.g. [...] Why is the code then significantly slower? Shrug. It happens. Looks like a performace regression, and it'll probably be fixed. > As to forcing people: Why does GCC ignore -fomit-frame-pointer in > -fPIC mode? I don't know. Have you looked? Is it part of the ABI, as I speculated? >> OK, that would at least be possible for someone to implement. >> Written carefully, it could be a C implementation as well. But I >> think you would find that your "written in a day or so" >> specification would need a considerable amount of clarification, >> particularly in the area of concurrency. And if you nailed it down >> too hard you wouldn't leave much room for optimization. > > Hm, for concurrency, I would need to specify which operations are > atomic; you would have to specify them explicitely as atomic, and I > need a sane "volatile" spec. I think you'll find it's much more complicated than that. >> But that argument needs to be better than "x86 does do it". > > The argument is "the actual hardware does it" Well, yes. The argument needs to be better than that one. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 09:34 +0000 |
| Message-ID | <2014Feb18.103428@mips.complang.tuwien.ac.at> |
| In reply to | #28503 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> As a rule, you have an underlying machine model (e.g. two's
>> complement signed arithmetics) for statements like x<x-1, and for
>> this machine modell, the statement makes sense and delivers a
>> predictable result on overflow.
>
>But that's not the C model: that's the Java model. When we did GCJ we
>added -fwrapv to provide this feature because Java needs it, but it's
>there for C too. So, if you really want code like that to work, there
>is an option that supports it. What more do you want, except to force
>everyone else to use it too?
First you miscompiled (silently), and only later you added the option,
and a warning. The right way to go would be to not miscompile by
default; if the programmer indicates that his intent is to write 100%
pure standard C code with "-ansi -pedantic" (gcc already has this
option), you can do optimizations based on all the undefined
behaviours. But there's a reason why "-ansi -pedantic" is not the
default in gcc, and that reason is at least as valid for optimizations
as for the rest. No, I don't want to force everybody to use
wraparound for signed integers, I don't even want the compiler to
never optimize based on "undefined behaviours" in the C standard. But
I don't want the compiler to use such "optimizations" by default,
because then they often result in miscompilation.
>> If you take GCC's approach on ANS Forth, you would deliberately
>> miscompile all code that wouldn't produce identical results on mixed
>> and separate FP stacks, because that code "is obviously
>> non-standard" and therefore broken. This is your attitude.
>
>No, it's not. If the code is well-defined and has an environmental
>dependency on separate FP stacks, and the system has a separate
>stacks, the everything is fine. You know why? Because that's what
>the standard says. And that's the only reason.
What Forth-94 says about the floating-point stack is an exercise in
weasel-wording and Forth-2012 is not much better. For Forth-2012
that's because the committee did not find a consensus on the right
approach, and I guess that's also true for Forth-94.
Given that weasel-wording, it would be easy for someone so inclined to
justify the miscompilation (possibly after some course in language
lawyering given by C compiler writers).
> But I think you
>would find that your "written in a day or so" specification would need
>a considerable amount of clarification, particularly in the area of
>concurrency.
Is concurrency covered in C at all?
>And if you nailed it down too hard you wouldn't leave
>much room for optimization.
That's fine.
>In contrast, I have no idea what really Anton expects C to do, and I
>doubt that he really does either. It's an "intuitionist school of
>programming languages" where a language implementation should do
>whatever Joe Random thinks it ought to do, and the poor compiler
>writer had better guess.
I know what I expect. The question is whether others expect that,
too. For the most part, I think so, but others might expect even more
things to work. E.g., I don't expect a particular arrangement of
parameters in memory, but I have seen code that expected such an
arrangement (and it worked, to my surprise). I have only seen such
code once, and a long time ago, so maybe this is no longer relevant.
>It's very easy to pick extreme cases and say "GCC shouldn't do this".
>It much harder to specify around the boundaries exactly what it is
>allowed to do.
That's were "be conservative" comes in. When in doubt, better don't
change the behaviour.
>Having said that, there have been cases of behaviour that was allowed
>by the C standard but was so dangerous that it shouldn't ever be
>implemented: one example I remember was speculative stores into
>conditionals. So I'm not totally opposed to the "it shouldn't do that
>even if it's allowed to in theory" argument in some specific cases,
>when there is an extremely good argument. But that argument needs to
>be better than "x86 does do it".
For
if (x<x-1) ...
every single target of gcc does have wrap-around 2's-complement
arithmetics (and this would even work for wraparound 1s-complement and
wraparound sign-magnitude arithmentics, if they exist; and "if
(x<=x-1)" would even work for saturating arithmetics, but that's not
used for ordinary ints on any platform I know).
But actually, some piece of code may be intended to only work on IA32
(or x86 as people with little knowledge of computer architecture call
it), so even if it would not work on some other architecture targeted
by gcc (the only thing that comes to my mind is alignment issues), the
compiler should preserve the behaviour by default when compiling for
IA32.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-18 05:01 -0600 |
| Message-ID | <spadnZKuutcFoJ7OnZ2dnUVZ_oWdnZ2d@supernews.com> |
| In reply to | #28514 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> As a rule, you have an underlying machine model (e.g. two's >>> complement signed arithmetics) for statements like x<x-1, and for >>> this machine modell, the statement makes sense and delivers a >>> predictable result on overflow. >> >>But that's not the C model: that's the Java model. When we did GCJ we >>added -fwrapv to provide this feature because Java needs it, but it's >>there for C too. So, if you really want code like that to work, there >>is an option that supports it. What more do you want, except to force >>everyone else to use it too? > I don't want the compiler to use such "optimizations" by default, > because then they often result in miscompilation. Your opinion has been noted. >>> If you take GCC's approach on ANS Forth, you would deliberately >>> miscompile all code that wouldn't produce identical results on mixed >>> and separate FP stacks, because that code "is obviously >>> non-standard" and therefore broken. This is your attitude. >> >>No, it's not. If the code is well-defined and has an environmental >>dependency on separate FP stacks, and the system has a separate >>stacks, the everything is fine. You know why? Because that's what >>the standard says. And that's the only reason. > > What Forth-94 says about the floating-point stack is an exercise in > weasel-wording and Forth-2012 is not much better. For Forth-2012 > that's because the committee did not find a consensus on the right > approach, and I guess that's also true for Forth-94. > > Given that weasel-wording, it would be easy for someone so inclined to > justify the miscompilation (possibly after some course in language > lawyering given by C compiler writers). I don't believe so. >>But I think you would find that your "written in a day or so" >>specification would need a considerable amount of clarification, >>particularly in the area of concurrency. > > Is concurrency covered in C at all? Yes. >>It's very easy to pick extreme cases and say "GCC shouldn't do this". >>It much harder to specify around the boundaries exactly what it is >>allowed to do. > > That's were "be conservative" comes in. When in doubt, better don't > change the behaviour. But where exactly is that "in doubt" boundary? And who is to be in doubt? >>Having said that, there have been cases of behaviour that was allowed >>by the C standard but was so dangerous that it shouldn't ever be >>implemented: one example I remember was speculative stores into >>conditionals. So I'm not totally opposed to the "it shouldn't do that >>even if it's allowed to in theory" argument in some specific cases, >>when there is an extremely good argument. But that argument needs to >>be better than "x86 does do it". > > For > > if (x<x-1) ... > > every single target of gcc does have wrap-around 2's-complement > arithmetics (and this would even work for wraparound 1s-complement and > wraparound sign-magnitude arithmentics, if they exist; and "if > (x<=x-1)" would even work for saturating arithmetics, but that's not > used for ordinary ints on any platform I know). > > But actually, some piece of code may be intended to only work on IA32 > (or x86 as people with little knowledge of computer architecture call > it), so even if it would not work on some other architecture targeted > by gcc (the only thing that comes to my mind is alignment issues), the > compiler should preserve the behaviour by default when compiling for > IA32. This is just a restatement of your previous opinion. There's no "...because" other than "that's what the hardware does." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 14:19 +0000 |
| Message-ID | <2014Feb18.151937@mips.complang.tuwien.ac.at> |
| In reply to | #28517 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>> If you take GCC's approach on ANS Forth, you would deliberately
>>>> miscompile all code that wouldn't produce identical results on mixed
>>>> and separate FP stacks, because that code "is obviously
>>>> non-standard" and therefore broken. This is your attitude.
>>>
>>>No, it's not. If the code is well-defined and has an environmental
>>>dependency on separate FP stacks, and the system has a separate
>>>stacks, the everything is fine. You know why? Because that's what
>>>the standard says. And that's the only reason.
>>
>> What Forth-94 says about the floating-point stack is an exercise in
>> weasel-wording and Forth-2012 is not much better. For Forth-2012
>> that's because the committee did not find a consensus on the right
>> approach, and I guess that's also true for Forth-94.
>>
>> Given that weasel-wording, it would be easy for someone so inclined to
>> justify the miscompilation (possibly after some course in language
>> lawyering given by C compiler writers).
>
>I don't believe so.
I'll have a try at such a justification:
"You know why? Because that's what the standard says. And that's the
only reason."
>>>It's very easy to pick extreme cases and say "GCC shouldn't do this".
>>>It much harder to specify around the boundaries exactly what it is
>>>allowed to do.
>>
>> That's were "be conservative" comes in. When in doubt, better don't
>> change the behaviour.
>
>But where exactly is that "in doubt" boundary? And who is to be in
>doubt?
The compiler writer. And the doubt cases are whenever they are in
doubt of what the programmer intended.
>> For
>>
>> if (x<x-1) ...
>>
>> every single target of gcc does have wrap-around 2's-complement
>> arithmetics (and this would even work for wraparound 1s-complement and
>> wraparound sign-magnitude arithmentics, if they exist; and "if
>> (x<=x-1)" would even work for saturating arithmetics, but that's not
>> used for ordinary ints on any platform I know).
>>
>> But actually, some piece of code may be intended to only work on IA32
>> (or x86 as people with little knowledge of computer architecture call
>> it), so even if it would not work on some other architecture targeted
>> by gcc (the only thing that comes to my mind is alignment issues), the
>> compiler should preserve the behaviour by default when compiling for
>> IA32.
>
>This is just a restatement of your previous opinion. There's no
>"...because" other than "that's what the hardware does."
It's not just what the hardware does. It's what gcc does, unless the
"optimizer" comes into play. On MIPS it compiles + of signed integers
into addu, not add (which produces an exception on overflow); on Alpha
into add, not addv (again exception on overflow). On IA32 into add
without following it with into. When I rearrange the code so that the
"optimizer" does not see everything together, gcc does what I intend
the code to do. A proper optimizer does not change that.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-18 08:28 -0800 |
| Message-ID | <7xppmks7v9.fsf@ruckus.brouhaha.com> |
| In reply to | #28525 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > It's not just what the hardware does. It's what gcc does, unless the > "optimizer" comes into play. On MIPS it compiles + of signed integers > into addu, not add (which produces an exception on overflow); on Alpha > into add, not addv (again exception on overflow). On IA32 into add > without following it with into. When I rearrange the code so that the > "optimizer" does not see everything together, gcc does what I intend > the code to do. A proper optimizer does not change that. Are you seriously saying that the optimized program always has to do the exact same thing as the unoptimized one, even when the standard explicitly says the behavior is undefined? Example: I've seen code that had a function compute some stuff in local variables, whose content got left on the stack after the function returned. Later code then (hopefully not on purpose) accessed the contents of the stack slots which in an unoptimized compilation, would not have been disturbed. Are you seriously saying an optimizer should preserve that behavior? Certainly lots of C errors can be caught by static analyzers that go beyond what it's reasonable to expect a compiler to do. Lots of others are basically arguments to not use C. You've probably seen: http://css.csail.mit.edu/stack/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 17:14 +0000 |
| Message-ID | <2014Feb18.181426@mips.complang.tuwien.ac.at> |
| In reply to | #28529 |
Paul Rubin <no.email@nospam.invalid> writes:
>Are you seriously saying that the optimized program always has to do the
>exact same thing as the unoptimized one, even when the standard
>explicitly says the behavior is undefined?
Yes, in most cases.
> Example: I've seen code that
>had a function compute some stuff in local variables, whose content got
>left on the stack after the function returned. Later code then
>(hopefully not on purpose) accessed the contents of the stack slots
>which in an unoptimized compilation, would not have been disturbed.
>Are you seriously saying an optimizer should preserve that behavior?
Uninitialized data is one of the possible exceptions we discussed.
Maybe you should read the discussion from the beginning.
>You've probably seen: http://css.csail.mit.edu/stack/
Not that I remember. I find it interesting that the page says:
|Optimization-unstable code (unstable code for short) is an emerging
|class of software bugs
Where does it emerge from? It emerges from the fashion of some
compiler writers (especially in the C world) to turn their compilers
into miscompilers. Better fix the cause than introduce workarounds in
the form of analysers; of course analysers can still be valuable for
the exceptions such as uninitialized data (However, I expect better
results from dynamic analyzers than static analyzers in this area).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-18 11:46 -0800 |
| Message-ID | <7xmwhoi4px.fsf@ruckus.brouhaha.com> |
| In reply to | #28534 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> |Optimization-unstable code (unstable code for short) is an emerging
> |class of software bugs
>
> Where does it emerge from? It emerges from the fashion of some
> compiler writers (especially in the C world) to turn their compilers
> into miscompilers.
The C standard has two classes of unspecified behavior: "implementation
dependent" where the compiler writer gets to choose what semantics they
want, but then they have to stick to it consistently; and "undefined"
where consistency is not required. I think you're saying that various
program constructs should be treated as as implementation dependent
(i.e. consistently) even when the standards committee chose to allow
inconsistency. You may be right, but the problem would seem to be with
the C language (as defined by the standard), not with implementations
doing what the standard says.
From http://blog.regehr.org/archives/970 :
Compilers are getting smarter all the time, causing code that
previously worked to break. A sufficiently advanced compiler is
indistinguishable from an adversary.
I would think robust code should be written to withstand adversarial
compilation. I'd be supportive of a "-fperverse" gcc flag which
deliberately breaks code as hard as it can while still staying standard
conformant, and test suites should use this flag.
> (However, I expect better results from dynamic analyzers than static
> analyzers in this area).
These might be of interest:
http://frama-c.com/
http://code.google.com/p/c-semantics/
http://embed.cs.utah.edu/ioc/
The links are from here:
http://blog.regehr.org/archives/761
a slightly sarcastic post about optimizing around undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-18 18:20 -0500 |
| Message-ID | <op.xbh24hdj5zc71u@localhost> |
| In reply to | #28537 |
On Tue, 18 Feb 2014 14:46:34 -0500, Paul Rubin <no.email@nospam.invalid> wrote: > The C standard has two classes of unspecified behavior: "implementation > dependent" where the compiler writer gets to choose what semantics they > want, but then they have to stick to it consistently; and "undefined" > where consistency is not required. I would add a few more classes: 1) required contradictions in the specification 2) result of various interactions withins C 3) translation from C to assembly or binary Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-19 17:10 +0100 |
| Message-ID | <le2l28$v31$1@online.de> |
| In reply to | #28537 |
Paul Rubin wrote:
> From http://blog.regehr.org/archives/970 :
>
> Compilers are getting smarter all the time, causing code that
> previously worked to break. A sufficiently advanced compiler is
> indistinguishable from an adversary.
>
> I would think robust code should be written to withstand adversarial
> compilation. I'd be supportive of a "-fperverse" gcc flag which
> deliberately breaks code as hard as it can while still staying standard
> conformant, and test suites should use this flag.
Let's take a look at some other place, where correctness is very important:
digital hardware design. Correctness there is important, because you can't
change the hardware after tapeout. Typical design approaches are that you
implement the simple fast stuff in hardware, and leave the complex slow
stuff to software, so that you can replace the software when it's not
correct (it is also easier to get higher-level software code correct than
lower level logic with its inherently parallel execution model).
So what's done there? There's, for start, a language like Verilog, which
doesn't leave much undefined, especially in the synthesizable subset. So
you have a precise specification of what the language actually does,
something that helps you to write correct code.
When I did the review of the b16 processor, one of the guys there, who had a
VHDL background, told me that the case statement I was using was supposed to
have "undefined semantics". In Verilog (as well as in VHDL), you can have a
number with "don't care" bits (written as ?, z, or x depending on which case
statement you use), that will match any bit. My case statement had
something lik
case 'b01001: ...
case 'b01???: ...
and the argument was that it's undefined whether the 01001 or the 01???
matches. This is true for VHDL, but wrong for Verilog: The Verilog
specification was written carefully to make sure that this doesn't lead to
undefined behavior. It's "first hit matches", i.e. a priority encoder.
The next thing you do with Verilog code is to run a formal verification tool
which checks netlist vs. source code. The RTL compilers are pretty
reliable, but for double-checking, it's a good idea to use this tool. The
formal verification tool takes a very conservative approach to semantics,
i.e. it actually overspecifies things, and you sometimes need to give it
hints. E.g. if you use the power-saving option on the RTL compiler to
produce gated clocks (which then aren't explicit code in your source, but
inserted implicitely), you have to tell the formal verification tool to
treat clock gating as equivalent to conditionals. By default, it doesn't
match those, even though the behavior is the same. This means that certain
"maybe dangerous" optimizations have to be activated by hand, on both tools
(the RTL compiler doesn't produce gated clocks by default, either). And the
formal verification tool really checks for identity, there is no "undefined
behavior" that is tolerated to be either this or that.
Of course, you also use linting to check whether the constructs you use are
all sane, e.g. checking for asynchronous clock domain crossing and that sort
of stuff you won't see in a simulation and neither timing check nor formal
verification will catch. Since the RTL compilers perform expensive
optimizations (they are big and complex pieces of software), the formal
verification tool is justified. If the compiler would be simple, you
wouldn't need such a tool.
This approach is sane and leads to pretty reliable results. The projects I
did with this technology leveraged completely were all first-time-right;
well, they were, because I kept my Verilog code simple; the way more complex
code of my Dialog coworkers never was first time right. So it helps to
catch some bugs, but for sure not all of them.
The blog you pointed to has a nice example that would certainly fail on a
formal verification:
int a = s->x;
if(s==NULL) goto error;
GCC decided to miscompile the conditional jump, because according to the C
standard, s->x is undefined if s==NULL. However, to make this
transformation valid, you must have a *defined* result of s->x (e.g.
"crashes") to take the jz error out. If it doesn't crash (and it apparently
doesn't in Linux kernel space on some architectures), you are not allowed to
optimize the jump away, because that is not an "identity" transformation.
The tool mentioned in the blog does just that: It first eliminates dead code
without taking undefined behavior into account, and then in the second step
looks at code which might be dead if undefined behavior is used to eliminate
it. And those are very few cases, and the cases it will warn you. That's
the case where the compiler is actually miscompiling the code, i.e. it does
not do identity transformations (and IMHO this is a miscompilation).
If you have the Java VM model ("null pointer dereferencing cause a
praticular exception"), you are allowed to leave the jump out, and the
kernel developers better make sure that their run-time meets the spec.
We have a significant reliability problem in software. This is partly an
attitude problem, which is why hardware guys often tell you that you
shouldn't do things that need to be reliable "in software". They are
usually fine when you do it in deeply embedded firmware, following the usual
rigid reliability checks these people do.
The attitude of compiler writer to optimize code based on "undefined
behavior" of the language standard is part of the problem. The sheer code
size of much of our software is another problem: Even well-debugged code has
a bug every few thousands lines of code. Million lines of code are simply
not acceptable.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-19 23:17 -0800 |
| Message-ID | <7xeh2yi77o.fsf@ruckus.brouhaha.com> |
| In reply to | #28583 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > The blog you pointed to has a nice example that would certainly fail on a > formal verification: > int a = s->x; > if(s==NULL) goto error; > GCC decided to miscompile the conditional jump, because according to the C > standard, s->x is undefined if s==NULL. However, to make this > transformation valid, you must have a *defined* result of s->x (e.g. > "crashes") to take the jz error out. I don't understand why you say there is a miscompilation. The blog describes it as: from the "s->x" the compiler infers that s is non-null, so it optimizes away the test. But it's equally valid to say: the compiler optimizes nothing; the null dereference is executed and since the action is undefined, the machine can do whatever it likes, such as jump around the comparison against NULL. > If it doesn't crash (and it apparently doesn't in Linux kernel space > on some architectures), you are not allowed to optimize the jump away, Who says undefined behavior has to mean "crash"? It can mean "generate a crossword puzzle", it can mean "erase the hard disk", it can mean "ignore the next comparison and keep going" (equivalent to optimizing the comparison away), etc. The point is that the execution path is no longer under the programmer's control. So I wouldn't say the compiler miscompiled anything: the compiler is only responsible for programs that don't engage in undefined behavior. > because that is not an "identity" transformation. I think by this you mean that the undefined behavior should be consistent across compiler settings, but "undefined" explicitly means you can't expect consistency. One possible conclusion (given the observed difficulty of even expert programmers to avoid these bugs) is that using C for anything critical is crazy. The Ada guys have been saying that for 30 years, maybe with good reason. If it helps, though, http://blog.regehr.org/archives/213 (same guy, and he has tons more examples and analysis of similar issues) discusses the case for C acting the way it does. > The tool mentioned in the blog does just that: It first eliminates > dead code without taking undefined behavior into account, and then in > the second step looks at code which might be dead if undefined It might be interesting to build that into the compiler if that doesn't slow down compilation too much. Other fancier checks are more expensive though. http://stanford.edu/~engler/ has lots of good links. > We have a significant reliability problem in software. ... The > attitude of compiler writer to optimize code based on "undefined > behavior" of the language standard is part of the problem. Well, the undefined behavior is part of the language design, so the standards committee is a better target of that criticism than the compiler writers. And C programmers routinely overestimate their ability to avoid undefined behaviors in their code. The other part, as you say, comes from the very high complexity of today's software. Static analysis appears to help even for Java, which has very little undefined behavior. And Ada was designed to be friendly to static analysis. I've never used it but may get to try it on something soon. Hardware guys have their own attitude problems, of course: they will screw up the useability of a design in order to save 2 cents worth of transistors. For example, comp.arch.embedded had a huge thread not that long ago, about floating point microcontrollers that implement IEEE 754 arithmetic slightly incorrectly in order to simplify the circuitry, that breaks some numerical algorithms in subtle ways.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-20 09:55 -0600 |
| Message-ID | <HY-dnRM1Utb7uJvOnZ2dnUVZ_rOdnZ2d@supernews.com> |
| In reply to | #28593 |
Paul Rubin <no.email@nospam.invalid> wrote: > > Well, the undefined behavior is part of the language design, so the > standards committee is a better target of that criticism than the > compiler writers. Hallelujah. > And C programmers routinely overestimate their ability to avoid > undefined behaviors in their code. The other part, as you say, > comes from the very high complexity of today's software. Static > analysis appears to help even for Java, which has very little > undefined behavior. It's really hard to avoid some undefined behaviour, even in something like Java where you try really hard to nail everything down. For example, some people have been puzzling over the exact definition of the lifetime of an object, and when exactly the VM might finalize an object. (The problem is that finalization can occur even while one of that object's methods is still executing, because the VM considers an object to be dead after the last access to a field of in that object has been executed. Then, finalization can occur. But people are surprised by finalization while a method of an object is still being executed.) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-21 20:15 +0100 |
| Message-ID | <le88kf$rau$1@online.de> |
| In reply to | #28593 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> The blog you pointed to has a nice example that would certainly fail on a >> formal verification: >> int a = s->x; >> if(s==NULL) goto error; >> GCC decided to miscompile the conditional jump, because according to the >> C >> standard, s->x is undefined if s==NULL. However, to make this >> transformation valid, you must have a *defined* result of s->x (e.g. >> "crashes") to take the jz error out. > > I don't understand why you Centre Pompidousay there is a miscompilation. The blog > describes it as: from the "s->x" the compiler infers that s is non-null, > so it optimizes away the test. But it's equally valid to say: the > compiler optimizes nothing; the null dereference is executed and since > the action is undefined, the machine can do whatever it likes, such as > jump around the comparison against NULL. This is just nonsense. The actual machine does not start to recite the Jabberwocky poem when you dereference a NULL pointer; it does have a very precise semantics, and what it does depends on whether there is a page mapped at address zero (it will dereference 0+some offset), or not (it will produce an segv exception). Stop thinking in this nonsense terms: The behavior of the machine on NULL dereferences is *well defined*. It's not nonsense. The standard undefines the behavior, because it can be different on different machines or systems, though there's a large common ground. >> If it doesn't crash (and it apparently doesn't in Linux kernel space >> on some architectures), you are not allowed to optimize the jump away, > > Who says undefined behavior has to mean "crash"? It can mean "generate > a crossword puzzle", it can mean "erase the hard disk", it can mean > "ignore the next comparison and keep going" (equivalent to optimizing > the comparison away), etc. But all these things only happen on wonderland computers. Grow up, and realize that the wonderland is only in your dreams. > The point is that the execution path is no > longer under the programmer's control. So I wouldn't say the compiler > miscompiled anything: the compiler is only responsible for programs that > don't engage in undefined behavior. That's the GCC writers point of view, and apparently, someone had followed the white rabbit. If you translate the s->x into a deterministic operation that either segvs or fetches that value, depending on the page mapping (which the compiler apparently doesn't know) you don't have undefined behavior. Get real: A compiler converts a C statement into machine instructions, not into wonderland miracles. >> because that is not an "identity" transformation. > > I think by this you mean that the undefined behavior should be > consistent across compiler settings, but "undefined" explicitly means > you can't expect consistency. No. Undefined means the standard can't specify the behavior, because there was no consensus. In Forth, the standard allows you to have a mixed or a separate floating point stack. A standard program that uses something like : sum-array ( addr u -- r ) 0e bounds ?DO I f@ f+ 1 floats +LOOP ; is therefore "undefined", but : sum-array ( addr u -- r ) 2>r 0e 2r> bounds ?DO I f@ f+ 1 floats +LOOP ; would be well-defined. The further program however happens to work perfect on all those separate-stack systems. According to the wonderland compiler writers, the compiler is entitled to miscompile the program above, even though the system is actually a separate-stack system. > One possible conclusion (given the > observed difficulty of even expert programmers to avoid these bugs) is > that using C for anything critical is crazy. The Ada guys have been > saying that for 30 years, maybe with good reason. If it helps, though, Ada is pretty crazy, too. You would guess that the horribly stupid overflow checks were mandatory? No, the Gnat compiler actually compiles integers as wrapv two's complement, without checks. Because that way, the code is way faster (into is a precise exception, which is costly, and since no big code- base uses into, Intel just doesn't care about performance). > http://blog.regehr.org/archives/213 Gnat in default mode actually results in exactly the same behavior he's moaning about right at the start. This guy is straight in the middle of wonderland. The wonderland of abstract computer science concept, and not real machines. > (same guy, and he has tons more examples and analysis of similar issues) > discusses the case for C acting the way it does. Apparently he's on the side of the compiler makers who make compilers which break code for no good reasons other than language lawyering somehow "allowed" them to do it. >> The tool mentioned in the blog does just that: It first eliminates >> dead code without taking undefined behavior into account, and then in >> the second step looks at code which might be dead if undefined > > It might be interesting to build that into the compiler if that doesn't > slow down compilation too much. Other fancier checks are more expensive > though. http://stanford.edu/~engler/ has lots of good links. Actually, I think, dead code eliminination should issue a warning in any case, unless you explicitely mark a block as "maybe dead". Considering my embedded experience, dead code is a bug, because it has zero test coverage. If you know that it is dead, you must remove it from the source code; if you don't know if it is dead or not, it is even worse. >> We have a significant reliability problem in software. ... The >> attitude of compiler writer to optimize code based on "undefined >> behavior" of the language standard is part of the problem. > > Well, the undefined behavior is part of the language design, so the > standards committee is a better target of that criticism than the > compiler writers. No, a standard committee is a political organization that wants to find a compromise on what is common practice. There are parts of a language where you can't find such a compromise. The compiler writer has to fill those parts with live, because he usually doesn't have to make these compromises. If you compile C for two's complement machines with expensive overflow check, wrapv is the way to go. If you had your compiler wrapv for 20 years, it is going to stay wrapv. There is no point to change that, it will break code and customers will be angry. > And C programmers routinely overestimate their > ability to avoid undefined behaviors in their code. The other part, as > you say, comes from the very high complexity of today's software. > Static analysis appears to help even for Java, which has very little > undefined behavior. And Ada was designed to be friendly to static > analysis. I've never used it but may get to try it on something soon. It is one of those BDSM languages, I wouldn't touch it. But you are quite on the side of the typechecker people... Large programs are a problem, and writing large programs is *wrong*. I remember, the coworker of my father who gave me the volksForth floppy, and got me to Forth was complaining that you couldn't write a word with more than 16 lines in Forth (because back then, it was all blocks). The right answer to that is that writing a word with more than 16 lines is wrong, and therefore the hard limit is a good thing. Actually, you could write larger words, because --> is immediate, and takes you to the next block to continue there... > Hardware guys have their own attitude problems, of course: they will > screw up the useability of a design in order to save 2 cents worth of > transistors. For example, comp.arch.embedded had a huge thread not that > long ago, about floating point microcontrollers that implement IEEE 754 > arithmetic slightly incorrectly in order to simplify the circuitry, that > breaks some numerical algorithms in subtle ways. No, that is the same class of people. Screw the customer for a small saving somewhere, those are people who should not be in business, and in hardware, this sort of stuff actually does happen: they go out of business. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-22 12:08 +0000 |
| Message-ID | <2014Feb22.130859@mips.complang.tuwien.ac.at> |
| In reply to | #28667 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>> http://blog.regehr.org/archives/213
>
>Gnat in default mode actually results in exactly the same behavior he's
>moaning about right at the start. This guy is straight in the middle of
>wonderland. The wonderland of abstract computer science concept, and not
>real machines.
No, he is not. Read comment 5 (which replies to the also the
interesting comment 4 by Matthias Felleisen (for context, Felleisen is
the author of several Scheme books), where John Regehr, the author of
the blog post, writes:
|I feel like certain languages were designed by and for compiler
|people. Optimizations good, everything else: irrelevant. Hopefully
|these languages will lose (or be revised) to cope with the modern
|situation where machine resources are relatively cheap and program
|errors are relatively costly.
In the blog post itself he just presented the situation, without
stating whether he approves or disapproves.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-22 14:45 -0800 |
| Message-ID | <7xlhx2rckq.fsf@ruckus.brouhaha.com> |
| In reply to | #28667 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > This is just nonsense. The actual machine does not start to recite the > Jabberwocky poem when you dereference a NULL pointer; If you type "null pointer exploit" into a search engine, you'll see it's indeed possible for such a dereference to send Jabberwocky to /dev/audio. That has nothing to do with over-aggressive compiler optimization. Of course the compiler doesn't emit Jabberwocky code. There instead ends up being an uncontrolled jump that can run remotely injected code that can recite Jabberwocky or do whatever else the attacker chooses. > it does have a very precise semantics, Not in C it doesn't. You can't even assume that C pointer variables contain machine addresses. If you really want to do something with location zero, you probably have to call some assembly code. Or if you want C to behave differently, talk to the standards committee. >> Who says undefined behavior has to mean "crash"? It can mean "generate >> a crossword puzzle"... > But all these things only happen on wonderland computers. Grow up, and > realize that the wonderland is only in your dreams. They actually happen in nightmares and not just the good kind of dreams. And then we wake up and learn from decades of remote exploits that those nightmares are also what happens in real deployed code. One reasonable response is that C should have been outlawed decades ago. It can't really be fixed. > That's the GCC writers point of view GCC, Clang, ICC, and every other serious optimizing compiler, from what I can tell. > If you translate the s->x into a deterministic operation that either > segvs or fetches that value, If compilers were supposed to do that, then the standard would say so. The situation where a program dereferences a null pointer for some reason other than a bug is so unusual that it can be treated as always being a bug (call assembly code or maybe use a volatile if you want location zero on purpose). Remember that the standard explicitly says taking the address of something will never give a null pointer, and malloc returning a null pointer means allocation has failed. The null pointer in C is a sentinel value that can't be validly dereferenced. So what to do if a program dereferences a null pointer anyway? The users driving the standards process weren't willing to slow down non-buggy code for the sake of making buggy code more predictable, so they specified a standard aimed at optimizing the non-buggy case. According to their philosophy, C is an amplifier (cough), and the way to make buggy code predictable is fix the bugs. If the compilers did what you wanted, you'd get supercomputer users saying "why should the compiler slow down MY careful code, just because YOU refuse to get the bugs out of your crappy code? Use better coding processes and everything will be fine." So, once again, you need to talk to the standards committee rather than the compiler writers, if you want the language to be specified differently than it is. > No. Undefined means the standard can't specify the behavior, because there > was no consensus. I don't have that impression--I thought they said "undefined" only for the sake of weird machines, optimizations, etc. Do you have a cite? > In Forth, the standard allows you to have a mixed or a separate > floating point stack. ... According to the wonderland compiler > writers, the compiler is entitled to miscompile the program above, > even though the system is actually a separate-stack system. I don't think that's comparable. Separate vs mixed stack is controlled by the compiler. There is such a thing as "unspecified" behavior in C, which is different from undefined. Example: if you call f (expression1, expression2) the args are evaluated in unspecified order. That means the compiler has 2 choices, you don't know which one it will pick, but it MUST be one or the other, it can't do something unrelated like recite "jabberwocky". Undefined is more like what happens in Forth if you say "+" with nothing on the stack (unless the Forth standard specifies this should give an underflow exception, which it might, but that can slow correct programs down). > the Gnat compiler actually compiles integers as wrapv two's > complement, without checks. Is that what the Ada spec says to do? If wrapping integers is invalid and the compiler turns off the checks by default, that's disappointing. Optionally disabling the checks is fine, with the programmer explicitly taking responsibility. > Because that way, the code is way faster (into is a precise exception, > which is costly, and since no big code- base uses into, Intel just > doesn't care about performance). That seems like an x86 hardware deficiency. Anton mentioned ADD on MIPS processors has an overflow exception. That should really be the default. > Apparently he's on the side of the compiler makers who make compilers which > break code for no good reasons other than language lawyering somehow > "allowed" them to do it. The other reason is that it makes non-buggy programs run faster, which matters to a lot of important C users. I do think those users overestimated their own ability to avoid such bugs, but this is a lesson from decades of hindsight. > Actually, I think, dead code eliminination should issue a warning in any > case, unless you explicitely mark a block as "maybe dead". Hmm, maybe, though some other situations like that can be hard to detect, and various sorts of automatically generated code can have dead code. A pragma or compiler flag could turn off the warning though. >>> We have a significant reliability problem in software. ... The >>> attitude of compiler writer to optimize code based on "undefined >>> behavior" of the language standard is part of the problem. I'm really not so convinced of that... let's imagine GCC by default doesn't optimize away those checks even with -O3, but it has a separate flag "-fultra-aggressive" which eliminates the checks, making code that's a few percent faster, if you explicitly ask for that. Do you think developers whose applications have to compete on benchmarks are going to resist enabling the flag? It amounts to an admission that they think their code is buggy. > If you had your compiler wrapv for 20 years, it is going to stay > wrapv. There is no point to change that, it will break code and > customers will be angry. That code is already broken. The way math works, adding two positive integers always results in another positive integer. If your program uses integers that accidentally break that invariant by no longer fitting in the machine representation, it will get nonsense results, i.e. it is broken. If it breaks the invariant on purpose, you should announce that intention by choosing an unsigned type. > [Ada] is one of those BDSM languages, I wouldn't touch it. It's verbose but doesn't really look worse than Java in that regard. I'm not sure what the alternatives are for embedded programming, given the terrible behavior of C programs as we're discussing. The checks that you get with Ada tools are similar to the ones you described using for Verilog. Why shouldn't a software programmer want similar levels of checking, if the application is intolerant enough of errors that it's worth slowing down the coding process by a nontrivial factor to prevent them? (Most of my own day-to-day stuff is more error-tolerant, so I code it quickly in Python and fix problems as they occur, but I wouldn't use Python for a critical app). > Large programs are a problem, and writing large programs is *wrong*. In the real world, people often want stuff from computers that can't be done with small programs, but can sometimes be done with large programs, so the large programs get written. If you ever do a Google search, there's a monstrous amount of code running it behind the scenes. Same thing if you use the speech recognition on a recent mobile phone (the phone cpu is not powerful enough, so the application sends the audio stream to a server farm that does the actual decoding and content analysis). Self-driving cars are appearing on the roads, and may reach a point where they're safer than cars driven by humans, etc. It won't be small programs doing that.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-23 02:29 +0100 |
| Message-ID | <lebiui$b0s$1@online.de> |
| In reply to | #28696 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> This is just nonsense. The actual machine does not start to recite the >> Jabberwocky poem when you dereference a NULL pointer; > > If you type "null pointer exploit" into a search engine, you'll get to places where people discuss about this GCC miscompiling stuff... Normally, you don't need to check null pointer dereferencing, because the zero page isn't mapped, and you have exception handling. Ok, in C, you don't have proper exception handling. And in the Linux kernel, you can't guarantee that the zero page is unmapped... > you'll see it's > indeed possible for such a dereference to send Jabberwocky to > /dev/audio. Yes, because GCC made it so. > That has nothing to do with over-aggressive compiler > optimization. Of course the compiler doesn't emit Jabberwocky code. It did. > There instead ends up being an uncontrolled jump that can run remotely > injected code that can recite Jabberwocky or do whatever else the > attacker chooses. > >> it does have a very precise semantics, > > Not in C it doesn't. Get you head out of the C standard. Of course C code compiles to some real machine. And there, it does have a precise semantics. > You can't even assume that C pointer variables > contain machine addresses. In general, you can't, but in GCC, that is the case. That's the stuff we call "implementation defined" in ANS Forth. > If you really want to do something with > location zero, you probably have to call some assembly code. Or if you > want C to behave differently, talk to the standards committee. The standard committee has to find compromises. They undefine everything where they can't reach a consensus. I have no axe to grind with the C standard people, I'm in a standard committee myself, and I know that there are things where people can't reach a consensus, and they have good reasons not to reach a consensus. However, when I go home to implement this stuff in Gforth, I don't have to make the same sort of concession. I only have to reach a consensus with Anton. >>> Who says undefined behavior has to mean "crash"? It can mean "generate >>> a crossword puzzle"... >> But all these things only happen on wonderland computers. Grow up, and >> realize that the wonderland is only in your dreams. > > They actually happen in nightmares and not just the good kind of dreams. > And then we wake up and learn from decades of remote exploits that those > nightmares are also what happens in real deployed code. One reasonable > response is that C should have been outlawed decades ago. It can't > really be fixed. Ok, agreed to that. The fact that C treats arrays as pointers (without length) is simply so wrong that it is broken beyond repair. I'm not sure if you can't fix it within what the C standard allows, in AS/400, this problem is fixed. A pointer there is actually always a pointer+length thing. >> That's the GCC writers point of view > > GCC, Clang, ICC, and every other serious optimizing compiler, from what > I can tell. Probably started with ICC. Intel had done several stunts in the 90s, where they produced wrong code just for the sake of faster SPEC results. As long as it did process the SPEC testbenches correctly, it was good enough. The result was that back then, very few people used ICC for production code - it was either MSVC or GCC. >> If you translate the s->x into a deterministic operation that either >> segvs or fetches that value, > > If compilers were supposed to do that, then the standard would say so. No, why? The standard is a compromise between compilers who target an 8051 and compilers who target AS/400. If you let the AS/400 people say what's well-defined, you get rid of the buffer overflows tomorrow. But the 8051 people would not be happy. > The situation where a program dereferences a null pointer for some > reason other than a bug is so unusual that it can be treated as always > being a bug (call assembly code or maybe use a volatile if you want > location zero on purpose). Remember that the standard explicitly says > taking the address of something will never give a null pointer, and > malloc returning a null pointer means allocation has failed. The null > pointer in C is a sentinel value that can't be validly dereferenced. > > So what to do if a program dereferences a null pointer anyway? The > users driving the standards process weren't willing to slow down > non-buggy code for the sake of making buggy code more predictable, so > they specified a standard aimed at optimizing the non-buggy case. > According to their philosophy, C is an amplifier (cough), and the way to > make buggy code predictable is fix the bugs. If the compilers did what > you wanted, you'd get supercomputer users saying "why should the > compiler slow down MY careful code, just because YOU refuse to get the > bugs out of your crappy code? Use better coding processes and > everything will be fine." So, once again, you need to talk to the > standards committee rather than the compiler writers, if you want the > language to be specified differently than it is. Sorry, I think you have been dragged away. The problem with this code is that the behavior of dereferencing s->x is undefined, and may or may not result in a segv violation (the compiler can't know). Because it can't know, it can't know that the check for if(!s) is unreachable. For doing that, it has to know that NULL->x causes an exception. So it either has to make sure that it does (by inserting code that does), or it has to keep the if(!s). You can't get both: undefined behavior and being able to optimize things away. >> No. Undefined means the standard can't specify the behavior, because >> there was no consensus. > > I don't have that impression--I thought they said "undefined" only for > the sake of weird machines, optimizations, etc. Do you have a cite? I'm in a standard committee following the same ANS rules. We have implementation-defined behavior, where the thing is never undefined, because the implementation has to define it (usually means "no consensus reached"). We have ambiguous conditons, which mean that the implementation may or may not define the behavior; these are conditions where we don't want to enforce a particular implementation, because we know different tradeoffs exists (therefore, an ambiguous condition is also a place where we didn't reach a consensus). >> In Forth, the standard allows you to have a mixed or a separate >> floating point stack. ... According to the wonderland compiler >> writers, the compiler is entitled to miscompile the program above, >> even though the system is actually a separate-stack system. > > I don't think that's comparable. Separate vs mixed stack is controlled > by the compiler. There is such a thing as "unspecified" behavior in C, > which is different from undefined. Example: if you call > > f (expression1, expression2) > > the args are evaluated in unspecified order. That means the compiler > has 2 choices, you don't know which one it will pick, but it MUST be one > or the other, it can't do something unrelated like recite "jabberwocky". > Undefined is more like what happens in Forth if you say "+" with nothing > on the stack (unless the Forth standard specifies this should give an > underflow exception, which it might, but that can slow correct programs > down). The exceptions are optional, therefore we can't mandate it to throw an exception. >> the Gnat compiler actually compiles integers as wrapv two's >> complement, without checks. > > Is that what the Ada spec says to do? If wrapping integers is invalid > and the compiler turns off the checks by default, that's disappointing. AFAIK, wrapping integers is invalid in Ada. You have to jump through hoops to get wrapv behavior in Ada. > Optionally disabling the checks is fine, with the programmer explicitly > taking responsibility. Yes. >> Because that way, the code is way faster (into is a precise exception, >> which is costly, and since no big code- base uses into, Intel just >> doesn't care about performance). > > That seems like an x86 hardware deficiency. Anton mentioned ADD on MIPS > processors has an overflow exception. That should really be the default. They cause a significant slowdown on MIPS as well. This stuff does not work together with OoO Execution. You have a limited amount of resources for precise exceptions, and those are usually all used up by the loads and stores. >> Apparently he's on the side of the compiler makers who make compilers >> which break code for no good reasons other than language lawyering >> somehow "allowed" them to do it. > > The other reason is that it makes non-buggy programs run faster, which > matters to a lot of important C users. I do think those users > overestimated their own ability to avoid such bugs, but this is a lesson > from decades of hindsight. I don't think there is a real-world case where this optimization made a program run faster and not go against the intention of the author. The Linux kernel certainly was faster after all these NULL-checks were eliminated, but it was broken. It's like ICC managed to compile SPEC code faster, because the code was broken, but this didn't show up with the limited test cases. >> Actually, I think, dead code eliminination should issue a warning in any >> case, unless you explicitely mark a block as "maybe dead". > > Hmm, maybe, though some other situations like that can be hard to > detect, and various sorts of automatically generated code can have dead > code. A pragma or compiler flag could turn off the warning though. Yes. >>>> We have a significant reliability problem in software. ... The >>>> attitude of compiler writer to optimize code based on "undefined >>>> behavior" of the language standard is part of the problem. > > I'm really not so convinced of that... let's imagine GCC by default > doesn't optimize away those checks even with -O3, but it has a separate > flag "-fultra-aggressive" which eliminates the checks, making code > that's a few percent faster, if you explicitly ask for that. Do you > think developers whose applications have to compete on benchmarks are > going to resist enabling the flag? It amounts to an admission that they > think their code is buggy. Most code is not even compiled with -O3, the "sane" level you compile your code with is normally -O2. There's a long history of disabling too aggressive optimizations, because the compiler might miscompile the code, and conservative people actually do compile unoptimized. Google delivered the whole NDK toolchain compiled unoptimized for some time, until they figured out that GCC is probably fine when compiled with the GCC maintainer's choice of optimization, which is -O2. >> If you had your compiler wrapv for 20 years, it is going to stay >> wrapv. There is no point to change that, it will break code and >> customers will be angry. > > That code is already broken. The way math works, adding two positive > integers always results in another positive integer. It is not an integer. The C types are called "int", but they are *not* Z. There are languages where the integer type is implemented as bignums, i.e. really is Z. C's model is that each primitive data type takes a fixed size of computer memory. > If your program > uses integers that accidentally break that invariant by no longer > fitting in the machine representation, it will get nonsense results, > i.e. it is broken. If it breaks the invariant on purpose, you should > announce that intention by choosing an unsigned type. The two's complement wrapv style type makes sense both as signed and unsinged type. It's just not Z and N0. And it's also not GF(2^n). >> [Ada] is one of those BDSM languages, I wouldn't touch it. > > It's verbose but doesn't really look worse than Java in that regard. > I'm not sure what the alternatives are for embedded programming, given > the terrible behavior of C programs as we're discussing. The checks > that you get with Ada tools are similar to the ones you described using > for Verilog. No, you are confusing things. Ada implements checks on stuff where the machine differs from the mental model of the language, like overflow. Verilog does not have a difference between the machine and the mental model, and therefore, if x+1 wraps around, it just wraps around. And AFAIK, you don't have Ada tools to prove that your compiler generated code that is identical to your source code. The formal verification tools you have for Ada do something entirely different. > Why shouldn't a software programmer want similar levels of > checking, if the application is intolerant enough of errors that it's > worth slowing down the coding process by a nontrivial factor to prevent > them? (Most of my own day-to-day stuff is more error-tolerant, so I > code it quickly in Python and fix problems as they occur, but I wouldn't > use Python for a critical app). > >> Large programs are a problem, and writing large programs is *wrong*. > > In the real world, people often want stuff from computers that can't be > done with small programs, but can sometimes be done with large programs, > so the large programs get written. If you ever do a Google search, > there's a monstrous amount of code running it behind the scenes. Yes, but you forgot that there is an awful lot of accidental complexity in this program, complexity that got accumulated over time, but that is *not* necessary to do the job. If you have 1000 programmers working on a piece of code for 10 years, you get a big program. It doesn't mean it has to be that big, it just is that big, because there are a lot of redundancies created by cut&paste programming. Think of this like the genome of a lungfish: it has 133 billion base pairs. That is an awful lot more than we humans do (3 billion base pairs). The difference is that the lung fish has many duplicated and slightly modified genes, which are optimized to different temperatures (amphibs have the same sort of thing, but the size is already significantly reduzed compared to this ancestor). Mammals have found a different solution: they just keep their temperature constant, and therefore don't need these duplicates. > Same > thing if you use the speech recognition on a recent mobile phone (the > phone cpu is not powerful enough, so the application sends the audio > stream to a server farm that does the actual decoding and content > analysis). Actually, speech recognition works quite well on-device. It just depends on the programmers. You are ignoring the accidential complexity factor. > Self-driving cars are appearing on the roads, and may reach > a point where they're safer than cars driven by humans, etc. It won't > be small programs doing that. They are already safer than cars driven by humans, and the number of people working on this project at Google is way smaller than the search engine team (this is a "hobby" of a few guys at Google, and Google pays them for doing this research). I'm quite sure the program is much smaller than you think. The trick of Google's self-driving cars are the sensors. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-22 21:29 -0800 |
| Message-ID | <7xy51275wq.fsf@ruckus.brouhaha.com> |
| In reply to | #28698 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Get you head out of the C standard. Of course C code compiles to some real
> machine. And there, it does have a precise semantics.
Think of a Lisp-like language that reserves some bits in the machine
word to use as type tags. So there are some bit combinations that are
valid machine addresses but will never be used as actual pointers in the
compiler output, since the tag bits signify that they're other kinds of
data. Therefore the garbage collector never has to worry about whether
something can be pointed to by such a word. If that invariant is
broken, the program can go off into the weeds, so the program has to be
written to never let that happen. The semantics of machine words are
overloaded compared to assembly code. It's the same way with null
pointers in C.
> No, why? The standard is a compromise between compilers who target an 8051
> and compilers who target AS/400.
Historically more like Vax vs Cray, I think.
> Sorry, I think you have been dragged away. The problem with this code is
> that the behavior of dereferencing s->x is undefined, and may or may not
> result in a segv violation (the compiler can't know). Because it can't
> know, it can't know that the check for if(!s) is unreachable.
But it doesn't need to know. There are two possibilities:
1) s is null => result is undefined, compiler has no obligation
to do anything in particular. Program can go into the weeds
(nondeterministcally) just like with any other OOB memory reference.
2) s is not null => the if(!s) will always succeed, so it is redundant.
> You can't get both: undefined behavior and being able to optimize things
> away.
Non-sequitur. I could see a case for enabling a compiler guarantee that
the dereference will always trap, if some flag is set (maybe by
default). But, I think people will turn off that flag once they think
their code works and they want maximum optimization.
> We have ambiguous conditons, which mean that the implementation may or may
> not define the behavior; these are conditions where we don't want to enforce
> a particular implementation,
So this is like null pointer dereferences in C. Now we're just haggling
about the price ;-).
>> Undefined is more like what happens in Forth if you say "+" with nothing
>> on the stack (unless the Forth standard specifies this should give an
>> underflow exception ...).
> The exceptions are optional, therefore we can't mandate it to throw an
> exception.
So what happens? Do implementers have to assume the worst?
>> Anton mentioned ADD on MIPS processors has an overflow exception.
>> That should really be the default.
> They cause a significant slowdown on MIPS as well... You have a
> limited amount of resources for precise exceptions
Is an imprecise exception so bad? Those happen with floating point
operations, I think.
> I don't think there is a real-world case where this optimization made a
> program run faster and not go against the intention of the author.
This seems speak mostly about the mistaken egotism of the C programmers
who thought they could always write what they intended.
>>> If you had your compiler wrapv for 20 years, it is going to stay
>>> wrapv. There is no point to change that, it will break code and
>>> customers will be angry.
Was wrapv-by-default actually documented in the GCC manual? Did anyone
depend on it? I think if a deterministic overflow is desired, trapv
would be better than wrapv: code that relies on wrapv without specifying
it explicitly has high chance of being wrong.
>> adding two positive integers always results in another positive integer.
> It is not an integer. The C types are called "int", but they are *not* Z.
> There are languages where the integer type is implemented as bignums, i.e.
> really is Z.
Z is infinite. Bignums are the tiny subset of Z that fit in the
computer's memory, but if your program starts using integers overflow
for memory, it can thrash, crash, or do other nasty things. Programs
that do that are wrong. Ints are the even tinier subset of Z that fit
in a single machine word so they can use efficient hardware arithmetic.
Programs whose ints overflow the machine words are also wrong. I'd say
the right behavior for (unannotated) int overflow is trapv, and it's a
pervasive enough problem that good hardware (which I guess doesn't
exist) should make trapv basically cost-free.
> The two's complement wrapv style type makes sense both as signed and
> unsinged type. It's just not Z and N0. And it's also not GF(2^n).
Really there should be separate types for wrapping and trapping, for
both signed and unsigned.
> Verilog does not have a difference between the machine and the mental model,
> and therefore, if x+1 wraps around, it just wraps around.
This I don't understand: Verilog is a hardware design language, the
compiler output IS the machine, and the user program literally defines
what the machine does. Why should it always wrap around rather than
saturate or trap?
>> If you ever do a Google search, there's a monstrous amount of code
>> running it behind the scenes.
> Yes, but you forgot that there is an awful lot of accidental complexity in
> this program,
There might be a billion LOC in there. Following Chuck Moore's claim of
1000:1, perhaps you can cook it down to a million LOC. That's still an
awful lot.
> Think of this like the genome of a lungfish: it has 133 billion base pairs.
> That is an awful lot more than we humans do (3 billion base pairs).
Interesting.
> Actually, speech recognition works quite well on-device. It just depends on
> the programmers. You are ignoring the accidential complexity factor.
There's a huge amount of data involved. Like you can tell your phone to
direct you to the nearest barber shop. The app has to recognize the
words, figure out the natural language semantics, then use the phone's
GPS to find your current location, then consult a map database and a
business directory, etc. Last I heard, that was all done on servers,
but I don't pay close attention, I don't use that type of phone.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-23 22:33 +0100 |
| Message-ID | <ledpee$pos$1@online.de> |
| In reply to | #28704 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Get you head out of the C standard. Of course C code compiles to some >> real >> machine. And there, it does have a precise semantics. > > Think of a Lisp-like language that reserves some bits in the machine > word to use as type tags. So there are some bit combinations that are > valid machine addresses but will never be used as actual pointers in the > compiler output, since the tag bits signify that they're other kinds of > data. Therefore the garbage collector never has to worry about whether > something can be pointed to by such a word. If that invariant is > broken, the program can go off into the weeds, so the program has to be > written to never let that happen. The semantics of machine words are > overloaded compared to assembly code. It's the same way with null > pointers in C. A Lisp-like language is quite far away from the machine code. It's not a language to write close-to-the-machine stuff. C was designed to write operating systems and similar close-to-the-machine stuff. You can't compare apples and bananas like this. >> No, why? The standard is a compromise between compilers who target an >> 8051 and compilers who target AS/400. > > Historically more like Vax vs Cray, I think. The C standard had a pretty recent update. The extremes are quite likely those I mentioned. Historically, C was K&R's baby, running on a PDP-11. >> Sorry, I think you have been dragged away. The problem with this code is >> that the behavior of dereferencing s->x is undefined, and may or may not >> result in a segv violation (the compiler can't know). Because it can't >> know, it can't know that the check for if(!s) is unreachable. > > But it doesn't need to know. There are two possibilities: > 1) s is null => result is undefined, compiler has no obligation > to do anything in particular. We are talking about a quality implementation. In Forth, we have a lot of "an ambiguous condition exists if bla". All quality implementations try to map these ambiguous conditions to deterministic behavior, usually throwing some exception. > Program can go into the weeds > (nondeterministcally) just like with any other OOB memory reference. > 2) s is not null => the if(!s) will always succeed, so it is redundant. > >> You can't get both: undefined behavior and being able to optimize things >> away. > > Non-sequitur. I could see a case for enabling a compiler guarantee that > the dereference will always trap, if some flag is set (maybe by > default). But, I think people will turn off that flag once they think > their code works and they want maximum optimization. Not for an OS, where the caller of this code is in userland, and therefore potentially malicious. >> We have ambiguous conditons, which mean that the implementation may or >> may not define the behavior; these are conditions where we don't want to >> enforce a particular implementation, > > So this is like null pointer dereferences in C. Now we're just haggling > about the price ;-). The reason why we want to leave these decisions to the implementers is that there are tradeoffs. A small system in 8k of Flash can't implement everything. However, I expect that a quality system fills these holes with live, in a way that supports the user of the compiler. And they actually do. >>> Undefined is more like what happens in Forth if you say "+" with nothing >>> on the stack (unless the Forth standard specifies this should give an >>> underflow exception ...). >> The exceptions are optional, therefore we can't mandate it to throw an >> exception. > > So what happens? Do implementers have to assume the worst? The implementer is in charge for the tradeoffs. Does he want a minimal system on a small controller, or does he want a desktop system which supports million lines of code and mission critical applications? I don't have the impression the Forth implementers have difficulties to find the right tradeoffs. >>> Anton mentioned ADD on MIPS processors has an overflow exception. >>> That should really be the default. >> They cause a significant slowdown on MIPS as well... You have a >> limited amount of resources for precise exceptions > > Is an imprecise exception so bad? Those happen with floating point > operations, I think. It's the typical benchmark thing: Implementer check what's used frequently, and implement the infrequent stuff less aggressive. >> I don't think there is a real-world case where this optimization made a >> program run faster and not go against the intention of the author. > > This seems speak mostly about the mistaken egotism of the C programmers > who thought they could always write what they intended. Just yesterday, Apple issued an update to their SSL bug. The culprit is just what we are discussion here: They rendered the final check on an SSL connection setup into dead code, by having duplicated line in a statement: if(err = somecheck(...)) goto fail; goto fail; if(err = finalcheck(...)) goto fail; ... So the final check never was done. Optimizing it away, even though that was by C's semantics the expressed intention of the programmer, was very harmful. >>>> If you had your compiler wrapv for 20 years, it is going to stay >>>> wrapv. There is no point to change that, it will break code and >>>> customers will be angry. > > Was wrapv-by-default actually documented in the GCC manual? Did anyone > depend on it? Yes. A lot of code depends on it, so much that the GCC maintainers had added a -fwrapv flag to support it. > I think if a deterministic overflow is desired, trapv > would be better than wrapv: code that relies on wrapv without specifying > it explicitly has high chance of being wrong. No. People have thought in wrapv semantics for decades; everyone with an assembler background knows that by heart. >>> adding two positive integers always results in another positive integer. >> It is not an integer. The C types are called "int", but they are *not* >> Z. There are languages where the integer type is implemented as bignums, >> i.e. really is Z. > > Z is infinite. Bignums are the tiny subset of Z that fit in the > computer's memory, Indeed, but all programs that run on computers are limited by the computer's memory. Bignums are the best approximation to Z you can get. >> The two's complement wrapv style type makes sense both as signed and >> unsinged type. It's just not Z and N0. And it's also not GF(2^n). > > Really there should be separate types for wrapping and trapping, for > both signed and unsigned. Yes, this is something I can agree on. VHDL has those, and all sane VHDL designers I know use the wrapping ones. If you use the trapping ones, your code is very likely wrong (I've seen that, one of my coworker used the trapping ones, and we ran into trap after trap, and each of them was a bug). >> Verilog does not have a difference between the machine and the mental >> model, and therefore, if x+1 wraps around, it just wraps around. > > This I don't understand: Verilog is a hardware design language, the > compiler output IS the machine, and the user program literally defines > what the machine does. Why should it always wrap around rather than > saturate or trap? Because wrap around is the straight-forward hardware implementation. Saturation requires an additional check+multiplexer, and trap is completely impossible. It is hardware, there is no exception handler. >>> If you ever do a Google search, there's a monstrous amount of code >>> running it behind the scenes. >> Yes, but you forgot that there is an awful lot of accidental complexity >> in this program, > > There might be a billion LOC in there. Following Chuck Moore's claim of > 1000:1, perhaps you can cook it down to a million LOC. That's still an > awful lot. When I do a random google search, the result is done in less than a second. I would be surprised if your average search touches significantly more than 10k lines of code. Yes, there's also the web crawling and index building in the background, but that needs good performance, too. >> Think of this like the genome of a lungfish: it has 133 billion base >> pairs. That is an awful lot more than we humans do (3 billion base >> pairs). > > Interesting. > >> Actually, speech recognition works quite well on-device. It just depends >> on >> the programmers. You are ignoring the accidential complexity factor. > > There's a huge amount of data involved. Like you can tell your phone to > direct you to the nearest barber shop. The app has to recognize the > words, figure out the natural language semantics, then use the phone's > GPS to find your current location, then consult a map database and a > business directory, etc. Last I heard, that was all done on servers, > but I don't pay close attention, I don't use that type of phone. Google AFAIK splits things up. It can recognize a number of typical search keywords (like "where's the next") right in the phone, and sends some others to Google's server. This is, as usual, a tradeoff thing. Compared to Samsung Voice, it's much faster, and the result is more up to the point. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-23 22:13 -0800 |
| Message-ID | <7xsir9hwbh.fsf@ruckus.brouhaha.com> |
| In reply to | #28720 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> C was designed to write operating systems and similar
> close-to-the-machine stuff. You can't compare apples and bananas like
> this.
I think we heard similar things when C compilers started optimizing
x = *z;
y = *z;
to copy x to y with a register-register move instead of dereferencing z
twice ("it's a low level language and z might point to a device
register"). The volatile keyword was added to deal with that
possibility but in the normal case the optimization is fine.
>> Historically more like Vax vs Cray, I think.
> The C standard had a pretty recent update. The extremes are quite likely
> those I mentioned. Historically, C was K&R's baby, running on a PDP-11.
And various C programmers from the K&R era felt about the same way
towards ANSI C as Chuck does towards ANS Forth.
> In Forth, we have a lot of "an ambiguous condition exists if bla".
> All quality implementations try to map these ambiguous conditions to
> deterministic behavior, usually throwing some exception.
Is that the right thing for an optimizing compiler? If the programmer
says SWAP then they are asserting the stack has at least two items. If
there aren't, the code is buggy no matter what the compiler does.
Should the compiler slow the code down by checking anyway, if the
optimization level is cranked all the way up? I wouldn't have thought
that was in the Forth spirit. Look at all these crashes, and these are
in interpreters:
http://thebeez.home.xs4all.nl/4tH/crash.htm
> Not for an OS, where the caller of this code is in userland, and
> therefore potentially malicious.
All the more reason to write the code carefully. (Though since when
does userland pass pointers into the kernel).
> The implementer is in charge for the tradeoffs. Does he want a
> minimal system on a small controller, or does he want a desktop system
> which supports million lines of code and mission critical
> applications?
Unfortunately it's the second user (or one with a megawatt-burning
server farm) that wants the optimizations cranked to 11.
>> Is an imprecise exception so bad?
> It's the typical benchmark thing: Implementer check what's used frequently,
> and implement the infrequent stuff less aggressive.
But we keep hearing that CPU designers now have more transistors than
they know how to use. These checks are important for reliable code, and
benchmark-crazed programmers aren't going to let the compilers put in
the checks. So it's best if the hardware does it, with no overhead.
That makes use of the extra transistors and keeps the programmers happy.
> if(err = somecheck(...))
> goto fail;
> goto fail;
Oops. Yes a compiler might of flagged that, but there are other types
of bugs that (while catchable) are expensive enough to catch that it's
more practical to delegate them to an external tool. Those tools are
getting more available and they're quite effective, and it's pretty
disappointing for a rich corporation like Apple to not be using them.
>> Was wrapv-by-default actually documented in the GCC manual? Did anyone
>> depend on it?
>
> Yes. A lot of code depends on it,
Do you mean yes it was documented in the manual? Or just that people
relied on it? The latter is easy to believe but the former is a little
bit surprising.
>> trapv would be better than wrapv
> No. People have thought in wrapv semantics for decades; everyone with an
> assembler background knows that by heart.
Trapv would flush out those dependencies pretty quickly during any
reasonable testing, I'd hope. Then the code could be patched.
I rather like the AIR proposal that I linked earlier:
> (I've seen that, one of my coworker used the [VHDL] trapping ones, and
> we ran into trap after trap, and each of them was a bug).
You mean the traps were catching unintentional overflows? That means
they were doing their job, of flagging bugs. Or do you mean that the
application actually wanted wraparound. Maybe that sort of thing is
more common in hardware than in programs other than low level bit
twiddling code.
> When I do a random google search, the result is done in less than a second.
> I would be surprised if your average search touches significantly more than
> 10k lines of code.
Someone once told me what happens when you send a search query and it's
a stupendous amount of computation and lookups, that are run across
100's of machines.
[toc] | [prev] | [next] | [standalone]
Page 8 of 21 — ← Prev page 1 … 6 7 [8] 9 10 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web