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 6 of 21 — ← Prev page 1 … 4 5 [6] 7 8 … 21 Next page →
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-01-31 02:34 +0100 |
| Message-ID | <1189pah3la0mu.19bqmet1trtfp.dlg@40tude.net> |
| In reply to | #28171 |
Op Thu, 30 Jan 2014 15:59:29 GMT schreef Anton Ertl:
> "Ed" <invalid@invalid.com> writes:
>>mhx@iae.nl wrote:
>>> On Sunday, January 26, 2014 7:04:51 PM UTC+1, Stephen Pelc wrote:
>>> > On Mon, 27 Jan 2014 00:43:23 +1100, "Ed" <invalid@invalid.com> wrote:
>>> [..]
>>> anew -when
>>> : cond ( char -- 0 char ) 0 SWAP ;
>>> : range ( flag1 char low hi -- flag2 char ) 2 PICK >R 1+ WITHIN OR R> ;
>>> : equal ( flag1 char val -- flag2 ) OVER >R = OR R> ;
>>> : when ( flag char -- char ) POSTPONE TUCK POSTPONE AND POSTPONE OF ; IMMEDIATE COMPILE-ONLY
>>>
>>> : TEST1 ( char -- )
>>> space
>>> case
>>> cond
>>> 00 $1F range
>>> $7F equal when ." Control char " endof
>>> cond
>>> BL '/' range
>>> ':' '@' range
>>> '[' &` range
>>> '{' '~' range when ." Punctuation " endof
>>> cond '0' '9' range when ." Digit " endof
>>> cond 'A' 'Z' range when ." Upper case letter " endof
>>> cond 'a' 'z' range when ." Lower case letter " endof
>>> drop ." Not a character "
>>> endcase ;
>>
>>Good. (It wasn't necessary to emulate cond/equal/when etc but no matter.)
>>
>>The above demonstrates the limitation of ANS CASE. Because it doesn't cater
>>for more than one case per block, it must be simulated. It does this by testing
>>each case and OR'ing the results - a slow and cumbersome process. There's
>>no advantage ordering the cases (for speed) because all must be tested.
>
> No, once a test succeeds, the following OFs are not tested. If you
> know that one of the cases dominates (say, lower case letters), you
> can increase efficiency by putting that OF first. Alternatively, you
> can use that property of the CASE construct to simplify the tests
> (which can also help efficiency).
>
>: TEST1 ( char -- )
> space
> case
> cond '0' '9' range when ." Digit " endof
> cond 'A' 'Z' range when ." Upper case letter " endof
> cond 'a' 'z' range when ." Lower case letter " endof
> cond bl '~' range when ." Punctuation " endof
> cond 00 $7F range when ." Control char " endof
> drop ." Not a character "
> endcase ;
>
> And now you can simplify even more into:
>
>: TEST1 ( char -- )
> space
> case
> 0' '9' range-of ." Digit " endof
> A' 'Z' range-of ." Upper case letter " endof
> a' 'z' range-of ." Lower case letter " endof
> bl '~' range-of ." Punctuation " endof
> 00 $7F range-of ." Control char " endof
> drop ." Not a character "
> endcase ;
>
> I leave the definition of RANGE-OF as an exercise to the reader.
>
> - anton
Got it, when (range) matches, it leaves the inspected character double on
the stack, so OF sees it as success, otherwise it leaves the character and
the same but one more, so OF sees it as failure.
: (range) 2>r dup dup 2r> 1+ within 0=
if 1+ then ;
: range-of postpone (range) postpone of ; immediate
In the example, the drop in the line with "not a character" must be
dropped, contrary to my comment on Marcels code, because of the use of
cond.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-01-31 02:38 +0100 |
| Message-ID | <qpswjzouzwpn$.t9l7r5tbl6m5.dlg@40tude.net> |
| In reply to | #28175 |
Op Fri, 31 Jan 2014 02:34:32 +0100 schreef Coos Haak: > Got it, when (range) matches, it leaves the inspected character double on > the stack, so OF sees it as success, otherwise it leaves the character and > the same but one more, so OF sees it as failure. > >: (range) 2>r dup dup 2r> 1+ within 0= > if 1+ then ; Shorter : (range) 2>r dup dup 2r> 1+ within 0= + ; When failure, leave the duplicate one less. > >: range-of postpone (range) postpone of ; immediate > > In the example, the drop in the line with "not a character" must be > dropped, contrary to my comment on Marcels code, because of the use of > cond. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-30 15:51 -1000 |
| Message-ID | <FYWdnQDmar0BnHbPnZ2dnUVZ_qOdnZ2d@supernews.com> |
| In reply to | #28176 |
On 1/30/14 3:38 PM, Coos Haak wrote: > Op Fri, 31 Jan 2014 02:34:32 +0100 schreef Coos Haak: > >> Got it, when (range) matches, it leaves the inspected character double on >> the stack, so OF sees it as success, otherwise it leaves the character and >> the same but one more, so OF sees it as failure. >> >> : (range) 2>r dup dup 2r> 1+ within 0= >> if 1+ then ; > > Shorter > : (range) 2>r dup dup 2r> 1+ within 0= + ; > When failure, leave the duplicate one less. > >> >> : range-of postpone (range) postpone of ; immediate >> >> In the example, the drop in the line with "not a character" must be >> dropped, contrary to my comment on Marcels code, because of the use of >> cond. > This would be ever so much clearer if you used stack comments. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-03 14:58 +0000 |
| Message-ID | <2014Feb3.155831@mips.complang.tuwien.ac.at> |
| In reply to | #28175 |
Coos Haak <chforth@hccnet.nl> writes:
>Op Thu, 30 Jan 2014 15:59:29 GMT schreef Anton Ertl:
>>: TEST1 ( char -- )
>> space
>> case
>> 0' '9' range-of ." Digit " endof
>> A' 'Z' range-of ." Upper case letter " endof
>> a' 'z' range-of ." Lower case letter " endof
>> bl '~' range-of ." Punctuation " endof
>> 00 $7F range-of ." Control char " endof
>> drop ." Not a character "
>> endcase ;
>>
>> I leave the definition of RANGE-OF as an exercise to the reader.
>>
>> - anton
>
>Got it, when (range) matches, it leaves the inspected character double on
>the stack, so OF sees it as success, otherwise it leaves the character and
>the same but one more, so OF sees it as failure.
>
>: (range) 2>r dup dup 2r> 1+ within 0=
> if 1+ then ;
>
>: range-of postpone (range) postpone of ; immediate
So, when you try to define RANGE-OF in terms of OF, there is extra
work because the interface of OF does not quite fit; that's why I
suggested a word RANGE-OF rather than a sequence like RANGE OF; it
allows a more integrated implementation, something like (for Gforth):
: range-of ( comp: -- of-sys; run-time: n1 n2 n3 -- | n1 )
>r ]] 2>r dup 2r> 1+ within if drop [[ r> ; immediate
Works with
: TEST1 ( char -- )
space
case
'0' '9' range-of ." Digit " endof
'A' 'Z' range-of ." Upper case letter " endof
'a' 'z' range-of ." Lower case letter " endof
bl '~' range-of ." Punctuation " endof
00 $7F range-of ." Control char " endof
drop ." Not a character "
endcase ;
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-02-03 12:06 -0800 |
| Message-ID | <4643e053-bf4e-4fdc-92b9-0e474e1dd734@googlegroups.com> |
| In reply to | #28224 |
On Monday, February 3, 2014 3:58:31 PM UTC+1, Anton Ertl wrote:
> Coos Haak <chforth@hccnet.nl> writes:
>
> >Op Thu, 30 Jan 2014 15:59:29 GMT schreef Anton Ertl:
[..]
Let's see what is at stake here ...
anew -when
: between ( c a b -- bool ) 1+ WITHIN ;
: cond ( char -- 0 char ) 0 SWAP ;
: range ( flag1 char low hi -- flag2 char ) 2 PICK >R between OR R> ;
: equal ( flag1 char val -- flag2 ) OVER >R = OR R> ;
: when ( flag char -- char ) POSTPONE TUCK POSTPONE AND POSTPONE OF ; IMMEDIATE COMPILE-ONLY
: .control ( -- ) ; \ ." Control char " ;
: .punct ( -- ) ; \ ." Punctuation " ;
: .digit ( -- ) ; \ ." Digit " ;
: .upper ( -- ) ; \ ." Upper case letter " ;
: .lower ( -- ) ; \ ." Lower case letter " ;
: .nochar ( -- ) ; \ ." Not a character " ;
: TEST1 ( char -- )
case
cond
00 $1F range
$7F equal when .control endof
cond
BL '/' range
':' '@' range
'[' &` range
'{' '~' range when .punct endof
cond '0' '9' range when .digit endof
cond 'A' 'Z' range when .upper endof
cond 'a' 'z' range when .lower endof
.nochar
endcase ;
: TEST0 ( char -- )
LOCAL c
c $7F = c $20 < OR IF .control EXIT ENDIF
c '0' '9' between IF .digit EXIT ENDIF
c 'A' 'Z' between IF .upper EXIT ENDIF
c 'a' 'z' between IF .lower EXIT ENDIF
c BL '/' between IF .punct EXIT ENDIF
c ':' '@' between IF .punct EXIT ENDIF
c '[' &` between IF .punct EXIT ENDIF
c '{' '~' between IF .punct ELSE .nochar ENDIF ;
: BENCH CR ." \ cond etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST1 LOOP .ELAPSED
CR ." \ OF etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST0 LOOP .ELAPSED ;
FORTH> bench
\ cond etc., 100,000,000 times: 2.019 seconds elapsed.
\ OF etc., 100,000,000 times: 0.844 seconds elapsed. ok
\ saving 1.2 / 1e8 = 12 ns.
So we're worrying about a possible 12..24 ns savings in a word which
is supposed to do text output to the console.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-09 15:04 +0000 |
| Message-ID | <2014Feb9.160429@mips.complang.tuwien.ac.at> |
| In reply to | #28225 |
mhx@iae.nl writes:
>: BENCH CR ." \ cond etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST1 LOOP .ELAPSED
> CR ." \ OF etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST0 LOOP .ELAPSED ;
>
>FORTH> bench
>\ cond etc., 100,000,000 times: 2.019 seconds elapsed.
>\ OF etc., 100,000,000 times: 0.844 seconds elapsed. ok
>\ saving 1.2 / 1e8 = 12 ns.
>
>
>So we're worrying about a possible 12..24 ns savings in a word which
>is supposed to do text output to the console.
Sure, for that word it does not matter, but in other contexts a speed
difference of more than a factor of two in the selection may be relevant.
But I found that surprising, so I looked closer at it and did quite a
bit of benchmarking on my own. A problem I see with your benchmark is
that it is very predictable: in the last 99999872 invocations of
TEST0/1 the branches produce the same result (leading to .nochar).
That may not be very realistic, so I used three different inputs and
measured a variety of implementations of the word:
All inputs are 25000 chars long (and were processed 4000 times per
benchmark run for a total of 10^8 chars processed). The inputs are:
nochar: contains only the char 255; this is intended to reproduce
Marcel Hendrix' result. This is the best case for branch predictors.
random: contains uniformly distributed random chars between 0 and 159.
This is the worst case for branch predictors (in general; it is
possible to design a particularly adversarial sequence for a given
branch predictor).
forth: contains the 25000 first chars of a Forth source file. This is
intended to represent a typical case (if there is one).
The implementations of the test words are:
cond-when: TEST1 in mhx's program (with multiple range checks combined
with OR).
if-exit: TEST0 in mhx's program (an IF for each range).
range-of1: OFs arranged in a way such that testing for punctuation and
control do not need to check multiple ranges.
range-of-reordered: like range-of, but rearranged non-overlapping
ranges for expected frequency: lower-case chars are checked first.
cond-when-no-or: like range-of1, but using the cond...when syntax and
implementation.
execute1: use a dispatch table and EXECUTE for chars 0..$7f.
The results are (on a Core 2 Duo E8400 with vfxlin 4.60:
nochar random forth
cond-when
cycles 6214228299 7062893298 5847349761
branch mispredictions 130903 100668513 35284369
if-exit
cycles 3110486661 4823796609 3271687596
branch mispredictions 130547 97707494 41190043
range-of1
cycles 2258890920 3970150038 2459635254
branch mispredictions 131062 96950710 36173165
range-of-reordered
cycles 2369566791 4057743969 2336331564
branch mispredictions 130607 96981356 36597965
cond-when-no-or
cycles 3994438779 5732459433 3593025963
branch mispredictions 130697 96939636 36078610
execute1
cycles 842850828 3728143107 2587141053
branch mispredictions 130672 87887223 42717886
So if-exit is indeed a lot faster than cond-when, even for random; and
it has a better branch prediction then cond-when even for random.
That's a surprise to me.
Range-of1 is faster than either. Range-of-reordered is slightly faster
for forth (as intended). It's not clear to me why it's a bit slower
for nochar and random.
Cond-when-no-or shows that the rearrangement is not everything. The
implementation of COND ... WHEN is slow compared to that of RANGE-OF.
But compared to cond-when, cond-when-no-or is quite a lot faster.
Execute1 shines on nochar (only 8.4 cycles per processed char,
compared to 22.6 for the next fastest alternative), because it always
predicts correctly there. It also has slightly fewer mispredictions
than the competition for random, but is not that much faster than
range-of1 here. For the Forth input, it has the most mispreductions,
and is slightly slower than the range-of variants.
Your can find the code on
http://www.complang.tuwien.ac.at/forth/programs/switchbench.zip.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-02-09 10:56 -0800 |
| Message-ID | <8af1a9bb-1560-4f06-8425-3cd4293fe267@googlegroups.com> |
| In reply to | #28281 |
On Sunday, February 9, 2014 4:04:29 PM UTC+1, Anton Ertl wrote:
> mhx@iae.nl writes:
>
> >: BENCH CR ." \ cond etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST1 LOOP .ELAPSED
> > CR ." \ OF etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST0 LOOP .ELAPSED ;
>
> FORTH> bench
> \ cond etc., 100,000,000 times: 2.019 seconds elapsed.
> \ OF etc., 100,000,000 times: 0.844 seconds elapsed. ok
> \ saving 1.2 / 1e8 = 12 ns.
[..]
A slight correction (that doesn't change your general result):
I deleted that post after about 5 minutes and submitted the alternative with "#255 AND" inserted (still there at least with the Google reader):
: BENCH CR ." \ cond etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I #255 AND TEST1 LOOP .ELAPSED
CR ." \ IF etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I #255 AND TEST0 LOOP .ELAPSED ;
\ cond etc., 100,000,000 times: 1.799 seconds elapsed.
\ OF etc., 100,000,000 times: 0.783 seconds elapsed. ok
\ saving 1 / 1e8 = 10 ns.
Highly predictive for a human, but impressive if the processor
exploited it.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-10 15:58 +0000 |
| Message-ID | <2014Feb10.165809@mips.complang.tuwien.ac.at> |
| In reply to | #28284 |
mhx@iae.nl writes:
>On Sunday, February 9, 2014 4:04:29 PM UTC+1, Anton Ertl wrote:
>> mhx@iae.nl writes:
>>
>> >: BENCH CR ." \ cond etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST1 LOOP .ELAPSED
>> > CR ." \ OF etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I TEST0 LOOP .ELAPSED ;
>>
>> FORTH> bench
>> \ cond etc., 100,000,000 times: 2.019 seconds elapsed.
>> \ OF etc., 100,000,000 times: 0.844 seconds elapsed. ok
>> \ saving 1.2 / 1e8 = 12 ns.
>
>[..]
>
>A slight correction (that doesn't change your general result):
>I deleted that post after about 5 minutes and submitted the alternative with "#255 AND" inserted (still there at least with the Google reader):
AFAIK Google ignores cancels and supersedes, and apparently does not
propagate cancels (so my recommendation is to use a different news
server and send a cancel immediately (so it will hopefully catch the
to-be-canceled posting before it has propagated too far), but also
include a "Supersedes:" in the new posting). I saw both postings, but
did not spot the difference, so I assumed they had the same content.
>: BENCH CR ." \ cond etc., 100,000,000 times: " TIMER-RESET #100000000 0 DO I #255 AND TEST1 LOOP .ELAPSED
>
>Highly predictive for a human, but impressive if the processor
>exploited it.
Even a relatively simple predictor that predicts (per branch location)
that every branch will branch like it did last time will only
mispredict on category changes, and there are only about 10 such
changes for each 256 chars (there may be more than one branch
mispredicted per category change, though), so I would not find it that
impressive.
Anyway, let's see how a 2007-vintage CPU (Xeon E5450) does (there are
also a few more variants of the code in this data, discussed below):
nochar 0-255 random forth
cond-when
cycles 6112925730 5146812045 7072811361 5882624235
branch mispredictions 172458 8322533 100713020 36104132
if-exit
cycles 3078873819 2861084223 4787188389 3214801800
branch mispredictions 172592 10501466 98392270 40990952
if-exit-nolocal
cycles 2764916181 2489396040 4434227127 2881493820
branch mispredictions 172653 10604202 103808697 38777156
if-lt-exit
cycles 2651142573 2183950989 3693859650 2412457227
branch mispredictions 172953 9524077 100917331 35232394
if-tree
cycles 1649940003 1547685234 3936635793 2080625022
branch mispredictions 172768 7197715 136818386 41101604
range-of1
cycles 2351242908 2232882315 3962227590 2545391016
branch mispredictions 171974 7216811 97166639 36289345
range-of-reordered
cycles 2266886745 2095444719 3958337979 2319298362
branch mispredictions 173247 7156504 96300725 39020756
if-range
cycles 2051325306 1915896321 4008932271 2146507470
branch mispredictions 172683 7409669 96435688 37550207
cond-when-no-or
cycles 3995589672 3461412906 5643249012 3623354577
branch mispredictions 172978 7524597 97365896 36144760
cond-when-shortcircuit
cycles 5285638782 4340686194 6298363728 4742537715
branch mispredictions 172305 5440433 103031562 34360248
execute1
cycles 850183245 1329066000 3698307774 2646945819
branch mispredictions 171933 7592963 87935253 42756879
The 0-255 input creates 9-19 times fewer mispredictions than random,
and 3.6-6.3 times fewer mispredictions than the forth input, so it is
pretty predictable.
The new code variants are:
if-exit-nolocal: like if-exit, but uses DUP and DROP instead of a
local (VFX is not very good at locals).
if-lt-exit: like if-exit-nolocal, but rearranged the cases in
ascending order, which makes it possible to replace the BETWEEN/WITHIN
checks with U< checks.
: if-lt-exit ( char -- )
dup bl u< IF drop .control EXIT ENDIF
dup '0' u< IF drop .punct EXIT ENDIF
dup ':' u< IF drop .digit EXIT ENDIF
dup 'A' u< IF drop .punct EXIT ENDIF
dup '[' u< IF drop .upper EXIT ENDIF
dup 'a' u< IF drop .punct EXIT ENDIF
dup '{' u< IF drop .lower EXIT ENDIF
dup $7f u< IF drop .punct EXIT ENDIF
$80 u< if .control exit endif
.nochar ;
if-tree: like if-lt-exit, but the tests now form a decision tree
instead of sequential search (this is actually just a rearrangement of
the if-lt-exit code).
: if-tree ( char -- )
dup '[' u< IF
dup ':' u< IF
dup bl u< IF drop .control EXIT ENDIF
dup '0' u< IF drop .punct EXIT ENDIF
drop .digit EXIT ENDIF
dup 'A' u< IF drop .punct EXIT ENDIF
drop .upper EXIT ENDIF
dup '{' u< IF
dup 'a' u< IF drop .punct EXIT ENDIF
drop .lower EXIT ENDIF
dup $7f u< IF drop .punct EXIT ENDIF
$80 u< if .control exit endif
.nochar ;
if-range: like if-exit, but tests arrange like range-of-reordered
(i.e., less tests than if-exit). This is intended to blend the best
of two good approaches together.
: if-range ( char -- )
dup 'a' 'z' between IF drop .lower EXIT ENDIF
dup 'A' 'Z' between IF drop .upper EXIT ENDIF
dup '0' '9' between IF drop .digit EXIT ENDIF
dup bl '~' between IF drop .punct EXIT ENDIF
dup $80 u< IF drop .control EXIT ENDIF
drop .nochar ;
cond-when-shortcircuit: A reimplementation of the cond...when syntax
that only evaluates the ranges of a cond until a range matches.
: case1 ( compilation -- case-sys ; run-time -- ) \ core-ext
0 ; immediate
: ?of1 ( compilation -- of-sys ; run-time f -- ) \ gforth
>r POSTPONE if r> ; immediate
: of1 ( compilation -- of-sys ; run-time x1 x2 -- |x1 ) \ core-ext
\ !! the implementation does not match the stack effect
postpone over postpone = postpone ?of postpone drop ; immediate
: endof1 ( compilation case-sys1 of-sys -- case-sys2 ; run-time -- ) \ core-ext end-of
>r postpone else r> 1+ ; immediate
: n-thens1 ( orig1 ... origu u -- )
0 ?do postpone then loop ;
: endcase1 ( compilation case-sys -- ; run-time x -- ) \ core-ext end-case
>r postpone drop r> n-thens1 ; immediate
: cond1 ( comp: -- 0 )
0 ; immediate
: dup-between ( x1 x2 x3 -- x1 f )
1+ 2 pick >r within r> swap ;
: range1 ( comp: ucase u1 -- orig ucase u2; run-time: char low hi -- char )
2>r postpone dup-between postpone 0= postpone if 2r> 1+ ; immediate
: equal1 ( comp: ucase u1 -- orig ucase u2; run-time: char low hi -- char )
2>r postpone over postpone <> postpone if 2r> 1+ ; immediate
: when1 ( comp: orig1 ... origu u -- orig0 )
swap >r >r postpone ahead
r> 0 ?do
1 cs-roll postpone then
loop
r> postpone drop ; immediate
Discussion:
If-exit-nolocal is faster than if-exit; VFX compiles dup to better
code than locals accesses. If-lt-exit is faster still, but
interestingly more for the random and forth inputs than for the nochar
input. If-tree produces more mispredictions, but is the fastest for
the forth input, and the second fastest for nochar.
If-range is faster than its parents if-exit and range-of-reordered (as
intended), but slower than if-tree and (except for the Forth input)
execute1.
cond-when-shortcircuit is faster than cond-when, even for the random
input (with slightly more branch mispredictions), but is still one of
the slower variants. Surprisingly, it has the least branch
mispredictions for the Forth and 0-255 inputs.
You can find the code on
http://www.complang.tuwien.ac.at/forth/programs/switchbench.zip.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-02-10 12:06 -0800 |
| Message-ID | <22153d44-1ab2-4b38-a0cf-b526acf72448@googlegroups.com> |
| In reply to | #28295 |
On Monday, February 10, 2014 4:58:09 PM UTC+1, Anton Ertl wrote: > mhx@iae.nl writes: Nice. Here are the results for iForth. I reformatted the output for better viewing. That extra call costs Vfx a few ns :-) -marcel \ FORTH> .timings ( i7-920 @2.67GHz, iForth 64bit) \ input-nochar input-0-255 input-random input-forth \ cond-when : 6,346,904,229 5,642,283,817 8,046,563,090 6,592,156,589 \ if-exit : 2,799,249,563 2,561,896,191 4,917,164,627 3,181,333,799 \ if-exit-nolocal : 2,526,173,016 2,300,288,012 4,557,867,180 2,909,853,198 \ if-lt-exit : 2,807,117,092 2,342,671,793 4,361,761,971 2,891,869,976 \ if-tree : 1,679,227,193 1,621,541,419 4,446,235,931 2,398,170,220 \ range-of1 : 1,771,500,525 1,757,613,072 3,987,070,255 2,345,062,566 \ range-of-reordered : 1,774,096,820 1,735,153,443 3,992,501,922 2,297,363,509 \ if-range : 1,865,297,449 1,800,873,471 3,966,166,725 2,331,226,494 \ cond-when-no-or : 4,396,579,169 4,101,422,580 6,541,565,536 4,473,685,774 \ cond-when-shortcircuit : 5,326,803,566 4,463,152,744 6,707,315,275 5,076,355,470 \ execute1 : 1,223,918,211 1,632,836,771 4,647,442,503 2,913,930,095 \ VFX 32bit on Xeon E5450 \ nochar 0-255 random forth \ cond-when 6,112,925,730 5,146,812,045 7,072,811,361 5,882,624,235 \ if-exit 3,078,873,819 2,861,084,223 4,787,188,389 3,214,801,800 \ if-exit-nolocal 2,764,916,181 2,489,396,040 4,434,227,127 2,881,493,820 \ if-lt-exit 2,651,142,573 2,183,950,989 3,693,859,650 2,412,457,227 \ if-tree 1,649,940,003 1,547,685,234 3,936,635,793 2,080,625,022 \ range-of1 2,351,242,908 2,232,882,315 3,962,227,590 2,545,391,016 \ range-of-reordered 2,266,886,745 2,095,444,719 3,958,337,979 2,319,298,362 \ if-range 2,051,325,306 1,915,896,321 4,008,932,271 2,146,507,470 \ cond-when-no-or 3,995,589,672 3,461,412,906 5,643,249,012 3,623,354,577 \ cond-when-shortcircuit 5,285,638,782 4,340,686,194 6,298,363,728 4,742,537,715 \ execute1 850,183,245 1,329,066,000 3,698,307,774 2,646,945,819
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-11 11:22 +0000 |
| Message-ID | <2014Feb11.122211@mips.complang.tuwien.ac.at> |
| In reply to | #28303 |
mhx@iae.nl writes:
>On Monday, February 10, 2014 4:58:09 PM UTC+1, Anton Ertl wrote:
>> mhx@iae.nl writes:
>
>Nice. Here are the results for iForth.
Thanks. The relations between the different Forth codes are similar
on both Forth system, so if there are Forth compiler artifacts
involved (such as locals costs), both compilers seem to be similar in
these respects.
>That extra call costs Vfx a few ns :-)
I would expect that, but I don't see that reflected in the data.
execute1 takes fewer cycles on VFX, and the relation between the other
implementations and execute1 does not look like execute1 is relatively
slower on VFX than on iForth.
- 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 | m.a.m.hendrix@tue.nl |
|---|---|
| Date | 2014-02-11 05:23 -0800 |
| Message-ID | <7627efb9-a853-4f60-99d7-53caa45f9a51@googlegroups.com> |
| In reply to | #28311 |
On Tuesday, February 11, 2014 12:22:11 PM UTC+1, Anton Ertl wrote: > mhx@iae.nl writes: >On Monday, February 10, 2014 4:58:09 PM UTC+1, Anton Ertl wrote: >> mhx@iae.nl writes: > >Nice. Here are the results for iForth. > Thanks. [..] >> That extra call costs Vfx a few ns :-) > I would expect that, but I don't see that reflected in the data. True. I made a mistake (wistful thinking) when reading the table. I'll try it with iForth32 to see if I can find what is causing this. -marcel
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-02-12 10:54 -0800 |
| Message-ID | <c698e6b2-3964-43cf-9bed-46479e2d8b38@googlegroups.com> |
| In reply to | #28303 |
On Monday, February 10, 2014 9:06:39 PM UTC+1, m...@iae.nl wrote: > On Monday, February 10, 2014 4:58:09 PM UTC+1, Anton Ertl wrote: > > mhx@iae.nl writes: [..] > \ FORTH> .timings ( i7-920 @2.67GHz, iForth 64bit) > \ input-nochar input-0-255 input-random input-forth > \ cond-when : 6,346,904,229 5,642,283,817 8,046,563,090 6,592,156,589 > \ if-exit : 2,799,249,563 2,561,896,191 4,917,164,627 3,181,333,799 > \ if-exit-nolocal : 2,526,173,016 2,300,288,012 4,557,867,180 2,909,853,198 > \ if-lt-exit : 2,807,117,092 2,342,671,793 4,361,761,971 2,891,869,976 > \ if-tree : 1,679,227,193 1,621,541,419 4,446,235,931 2,398,170,220 > \ range-of1 : 1,771,500,525 1,757,613,072 3,987,070,255 2,345,062,566 > \ range-of-reordered : 1,774,096,820 1,735,153,443 3,992,501,922 2,297,363,509 > \ if-range : 1,865,297,449 1,800,873,471 3,966,166,725 2,331,226,494 > \ cond-when-no-or : 4,396,579,169 4,101,422,580 6,541,565,536 4,473,685,774 > \ cond-when-shortcircuit : 5,326,803,566 4,463,152,744 6,707,315,275 5,076,355,470 > \ execute1 : 1,223,918,211 1,632,836,771 4,647,442,503 2,913,930,095 But here the same iForth64 runs on Linux (and a newer CPU): FORTH> .timings ( Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz on Linux) \ input-nochar input-0-255 input-random input-forth \ cond-when : 4,891,361,540 4,208,792,334 5,540,642,949 4,838,778,005 \ if-exit : 1,901,547,585 1,662,851,657 3,214,747,968 1,972,416,607 \ if-exit-nolocal : 1,834,462,260 1,564,399,299 2,905,703,409 1,768,365,930 \ if-lt-exit : 2,032,586,754 1,644,585,701 2,850,777,605 1,887,264,409 \ if-tree : 1,219,623,123 1,107,459,558 3,010,698,315 1,502,909,268 \ range-of1 : 1,287,371,980 1,241,892,644 2,527,898,294 1,580,847,298 \ range-of-reordered : 1,287,365,817 1,224,578,139 2,509,108,618 1,402,272,044 \ if-range : 1,355,117,137 1,263,557,325 2,515,502,726 1,415,087,617 \ cond-when-no-or : 3,279,293,359 3,018,605,961 4,464,024,673 3,007,823,331 \ cond-when-shortcircuit : 3,945,028,457 3,235,696,943 4,643,551,387 3,595,227,118 \ execute1 : 689,075,476 1,043,965,027 3,020,107,541 2,207,686,956 ok -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-10 18:12 -0500 |
| Message-ID | <op.xa29fam05zc71u@localhost> |
| In reply to | #28284 |
On Sun, 09 Feb 2014 13:56:58 -0500, <mhx@iae.nl> wrote: > I deleted that post after about 5 minutes and submitted the alternative FYI, you deleted the post from Google Groups, but not from Usenet. Usenet servers usually don't delete posts anymore due to abuse. On Google Groups, your post and one of Hugh's say: "This message has been deleted." But, both are available on the Usenet server where I read. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-10 05:13 -0600 |
| Message-ID | <4s2dnQiAR8HoKWXPnZ2dnUVZ_vidnZ2d@supernews.com> |
| In reply to | #28281 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > nochar random forth > cond-when > cycles 6214228299 7062893298 5847349761 > branch mispredictions 130903 100668513 35284369 > if-exit > cycles 3110486661 4823796609 3271687596 > branch mispredictions 130547 97707494 41190043 > range-of1 > cycles 2258890920 3970150038 2459635254 > branch mispredictions 131062 96950710 36173165 > range-of-reordered > cycles 2369566791 4057743969 2336331564 > branch mispredictions 130607 96981356 36597965 > cond-when-no-or > cycles 3994438779 5732459433 3593025963 > branch mispredictions 130697 96939636 36078610 > execute1 > cycles 842850828 3728143107 2587141053 > branch mispredictions 130672 87887223 42717886 > > So if-exit is indeed a lot faster than cond-when, even for random; and > it has a better branch prediction then cond-when even for random. > That's a surprise to me. > > Range-of1 is faster than either. Range-of-reordered is slightly faster > for forth (as intended). It's not clear to me why it's a bit slower > for nochar and random. > > Cond-when-no-or shows that the rearrangement is not everything. The > implementation of COND ... WHEN is slow compared to that of RANGE-OF. > But compared to cond-when, cond-when-no-or is quite a lot faster. > > Execute1 shines on nochar (only 8.4 cycles per processed char, > compared to 22.6 for the next fastest alternative), because it always > predicts correctly there. It also has slightly fewer mispredictions > than the competition for random, but is not that much faster than > range-of1 here. For the Forth input, it has the most mispreductions, > and is slightly slower than the range-of variants. Thanks for doing that. So, overall, as expected, a simple jump table performs well. It's interesting that range-of1 performs as well as it does. We shouldn't read too much into small differences lest we end up falsely believing something to be significant that turns out merely to be an artefact of a particular version of a compiler. 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. IMO the most revealing thing of all is that the specific example which provoked this investigation turned out to be a problem that does not require a CASE statement, rather supporting Elizabeth's point: On Mon, 27 Jan 2014 00:43:23 +1100, "Ed" <invalid@invalid.com> wrote: > Elizabeth D Rather wrote: > > > People should order their cases if they have a good sense of what > > choices will occur most often. And jump tables are an easy-to-implement > > alternative if the application warrants it, particularly if the selector > > can be used to compute an index into the table. > > Presented with a complex CASE scenario such as the one below, how > would you and Stephen approach it, assuming it had to be reasonably > efficient? > > hex > > : TEST1 ( n ) space > case > cond > 00 1F range > 7F equal when ." Control char " else > cond > 20 2F range > 3A 40 range > 5B 60 range > 7B 7E range when ." Punctuation " else > cond 30 39 range when ." Digit " else > cond 41 5A range when ." Upper case letter " else > cond 61 7A range when ." Lower case letter " else > drop ." Not a character " > end-case ; Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-02-10 15:44 +0000 |
| Message-ID | <ldas5b$f3h$1@dont-email.me> |
| In reply to | #28293 |
on 10/02/2014 11:13:55, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: [benchmark snipped] > > Thanks for doing that. Seconded. > > So, overall, as expected, a simple jump table performs well. It's > interesting that range-of1 performs as well as it does. > I'm implementing string <-> Base64 routines at the moment. There's a trade off; is it easier to program as a shift, mask to 6 bits and CASE or have multiple jump tables for each byte? Which is faster? There's also a question here for processing large amounts of UTF-8 strings, since unlike ASCII where a byte is a character, each byte's leading bits have to be considered.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-10 10:40 -0600 |
| Message-ID | <VuadnbBOFomSnGTPnZ2dnUVZ_tqdnZ2d@supernews.com> |
| In reply to | #28294 |
Alex McDonald <blog@rivadpm.com> wrote: > on 10/02/2014 11:13:55, Andrew Haley wrote: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > [benchmark snipped] >> >> Thanks for doing that. > > Seconded. > >> So, overall, as expected, a simple jump table performs well. It's >> interesting that range-of1 performs as well as it does. > > I'm implementing string <-> Base64 routines at the moment. There's a > trade off; is it easier to program as a shift, mask to 6 bits and CASE or > have multiple jump tables for each byte? What do you want a jump table for? Unless you're desperately short of space each 6 bits is an index into a table of characters, and on the way back each character is an index into a 256-element table of 6-bit integers. When decoding, You don't need to check for a valid character every time: just OR all of the decoded characters together and if the result has has a top bit set at the end of a line you've had an overflow. > Which is faster? There's also a question here for processing large > amounts of UTF-8 strings, since unlike ASCII where a byte is a > character, each byte's leading bits have to be considered. That's a special case, so it's usually a branch if top bit set. The 110, 111, 11110 etc. UTF-8 prefixes are progressively less frequent (usually) so they can be handled out of line. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-10 17:47 +0100 |
| Message-ID | <ldavq7$5um$1@online.de> |
| In reply to | #28294 |
Alex McDonald wrote: > I'm implementing string <-> Base64 routines at the moment. There's a > trade off; is it easier to program as a shift, mask to 6 bits and CASE or > have multiple jump tables for each byte? Which is faster? There's also a > question here for processing large amounts of UTF-8 strings, since unlike > ASCII where a byte is a character, each byte's leading bits have to be > considered. Don't do CASE on that - index into a data table. Remember Thinking Forth? "Compute, don't do control structures". The good thing for UTF-8 strings is that they usually are in one or another language, and the languages themselves have at least the majority of their code-points together. So the branch misprediction is small. -- 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-10 16:34 +0000 |
| Message-ID | <2014Feb10.173445@mips.complang.tuwien.ac.at> |
| In reply to | #28293 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>So, overall, as expected, a simple jump table performs well. It's
>interesting that range-of1 performs as well as it does.
Yes. In the meantime I have tried out a few more variants (see
<2014Feb10.165809@mips.complang.tuwien.ac.at>), and some of the newer
ones also perform pretty well.
>We shouldn't read too much into small differences lest we end up
>falsely believing something to be significant that turns out merely to
>be an artefact of a particular version of a compiler.
Yes. I actually see the differences between range-of1 and
cond-when-no-or, as well as those between range-of-reordered and
if-range as artifact of the implementation, and obviously the
difference between if-exit and if-exit-nolocal.
There may also be artifacts of the CPU; the next CPU implements branch
prediction differently, and might get somewhat different results.
But even for compiler artifacts, it is interesting that both iForth
and VFX do quite a lot better for if-exit than for cond-when, and a
lot of that seems to come from COND...WHEN being expensive on the
compiler (as can be seen by comparing cond-when-no-or to range-of1).
>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.
>IMO the most revealing thing of all is that the specific example which
>provoked this investigation turned out to be a problem that does not
>require a CASE statement, rather supporting Elizabeth's point:
Also, I (think I) understand that Ed's comment was on the use of OR
instead of short-circuit evaluation in the original COND...WHEN
implementation. That's an issue that also arises in connection with
IF and other conditional control flow. I find it interesting (and to
me it's unexpected) that cond-when-shortcircuit is faster and often
produces fewer mispredictions than cond-when (bit it's slower than
cond-when-no-or).
- 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-10 11:09 -0600 |
| Message-ID | <P-udnVKsx8UymmTPnZ2dnUVZ_qidnZ2d@supernews.com> |
| In reply to | #28298 |
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, and it means that we're not comparing other versions of thise code with a straightforward jump table. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-10 17:20 +0000 |
| Message-ID | <2014Feb10.182035@mips.complang.tuwien.ac.at> |
| In reply to | #28299 |
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. Fortunately
the GCC disease of miscompiling all non-standard code (except SPEC
benchmarks) has not spread to Forth yet.
> and it
>means that we're not comparing other versions of thise code with a
>straightforward jump table.
Whatever that may be. In any case, even with tail-call elimination
there would be a return at the end of the called word (possibly with
more tail calls in between), so this differs from what a C compiler
classically produces for switch anyway, if that's what you mean with
"straightforward jump table".
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.
Also BTW, if you want a Forth-like language that supports tail-call
elimination and also indirect branching within definitions (for
"straightforward jump tables"), take a look at PAF; not implemented
yet, but there is a concept paper:
http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf
- 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]
Page 6 of 21 — ← Prev page 1 … 4 5 [6] 7 8 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web