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 7 of 21 — ← Prev page 1 … 5 6 [7] 8 9 … 21 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-10 12:14 -0600 |
| Message-ID | <rY-dndZnjOuDimTPnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #28300 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> >>>>>For example, >>>>here is EXECUTE1: >>>> >>>>( 080BFE40 83FB7F ) CMP EBX, 7F >>>>( 080BFE43 0F8606000000 ) JBE/NA 080BFE4F >>>>( 080BFE49 BB06000000 ) MOV EBX, 00000006 >>>>( 080BFE4E C3 ) NEXT, >>>>( 080BFE4F C1E302 ) SHL EBX, 02 >>>>( 080BFE52 8B93B0FB0B08 ) MOV EDX, [EBX+080BFBB0] >>>>( 080BFE58 8B5D00 ) MOV EBX, [EBP] >>>>( 080BFE5B 8D6D04 ) LEA EBP, [EBP+04] >>>>( 080BFE5E FFD2 ) CALL EDX >>>>( 080BFE60 C3 ) NEXT, >>>> >>>>As you can see, this ends with a call followed by a return. >>> >>> AFAIK that's intentional to support return address manipulation. >> >>Sure, but that behaviour isn't required by the Forth language, > > It is required by the Forth language as supported by VFX. I suppose so; but that is not *the* Forth language. Not yet, anyway. :-) > Fortunately the GCC disease of miscompiling all non-standard code > (except SPEC benchmarks) has not spread to Forth yet. [ Maybe I ought to have a STD_DISCLAIMER of the form "When Anton inserts an irrelevant GCC flame into a discussion, I'm going to ignore him. It's a pointless provocation and leads only to flame wars." ] Anyway, this language "feature" means that VFX can't do tail call elimination, a very simple optimization that was available way back in cmFORTH. This fact casts some doubt upon your performance comparison. I don't think that it's likely to be a huge difference, but it is likely to be significant. >>and it means that we're not comparing other versions of this code >>with a straightforward jump table. > > Whatever that may be. It would be more straightforward without a CALL and RET. > BTW, what may (or may not) make the IF-based variants look better than > the EXECUTE-based variant is that the words .LOWER etc. are inlined in > the IF-based variants, but not in the EXECUTE-based variant. Indeed, I have noticed that, but I think it's typical of what a compiler would do in real code. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-02-10 22:38 +0000 |
| Message-ID | <52f95386.555836101@news.demon.co.uk> |
| In reply to | #28301 |
On Mon, 10 Feb 2014 12:14:54 -0600, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Anyway, this language "feature" means that VFX can't do tail call >elimination, a very simple optimization that was available way back >in cmFORTH. This fact casts some doubt upon your performance >comparison. I don't think that it's likely to be a huge difference, >but it is likely to be significant. As Anton has pointed out, VFX *chooses* not to do tail call elimination. We could do it, but the demand is not there. We have, however, been thanked for not doing it as other traditional Forth techniques such as return stack manipulation are simple to implement in VFX. The only safe way to do tail call elimination is to have a switch to disable it. I'm becoming less and less interested in the last few nanoseconds. Reliability is good. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-11 03:46 -0600 |
| Message-ID | <Wr2dndjFkeESbGTPnZ2dnUVZ_hKdnZ2d@supernews.com> |
| In reply to | #28304 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Mon, 10 Feb 2014 12:14:54 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>Anyway, this language "feature" means that VFX can't do tail call >>elimination, a very simple optimization that was available way back >>in cmFORTH. This fact casts some doubt upon your performance >>comparison. I don't think that it's likely to be a huge difference, >>but it is likely to be significant. > > As Anton has pointed out, VFX *chooses* not to do tail call > elimination. We could do it, but the demand is not there. We have, > however, been thanked for not doing it as other traditional Forth > techniques such as return stack manipulation are simple to > implement in VFX. Well, yes, I know, and so does everyone else who read our last discussion about this. I don't particularly want to revisit it. > The only safe way to do tail call elimination is to have a switch to > disable it. That'd be useful for this benchmark, but maybe not for anything else. > I'm becoming less and less interested in the last few nanoseconds. But the subject of this discussion is the last few nanoseconds: that's all we're talking about now. > Reliability is good. And reliability is enhanced by return stack manipulation. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-02-11 10:30 +0000 |
| Message-ID | <52f9fb81.598838775@news.demon.co.uk> |
| In reply to | #28306 |
On Tue, 11 Feb 2014 03:46:55 -0600, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> Reliability is good. > >And reliability is enhanced by return stack manipulation. Explain and point to proof, please. Otherwise, that's just handwaving. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-11 18:24 -0600 |
| Message-ID | <o6ydne0RjaHSImfPnZ2dnUVZ_rudnZ2d@supernews.com> |
| In reply to | #28309 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Tue, 11 Feb 2014 03:46:55 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>> Reliability is good. >> >>And reliability is enhanced by return stack manipulation. > > Explain and point to proof, please. Otherwise, that's just > handwaving. Proof of what? What proof did you provide? I presume that when you said "Reliability is good" it had some relevance to the rest of the posting. Did it not? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-12 15:02 +0000 |
| Message-ID | <52fb8d00$0$9256$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #28306 |
In article <Wr2dndjFkeESbGTPnZ2dnUVZ_hKdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Stephen Pelc <stephenXXX@mpeforth.com> wrote: >> On Mon, 10 Feb 2014 12:14:54 -0600, Andrew Haley >> <andrew29@littlepinkcloud.invalid> wrote: >> >>>Anyway, this language "feature" means that VFX can't do tail call >>>elimination, a very simple optimization that was available way back >>>in cmFORTH. This fact casts some doubt upon your performance >>>comparison. I don't think that it's likely to be a huge difference, >>>but it is likely to be significant. >> >> As Anton has pointed out, VFX *chooses* not to do tail call >> elimination. We could do it, but the demand is not there. We have, >> however, been thanked for not doing it as other traditional Forth >> techniques such as return stack manipulation are simple to >> implement in VFX. > >Well, yes, I know, and so does everyone else who read our last >discussion about this. I don't particularly want to revisit it. > >> The only safe way to do tail call elimination is to have a switch to >> disable it. > >That'd be useful for this benchmark, but maybe not for anything else. > >> I'm becoming less and less interested in the last few nanoseconds. > >But the subject of this discussion is the last few nanoseconds: that's >all we're talking about now. > >> Reliability is good. > >And reliability is enhanced by return stack manipulation. You know very well what he means. Overall there will be less surprises with VFX, in this case from the people who use stack manipulation, or use a package from some-one who does. In real life it is little use to tell your clients : "You shouldn't have..." > >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-12 11:23 -0600 |
| Message-ID | <i66dnVD_5cpqMGbPnZ2dnUVZ_tydnZ2d@supernews.com> |
| In reply to | #28332 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <Wr2dndjFkeESbGTPnZ2dnUVZ_hKdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Stephen Pelc <stephenXXX@mpeforth.com> wrote: >> >>> I'm becoming less and less interested in the last few nanoseconds. >> >>But the subject of this discussion is the last few nanoseconds: that's >>all we're talking about now. >> >>> Reliability is good. >> >>And reliability is enhanced by return stack manipulation. > > You know very well what he means. Overall there will be less surprises > with VFX, in this case from the people who use stack manipulation, > or use a package from some-one who does. > In real life it is little use to tell your clients : > "You shouldn't have..." Sure, I am happy to believe that it makes perfect commercial sense to support return address manipulation. It is a bit of a stretch to invoke reliability in support of it, though. Colour me skeptical. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-13 09:25 +0000 |
| Message-ID | <2014Feb13.102556@mips.complang.tuwien.ac.at> |
| In reply to | #28336 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Sure, I am happy to believe that it makes perfect commercial sense to
>support return address manipulation. It is a bit of a stretch to
>invoke reliability in support of it, though. Colour me skeptical.
A reliable compiler does not silently miscompile a program that works
perfectly fine on the previous version of the compiler.
- 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-13 04:54 -0600 |
| Message-ID | <z-mdnVgtVLrEOWHPnZ2dnUVZ_q2dnZ2d@supernews.com> |
| In reply to | #28372 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Sure, I am happy to believe that it makes perfect commercial sense to >>support return address manipulation. It is a bit of a stretch to >>invoke reliability in support of it, though. Colour me skeptical. > > A reliable compiler does not silently miscompile a program that > works perfectly fine on the previous version of the compiler. This is an utterly ludicrous claim. It means that any effect of a compiler, even if caused by an error in that compiler, has to be preserved forever if it makes one nonstandard (and, formally speaking, undefined) program work as its author expected. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-13 13:41 +0000 |
| Message-ID | <2014Feb13.144124@mips.complang.tuwien.ac.at> |
| In reply to | #28376 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> A reliable compiler does not silently miscompile a program that
>> works perfectly fine on the previous version of the compiler.
>
>This is an utterly ludicrous claim. It means that any effect of a
>compiler, even if caused by an error in that compiler, has to be
>preserved forever if it makes one nonstandard (and, formally speaking,
>undefined) program work as its author expected.
Yes, preserving effects is the cost of staying compatible, and serious
software infrastructure providers pay these costs in order to provide
a stable environment. What does it say about someone when they call
that ludicrous? Will they rename XOR to OR next? Or will they
"optimize" counted loops into endless loops?
Of course, there are ways to phase out features that one no longer
wants to support. First, document that it is going away in the
future. Then provide a way to turn the new behaviour on. Next, warn
about the use of the old feature. Then, many years later, give an
error message, but with some way to get the old behaviour back. But
silently miscompiling previously working programs is not the way to
inspire confidence into the compiler, nor to encourage programmers to
switch to the new one.
- 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-13 14:14 +0000 |
| Message-ID | <52fcd333$0$24940$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #28381 |
In article <2014Feb13.144124@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> A reliable compiler does not silently miscompile a program that >>> works perfectly fine on the previous version of the compiler. >> >>This is an utterly ludicrous claim. It means that any effect of a >>compiler, even if caused by an error in that compiler, has to be >>preserved forever if it makes one nonstandard (and, formally speaking, >>undefined) program work as its author expected. > >Yes, preserving effects is the cost of staying compatible, and serious >software infrastructure providers pay these costs in order to provide >a stable environment. What does it say about someone when they call >that ludicrous? Will they rename XOR to OR next? Or will they >"optimize" counted loops into endless loops? > >Of course, there are ways to phase out features that one no longer >wants to support. First, document that it is going away in the >future. Then provide a way to turn the new behaviour on. Next, warn >about the use of the old feature. Then, many years later, give an >error message, but with some way to get the old behaviour back. But >silently miscompiling previously working programs is not the way to >inspire confidence into the compiler, nor to encourage programmers to >switch to the new one. That's ideal. When it comes to a product that is supported by a single implementor, it is acceptable -- or so I hope -- that new features are renamed, old features do not compile. Then document that at the users discretion an old version is still available. In the current example of removing the possibility of return stack manipulation, I would thread very carefully. Probably I would rename the compiler, such as to douse any hopes that programs should run, and force them to be ported instead. Anyone not paying attention to the non-portable stack manipulation while porting is a simpleton, and gets what they deserve. 1] Anyway arguing that return stack manipulations just shouldn't take place is fruitless. >- anton 1] I like that word: simpleton, from reading Jane Austen's Pride and Prejudice. Hope it is not too offensive. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-13 08:41 -0600 |
| Message-ID | <g4ydncrEzJcyRGHPnZ2dnUVZ_hGdnZ2d@supernews.com> |
| In reply to | #28381 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> A reliable compiler does not silently miscompile a program that >>> works perfectly fine on the previous version of the compiler. >> >>This is an utterly ludicrous claim. It means that any effect of a >>compiler, even if caused by an error in that compiler, has to be >>preserved forever if it makes one nonstandard (and, formally speaking, >>undefined) program work as its author expected. > > Yes, preserving effects is the cost of staying compatible, and > serious software infrastructure providers and their users > pay these costs in order to provide a stable environment. We shall simply have to agree to differ. It means that no optimization that can possibly affect a program, whether that program is well-defined or not, can ever be made. This even includes optimizations whose only effect is to speed up a program, because timing can affect the output of a badly-written program. So no optimzation may ever be done. I think that this is a hopelessly idealistic (not to say naive) view. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-13 15:29 +0000 |
| Message-ID | <2014Feb13.162903@mips.complang.tuwien.ac.at> |
| In reply to | #28384 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>It means that no optimization that can possibly affect a program,
>whether that program is well-defined or not, can ever be made. This
>even includes optimizations whose only effect is to speed up a
>program, because timing can affect the output of a badly-written
>program.
On a platform that totally defines every part of the hardware and the
software, and there are no outside influences, maybe some software
relies on the timing not changing, and in this case keeping the timing
the same may be advisable for a stable platform. OTOH, all changes
may affect some timings (e.g., having more words will change the
timing of dictionary searches), so if someone write such a program,
they will probably stay with the same version of the Forth system
anyway.
But for the platforms I work with, timing is influenced by so many
things (e.g., other processes polluting the caches and branch
predictors), that programmers do not write programs that rely on the
exact timings of code, and if they did, the programs would not work
anyway.
But otherwise, yes, proper optimizations do not silently change the
behaviour of programs.
A more relevant case is reading uninitialized data. That may lead to
one behaviour in one version of a Forth system and a different
behaviour in the next version, even if the optimizations in these
versions do not differ. Again, if a program intentionally relies on
that, it is probably best of sticking with one version. For the
system it's a good idea to initialize data (at least optionally), to
allow to initialize it in several ways (to support the programmer to
find the problem in testing), and ideally to have tools for finding
the reads of uninitialized data.
>So no optimzation may ever be done.
>
>I think that this is a hopelessly idealistic (not to say naive) view.
Sure, you put up an unrealistic straw man.
But the approach "miscompile non-standard programs silently" leads to
people turning off "optimization", or (if that option exists) getting
rid of the unreliable compiler.
I recently heard a talk at HiPEAC, where the presenter said that ISVs
don't turn on optimization, because they are blamed if the program
does not behave as it should, whereas binary optimization apparently
has a better reputation. My guess is that's because the binary
optimizer preserves the binary's behaviour (which is defined much more
tightly than some programming languages) instead of miscompiling the
program based on language lawyering of a weakly defined standard.
- 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-13 12:07 -0600 |
| Message-ID | <Z-KdndiCNZdAlGDPnZ2dnUVZ_jidnZ2d@supernews.com> |
| In reply to | #28385 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>It means that no optimization that can possibly affect a program, >>whether that program is well-defined or not, can ever be made. This >>even includes optimizations whose only effect is to speed up a >>program, because timing can affect the output of a badly-written >>program. > > On a platform that totally defines every part of the hardware and the > software, and there are no outside influences, maybe some software > relies on the timing not changing, and in this case keeping the timing > the same may be advisable for a stable platform. OTOH, all changes > may affect some timings (e.g., having more words will change the > timing of dictionary searches), so if someone write such a program, > they will probably stay with the same version of the Forth system > anyway. > > But for the platforms I work with, timing is influenced by so many > things (e.g., other processes polluting the caches and branch > predictors), that programmers do not write programs that rely on the > exact timings of code, and if they did, the programs would not work > anyway. I have certainly seen race conditions that were exposed when an optimization speeded up part of the code. Of course, the compiler was blamed for "breaking the program", but all it did was make part of the program go faster. > But otherwise, yes, proper optimizations do not silently change the > behaviour of programs. > A more relevant case is reading uninitialized data. That may lead to > one behaviour in one version of a Forth system and a different > behaviour in the next version, even if the optimizations in these > versions do not differ. Again, if a program intentionally relies on > that, it is probably best of sticking with one version. So, a "proper optimization" is allowed to change the behaviour of a program that worked because uninitialized data had a particular value. Is that right or not? But you said that: >>> A reliable compiler does not silently miscompile a program that >>> works perfectly fine on the previous version of the compiler. > For the system it's a good idea to initialize data (at least > optionally), to allow to initialize it in several ways (to support > the programmer to find the problem in testing), and ideally to have > tools for finding the reads of uninitialized data. > >>So no optimzation may ever be done. >> >>I think that this is a hopelessly idealistic (not to say naive) view. > > Sure, you put up an unrealistic straw man. I am trying to turn what you wrote into something that makes sense. The only way I can do that is follow its logical implications, wherever they may lead. By "miscompile" I understood "generate code that does something different". But now I see that for you "miscompile" doesn't mean that. It seems to mean "doesn't do any optimization that would surprise me." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-15 16:14 +0000 |
| Message-ID | <2014Feb15.171430@mips.complang.tuwien.ac.at> |
| In reply to | #28386 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> But for the platforms I work with, timing is influenced by so many
>> things (e.g., other processes polluting the caches and branch
>> predictors), that programmers do not write programs that rely on the
>> exact timings of code, and if they did, the programs would not work
>> anyway.
>
>I have certainly seen race conditions that were exposed when an
>optimization speeded up part of the code.
Yes, can happen.
>Of course, the compiler was
>blamed for "breaking the program", but all it did was make part of the
>program go faster.
Well if a compiler's optimizer has miscompiled before, that's what one
tends to think of when an optimization changes the behaviour.
>> But otherwise, yes, proper optimizations do not silently change the
>> behaviour of programs.
>
>> A more relevant case is reading uninitialized data. That may lead to
>> one behaviour in one version of a Forth system and a different
>> behaviour in the next version, even if the optimizations in these
>> versions do not differ. Again, if a program intentionally relies on
>> that, it is probably best of sticking with one version.
>
>So, a "proper optimization" is allowed to change the behaviour of a
>program that worked because uninitialized data had a particular value.
>Is that right or not?
That's a judgement call, that's why I brought it up.
>But you said that:
>
>>>> A reliable compiler does not silently miscompile a program that
>>>> works perfectly fine on the previous version of the compiler.
Yes. And that's the attitude one should employ when writing an optimizer.
There are some things that pretty much preclude optimization (and also
preclude most other changes in the compiler). One example is if the
timing has to be kept the same as in the unoptimized case. In this
case it's obvious that the only option is not to optimize. But the
compiler already does that by not turning on optimization, so an
optimizer does not need to cater for that particular case. The only
problem with this is if the programmer is unaware that his program
depends on the exact timing (as in the case reported above).
I think that depending on uninitialized data is pretty much in the
same category of things that preclude most changes in the compiler.
But I might be wrong.
>By "miscompile" I understood "generate code that does something
>different". But now I see that for you "miscompile" doesn't mean
>that. It seems to mean "doesn't do any optimization that would
>surprise me."
"Miscompile" means "generate code that behaves different from what the
programmer intended" (while the compiler generates code as intended
without optimization). Does a programmer intentionally write code in
non-assembly language that depends on the exact timing? I doubt it.
Do they intentionally write code that depends on particular values for
uninitialized data? Probably not that many.
- 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-15 13:22 -0600 |
| Message-ID | <BYedna7sVMrCI2LPnZ2dnUVZ_rGdnZ2d@supernews.com> |
| In reply to | #28454 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> But for the platforms I work with, timing is influenced by so many >>> things (e.g., other processes polluting the caches and branch >>> predictors), that programmers do not write programs that rely on the >>> exact timings of code, and if they did, the programs would not work >>> anyway. >> >>I have certainly seen race conditions that were exposed when an >>optimization speeded up part of the code. > > Yes, can happen. > >>Of course, the compiler was blamed for "breaking the program", but >>all it did was make part of the program go faster. > > Well if a compiler's optimizer has miscompiled before, that's what one > tends to think of when an optimization changes the behaviour. There is a subset of programmers who reach for "compiler bug" as a first explanation whenever a program doesn't do what they want, especially when its behaviour changes when it is optimized. >>> But otherwise, yes, proper optimizations do not silently change the >>> behaviour of programs. >> >>> A more relevant case is reading uninitialized data. That may lead to >>> one behaviour in one version of a Forth system and a different >>> behaviour in the next version, even if the optimizations in these >>> versions do not differ. Again, if a program intentionally relies on >>> that, it is probably best of sticking with one version. >> >>So, a "proper optimization" is allowed to change the behaviour of a >>program that worked because uninitialized data had a particular value. >>Is that right or not? > > That's a judgement call, that's why I brought it up. What does this mean? Is that right or not? >>But you said that: >> >>>>> A reliable compiler does not silently miscompile a program that >>>>> works perfectly fine on the previous version of the compiler. > > Yes. And that's the attitude one should employ when writing an > optimizer. I'm trying to discover what this means. > There are some things that pretty much preclude optimization (and > also preclude most other changes in the compiler). One example is > if the timing has to be kept the same as in the unoptimized case. > In this case it's obvious that the only option is not to optimize. > But the compiler already does that by not turning on optimization, > so an optimizer does not need to cater for that particular case. > The only problem with this is if the programmer is unaware that his > program depends on the exact timing (as in the case reported above). > > I think that depending on uninitialized data is pretty much in the > same category of things that preclude most changes in the compiler. I think so too. > But I might be wrong. Here's another question, to help me to understand your position: is a "proper optimization" allowed to change the behaviour of a program that writes to memory addresses outside that data space which has been allocated for its use? I'm guessing that the answer will be "yes", because one of the things an optimizer can do is reuse memory addresses so that a use is found for an unused region. >>By "miscompile" I understood "generate code that does something >>different". But now I see that for you "miscompile" doesn't mean >>that. It seems to mean "doesn't do any optimization that would >>surprise me." > > "Miscompile" means "generate code that behaves different from what > the programmer intended" (while the compiler generates code as > intended without optimization). This is is hard for me to distinguish from "doesn't do any optimization that would surprise me." > Does a programmer intentionally write code in non-assembly language > that depends on the exact timing? I doubt it. Do they > intentionally write code that depends on particular values for > uninitialized data? Probably not that many. What does intentionality have to do with any of this? The writer of a compiler cannot know what a programmer's intentions were, or what side-effects of an implementation a programmer might have decided to utilize. Or is a compiler writer expected to guess what a "reasonable programmer" might do? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-17 12:28 +0000 |
| Message-ID | <53020082$0$9229$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #28459 |
In article <BYedna7sVMrCI2LPnZ2dnUVZ_rGdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>> But for the platforms I work with, timing is influenced by so many >>>> things (e.g., other processes polluting the caches and branch >>>> predictors), that programmers do not write programs that rely on the >>>> exact timings of code, and if they did, the programs would not work >>>> anyway. >>> >>>I have certainly seen race conditions that were exposed when an >>>optimization speeded up part of the code. >> >> Yes, can happen. >> >>>Of course, the compiler was blamed for "breaking the program", but >>>all it did was make part of the program go faster. >> >> Well if a compiler's optimizer has miscompiled before, that's what one >> tends to think of when an optimization changes the behaviour. > >There is a subset of programmers who reach for "compiler bug" as a >first explanation whenever a program doesn't do what they want, >especially when its behaviour changes when it is optimized. > >>>> But otherwise, yes, proper optimizations do not silently change the >>>> behaviour of programs. >>> >>>> A more relevant case is reading uninitialized data. That may lead to >>>> one behaviour in one version of a Forth system and a different >>>> behaviour in the next version, even if the optimizations in these >>>> versions do not differ. Again, if a program intentionally relies on >>>> that, it is probably best of sticking with one version. >>> >>>So, a "proper optimization" is allowed to change the behaviour of a >>>program that worked because uninitialized data had a particular value. >>>Is that right or not? >> >> That's a judgement call, that's why I brought it up. > >What does this mean? Is that right or not? > >>>But you said that: >>> >>>>>> A reliable compiler does not silently miscompile a program that >>>>>> works perfectly fine on the previous version of the compiler. >> >> Yes. And that's the attitude one should employ when writing an >> optimizer. > >I'm trying to discover what this means. > >> There are some things that pretty much preclude optimization (and >> also preclude most other changes in the compiler). One example is >> if the timing has to be kept the same as in the unoptimized case. >> In this case it's obvious that the only option is not to optimize. >> But the compiler already does that by not turning on optimization, >> so an optimizer does not need to cater for that particular case. >> The only problem with this is if the programmer is unaware that his >> program depends on the exact timing (as in the case reported above). >> >> I think that depending on uninitialized data is pretty much in the >> same category of things that preclude most changes in the compiler. > >I think so too. > >> But I might be wrong. > >Here's another question, to help me to understand your position: is a >"proper optimization" allowed to change the behaviour of a program >that writes to memory addresses outside that data space which has been >allocated for its use? I'm guessing that the answer will be "yes", >because one of the things an optimizer can do is reuse memory >addresses so that a use is found for an unused region. The consequences are far-reaching. The compiler may assume the program is correct. If it concludes that somewhere the program writes to inaccessible memory, the next conclusion is that this code is unreachable. By elimination dead code like this, an incorrect program may be "optimised" out of existance. <SNIP> > >What does intentionality have to do with any of this? The writer of a >compiler cannot know what a programmer's intentions were, or what >side-effects of an implementation a programmer might have decided to >utilize. Or is a compiler writer expected to guess what a "reasonable >programmer" might do? To an extent yes. I've read accounts of optimiser writers who guess whithin reason what mistakes are to expected of mediocre programmers, and prevent a lot of service calls by doing so. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-17 14:05 +0000 |
| Message-ID | <2014Feb17.150541@mips.complang.tuwien.ac.at> |
| In reply to | #28459 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Here's another question, to help me to understand your position: is a
>"proper optimization" allowed to change the behaviour of a program
>that writes to memory addresses outside that data space which has been
>allocated for its use? I'm guessing that the answer will be "yes",
>because one of the things an optimizer can do is reuse memory
>addresses so that a use is found for an unused region.
I don't follow your justification, but I tend to yes, because most
programmers don't do that intentinally, and because such behaviour
tends to be pretty fragile anyway, and will break on many changes, not
just turning on optimization; so if somebody does that intentionally,
their best course may be to change as little as possible anyway.
>>>By "miscompile" I understood "generate code that does something
>>>different". But now I see that for you "miscompile" doesn't mean
>>>that. It seems to mean "doesn't do any optimization that would
>>>surprise me."
>>
>> "Miscompile" means "generate code that behaves different from what
>> the programmer intended" (while the compiler generates code as
>> intended without optimization).
>
>This is is hard for me to distinguish from "doesn't do any
>optimization that would surprise me."
It's not about you or me, but about the programmer who wrote the code.
Also, here are two examples of the difference:
1) A case where gcc performed a proper optimization that surprised me:
It compiled
if (*s1==*s2 && *s1!=0 && *s2!=0) ...
into code equivalent to
if (*s1==*s2 && *s1!=0) ...
I found that surprising, but it did not change the behaviour, so
it's a proper optimization.
2) A case where gcc miscompiled and it did not surprise me: I wrote
if (x>x+1) ...
as a cell-size-independent and efficient way to check whether x is
the smallest signed integer. Now I had been burned by gcc
miscompilation before, and checked what gcc did, and found that it
indeed miscompiled this code: it left the whole if statement and
the statements it controlled away.
>What does intentionality have to do with any of this? The writer of a
>compiler cannot know what a programmer's intentions were, or what
>side-effects of an implementation a programmer might have decided to
>utilize. Or is a compiler writer expected to guess what a "reasonable
>programmer" might do?
Yes, and be pretty conservative about it.
- 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-17 09:49 -0600 |
| Message-ID | <tqednXgs9PDrsp_OnZ2dnUVZ_jqdnZ2d@supernews.com> |
| In reply to | #28498 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Here's another question, to help me to understand your position: is a >>"proper optimization" allowed to change the behaviour of a program >>that writes to memory addresses outside that data space which has been >>allocated for its use? I'm guessing that the answer will be "yes", >>because one of the things an optimizer can do is reuse memory >>addresses so that a use is found for an unused region. > > I don't follow your justification, but I tend to yes, because most > programmers don't do that intentinally, and because such behaviour > tends to be pretty fragile anyway, and will break on many changes, not > just turning on optimization; so if somebody does that intentionally, > their best course may be to change as little as possible anyway. > >>>>By "miscompile" I understood "generate code that does something >>>>different". But now I see that for you "miscompile" doesn't mean >>>>that. It seems to mean "doesn't do any optimization that would >>>>surprise me." >>> >>> "Miscompile" means "generate code that behaves different from what >>> the programmer intended" (while the compiler generates code as >>> intended without optimization). >> >>This is is hard for me to distinguish from "doesn't do any >>optimization that would surprise me." > > It's not about you or me, but about the programmer who wrote the code. What's the difference? We're both programmers who writew code. > Also, here are two examples of the difference: > > 1) A case where gcc performed a proper optimization that surprised me: > It compiled > > if (*s1==*s2 && *s1!=0 && *s2!=0) ... > > into code equivalent to > > if (*s1==*s2 && *s1!=0) ... > > I found that surprising, but it did not change the behaviour, so > it's a proper optimization. > > 2) A case where gcc miscompiled and it did not surprise me: I wrote > > if (x>x+1) ... > > as a cell-size-independent and efficient way to check whether x is > the smallest signed integer. Now I had been burned by gcc > miscompilation before, and checked what gcc did, and found that it > indeed miscompiled this code: it left the whole if statement and > the statements it controlled away. But how is anyone to determine what is a correct optimization, except by asking you for your opinion in each case? You don't offer any specification for what you require. You just declare people who don't share your intuitive understanding of programming language semantics to be wrong. >>What does intentionality have to do with any of this? The writer of a >>compiler cannot know what a programmer's intentions were, or what >>side-effects of an implementation a programmer might have decided to >>utilize. Or is a compiler writer expected to guess what a "reasonable >>programmer" might do? > > 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-17 19:06 +0100 |
| Message-ID | <ldtj28$72j$1@online.de> |
| In reply to | #28500 |
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. 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. 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. 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. Take for example the separate/mixed FP stack in ANS Forth: It was next to impossible to write portable software for both cases, so we evaluated how many mixed FP stacks there are, and decided that we label the separate stack as recommended default. This means if you produce a quality implementation, you will have a separate FP stack. This is now non-ambiguous. 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. 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! 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. Java does this kind of things (and that's one of the good things about Java). Ada does this, too. As your compiler suite has a Java and an Ada backend, you need to do this anyhow. Your main competitor, llvm, does specify a VM, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 7 of 21 — ← Prev page 1 … 5 6 [7] 8 9 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web