Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29282 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-04-04 10:26 -0700 |
| Last post | 2014-12-02 04:54 +0100 |
| Articles | 20 on this page of 432 — 42 participants |
Back to article view | Back to comp.lang.forth
Epic Fail Jason Damisch <jasondamisch@yahoo.com> - 2014-04-04 10:26 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-04 12:42 -0500
Re: Epic Fail forthisit@gmail.com - 2014-04-04 11:09 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-04 22:09 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:44 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 09:42 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 10:47 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-05 15:25 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:29 +0000
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 12:35 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 15:54 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 12:43 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:16 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 13:00 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 21:08 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 15:17 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 00:17 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-09 22:42 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 00:06 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-10 16:00 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:35 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-10 17:51 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 21:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-11 23:10 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:18 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:23 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:52 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:14 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 19:21 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:25 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 16:12 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 09:48 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-12 10:23 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:51 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 13:00 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:29 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:56 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 00:25 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 10:50 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 16:53 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-14 02:32 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 17:59 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 02:00 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 18:30 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 14:21 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 21:12 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 12:49 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:02 -0700
Automatic scoping of locals (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:49 +0000
Re: Automatic scoping of locals (was: Epic Fail) hughaguilar96@yahoo.com - 2014-05-02 22:28 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 03:04 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:23 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 21:42 +0200
Re: Epic Fail Spam@ControlQ.com - 2014-04-11 16:13 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 22:15 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 16:10 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 18:42 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 23:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 04:05 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:57 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 11:56 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 14:53 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 07:26 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 21:21 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 04:07 -0500
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-14 09:55 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-14 22:04 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 04:10 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 02:40 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 06:41 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:20 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 12:21 +0000
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:30 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-15 20:04 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 23:50 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-15 21:31 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:55 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-16 14:50 +0100
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-16 06:06 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-19 17:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:35 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 00:19 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:29 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:45 -0400
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:49 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 13:07 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 20:16 -0400
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-23 14:41 -1000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-24 17:10 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-24 15:14 -0400
@ and optimization (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:40 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 06:13 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 15:26 +0000
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 09:03 -0700
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:45 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 11:15 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:22 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:38 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 11:38 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 14:35 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 09:59 -0500
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:14 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:30 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:05 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:27 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:39 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 18:07 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:24 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 13:00 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 11:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:12 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 03:52 -0500
Re: @ and optimization Mark Wills <markwills1970@gmail.com> - 2014-04-29 03:09 -0700
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 09:24 -0500
Re: @ and optimization "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 08:36 -1000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 10:18 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:38 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 10:21 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 15:41 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 12:26 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 10:44 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 09:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 17:48 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 03:55 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-01 14:21 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 10:11 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-01 14:20 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 12:38 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:17 +0200
Re: @ and optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:21 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:20 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:02 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 20:55 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:28 -0500
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:31 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:27 +0000
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:23 +0000
Re: @ and optimization hughaguilar96@yahoo.com - 2014-04-28 21:32 -0700
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 08:50 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-26 22:52 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 20:33 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:53 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:05 -0400
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 21:34 +0100
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 13:37 -0700
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 22:03 +0100
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:38 +0000
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:24 +0100
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:48 -0500
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:09 +0100
Re: @ and optimization (was: Epic Fail) hughaguilar96@yahoo.com - 2014-04-28 21:24 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-24 19:17 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:27 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-25 23:44 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-26 14:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 15:04 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 09:58 +0100
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 10:16 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 05:06 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:16 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-26 03:43 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 14:24 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:58 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:46 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 00:41 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:54 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:17 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:08 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 13:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 09:11 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:12 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:00 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:08 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:41 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:45 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:52 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 21:52 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:31 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-27 13:48 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:02 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 22:19 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 10:28 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:02 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 18:57 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-15 05:05 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 22:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:34 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-14 13:22 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 10:08 -0500
Re: Epic Fail Spam@ControlQ.com - 2014-04-14 11:59 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-17 16:56 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-17 15:16 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-17 23:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-18 04:38 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-18 09:17 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:44 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:41 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 16:55 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-18 19:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:52 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 12:21 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:36 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-20 08:17 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:35 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 10:51 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 19:54 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-22 20:47 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-19 11:34 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:05 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 12:38 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:42 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 12:11 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:23 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:58 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-21 10:21 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 04:58 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:05 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:12 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-20 19:47 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:03 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 11:51 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:28 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 15:02 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 13:23 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-22 19:19 +0200
Re: Epic Fail Todd Hughes <noemail@dontemailme.org> - 2014-04-10 11:24 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 06:55 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 15:50 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 11:02 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:31 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-11 03:55 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:08 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:03 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 17:45 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:16 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 18:59 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 19:11 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-11 12:05 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 22:03 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 20:18 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 21:44 -0400
Re: Epic Fail visualforth@rocketmail.com - 2014-04-11 14:00 -0700
Re: Epic Fail Matthias Trute <matthias.trute@gmail.com> - 2014-04-12 01:04 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-11-30 01:47 -0800
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 16:12 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-04 23:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:52 +0200
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 16:13 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-08 06:37 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 01:12 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:16 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-04 17:41 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-05 02:49 +0200
Re: Epic Fail Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-04-04 17:46 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:59 -1000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-05 08:51 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-05 14:45 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-05 16:01 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 19:22 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 10:46 +0100
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 13:20 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 19:58 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 12:28 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-06 16:40 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-06 22:04 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 23:25 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 23:48 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:08 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:34 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:29 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:01 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:29 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:33 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 19:33 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:40 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:25 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 20:19 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:23 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 03:24 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:18 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:20 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 14:49 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 08:43 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 20:27 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 02:57 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:00 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 16:10 +0200
Re: Epic Fail m.a.m.hendrix@tue.nl - 2014-04-07 07:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:07 -0700
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:13 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:40 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-07 01:02 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 10:49 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 19:01 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:13 -1000
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 20:34 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 12:04 -0700
[OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 00:42 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:14 -0700
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:15 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:10 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:35 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:17 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-06 16:48 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:30 -0700
Re: Epic Fail Lars Brinkhoff <lars.spam@nocrew.org> - 2014-04-07 11:26 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:21 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-07 17:54 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 12:14 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:49 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 09:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:43 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 12:53 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 00:09 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-06 13:12 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 07:55 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:18 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 08:21 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:30 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 22:12 +0200
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 12:08 -1000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 22:03 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-07 01:29 -0700
locals in nested definitions (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:57 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-07 11:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:54 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 00:04 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 14:12 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 21:23 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-07 19:33 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-07 23:52 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-08 09:07 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:35 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:21 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 16:33 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 23:41 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 22:47 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 10:43 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 07:22 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 10:12 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 08:58 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:02 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 23:07 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:21 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 15:32 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 17:46 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 01:06 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:06 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 02:56 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:24 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-09 02:22 -0400
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-09 17:07 +0300
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 03:48 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-07 07:17 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:52 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-07 03:53 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:24 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:45 -0700
Re: Epic Fail kerdezixe@gmail.com - 2014-04-29 11:15 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 11:21 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:46 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:27 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:13 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 00:04 -0700
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-30 00:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-30 23:30 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 16:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-01 03:33 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-05-01 04:04 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 16:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 03:56 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:08 -0500
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 02:30 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 06:45 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 22:02 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 04:04 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-02 08:12 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-02 22:33 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-05-02 15:19 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-03 04:30 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 09:53 +0000
Forth on JVM (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-30 09:24 +0000
Re: Forth on JVM (was: Epic Fail) jacko <jackokring@gmail.com> - 2014-04-30 17:14 -0700
Re: Forth on JVM (was: Epic Fail) jacko <jackokring@gmail.com> - 2014-04-30 17:27 -0700
Re: Forth on JVM (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-01 15:25 +0000
Re: Forth on JVM (was: Epic Fail) "Peter Knaggs" <pjk@bcs.org.uk> - 2014-05-03 08:28 +0100
Re: Forth on JVM (was: Epic Fail) "Peter Knaggs" <pjk@bcs.org.uk> - 2014-05-01 07:52 +0100
Re: Forth on JVM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-01 04:06 -0500
Re: Forth on JVM Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-05-01 14:28 +0200
Re: Epic Fail AKK <akk@nospam.org> - 2014-04-29 20:48 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:09 +0000
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 09:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:43 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 11:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 22:52 -0700
Re: Epic failure (was Epic Fail) "WJ" <w_a_x_man@yahoo.com> - 2014-11-29 20:13 +0000
Re: Epic failure (was Epic Fail) C G Montgomery <cgm@physics.utoledo.edu> - 2014-11-29 17:15 -0500
Re: Epic failure (was Epic Fail) Pablo Hugo Reda <pabloreda@gmail.com> - 2014-11-29 14:20 -0800
Re: Epic failure awegel@arcor.de (Alexander Wegel) - 2014-11-29 23:35 +0100
Re: Epic failure (was Epic Fail) Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-30 00:31 +0100
Re: Epic failure (was Epic Fail) Julian Fondren <julian.fondren@gmail.com> - 2014-11-29 17:41 -0800
Re: Epic failure (was Epic Fail) mhx@iae.nl - 2014-11-30 00:04 -0800
Re: Epic failure (was Epic Fail) mhx@iae.nl - 2014-11-30 00:09 -0800
Re: Epic failure (was Epic Fail) Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-30 17:22 +0100
Re: Epic failure (was Epic Fail) "WJ" <w_a_x_man@yahoo.com> - 2014-11-30 02:13 +0000
Re: Epic failure (was Epic Fail) Julian Fondren <julian.fondren@gmail.com> - 2014-11-29 18:55 -0800
Re: Epic failure (was Epic Fail) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-30 16:50 +0000
Re: Epic failure (was Epic Fail) Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-01 01:22 +0100
Re: Epic failure (was Epic Fail) Melzzzzz <mel@zzzzz.com> - 2014-12-02 06:00 +0100
Re: Epic failure (was Epic Fail) Melzzzzz <mel@zzzzz.com> - 2014-12-02 06:37 +0100
Re: Epic failure (was Epic Fail) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-02 12:28 +0000
Re: Epic failure Paul Rubin <no.email@nospam.invalid> - 2014-12-02 18:03 -0800
Re: Epic failure (was Epic Fail) the_gavino_himself <visphatesjava@gmail.com> - 2014-12-05 10:10 -0800
Re: Epic failure (was Epic Fail) rickman <gnuarm@gmail.com> - 2014-12-05 16:23 -0500
Re: Epic failure (was Epic Fail) Jason Damisch <jasondamisch@yahoo.com> - 2014-12-05 13:46 -0800
Re: Epic failure (was Epic Fail) "WJ" <w_a_x_man@yahoo.com> - 2014-12-01 07:54 +0000
Re: Epic failure awegel@arcor.de (Alexander Wegel) - 2014-12-01 14:02 +0100
Re: Epic failure hughaguilar96@gmail.com - 2014-12-01 15:04 -0800
Re: Epic failure awegel@arcor.de (Alexander Wegel) - 2014-12-02 04:54 +0100
Page 7 of 22 — ← Prev page 1 … 5 6 [7] 8 9 … 22 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-29 15:41 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr29.174103@mips.complang.tuwien.ac.at> |
| In reply to | #29965 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>OK. My take on it is much like Elizabeth's: if you're doing something
>>>outside the scope of the standard, you might have to disable an
>>>optimizer or in some way tell it what you're doing.
...
>> Concerning your appeal to Elizabeth Rather's authority: citation
>> needed.
>
>I did not appeal to anyone's authority. I agreed with Elizabeth when
>she said
>|On 4/23/14 2:16 PM, Rod Pemberton wrote:
>|> On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl
>|> <anton@mips.complang.tuwien.ac.at> wrote:
>|>
>|> [volatile issues in Forth]
>|>
>|>> In any case, if the programmer wants to write "foo @ dup", they can do
>|>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @
>|>> dup", and if there are any reasons not to do it, we should refrain
>|>> from it.
>|>
>|> How do you tell a Forth optimizer to selectively not optimize
>|> "foo @ foo @" into "foo @ dup"? Forth has no keyword like
>|> "volatile" in C to say: "Do not optimize this code."
>|
>|All the optimizing Forths I know have ways to turn the optimizer off and
>|on. It's pretty much essential, for many reasons.
I don't read anything about "outside the scope of the standard" here.
>> For other cases it's the same. You know what behaviour programmers
>> expect, and you implement it in the non-optimizing case.
>
>Well, this is in effect to forbid optimization.
No, there are many optimizations that do not change program behaviour
at all.
Also, there are also transformations that can change behaviour of some
programs, but do not change the behaviour that programmers expect and
rely on. E.g., gcc-2.x was quite effective at these kinds of
transformations.
>While this may be
>your personal preference, that is all it is.
If it was my personal preference, I would just turn off optimization
and be happy.
>Forth is, IMO, far more
>fexible than that, and Forth users can cope with optimizing compilers
>and occasionally switch them off.
Unfortunately, your "take" that one should disable the "optimizer"
when one does "something outside the scope of the standard" means
something quite different than "occasionally". Also, the general
concept has two problems:
1) It makes miscompilation the default. The next version of the
compiler may have a new "optimization", and may miscompile your
program that compiles as intended with the present version. So, to be
future-proof, you have to turn off the optimizer completely.
2) "Turning off the optimizer" or turning it on is very blunt. It
does not tell the compiler or anyone else what behaviour the
programmer expects of the program.
It's better to compile as intended by default. And if there is some
transformation that would benefit a significant number of programs,
but break others, give the programmer a way to hint to the compiler
that he does not rely on the behaviour that would break. An example
is the READ-ONLY hint that I mentioned earlier.
- 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-04-29 12:26 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <boOdnTRVDZQ0fcLOnZ2dnUVZ7o6dnZ2d@supernews.com> |
| In reply to | #29966 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>OK. My take on it is much like Elizabeth's: if you're doing something >>>>outside the scope of the standard, you might have to disable an >>>>optimizer or in some way tell it what you're doing. > ... >>> Concerning your appeal to Elizabeth Rather's authority: citation >>> needed. >> >>I did not appeal to anyone's authority. I agreed with Elizabeth when >>she said > >>|On 4/23/14 2:16 PM, Rod Pemberton wrote: >>|> On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl >>|> <anton@mips.complang.tuwien.ac.at> wrote: >>|> >>|> [volatile issues in Forth] >>|> >>|>> In any case, if the programmer wants to write "foo @ dup", they can do >>|>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @ >>|>> dup", and if there are any reasons not to do it, we should refrain >>|>> from it. >>|> >>|> How do you tell a Forth optimizer to selectively not optimize >>|> "foo @ foo @" into "foo @ dup"? Forth has no keyword like >>|> "volatile" in C to say: "Do not optimize this code." >>| >>|All the optimizing Forths I know have ways to turn the optimizer off and >>|on. It's pretty much essential, for many reasons. > > I don't read anything about "outside the scope of the standard" here. Ah, okay. That seems like a nitpick to me, but I agree that she did not mention the scope of the standard. I was referring to the need sometimes to turn the optimizer off. >>> For other cases it's the same. You know what behaviour programmers >>> expect, and you implement it in the non-optimizing case. >> >>Well, this is in effect to forbid optimization. > > No, there are many optimizations that do not change program behaviour > at all. Well, as discussed, that's not really true if you allow non-standard programs. I suspect that any optimization may change some non- standard program. >>While this may be your personal preference, that is all it is. > > If it was my personal preference, I would just turn off optimization > and be happy. In what sense is it more than your personal preference? >>Forth is, IMO, far more [flexible] than that, and Forth users can >>cope with optimizing compilers and occasionally switch them off. > > Unfortunately, your "take" that one should disable the "optimizer" > when one does "something outside the scope of the standard" means > something quite different than "occasionally". Also, the general > concept has two problems: > > 1) It makes miscompilation the default. Not necessarily, no: optimization does not have to be on by default. (And I reject the word "miscompilation" in this context, but you knew that.) > The next version of the compiler may have a new "optimization", and > may miscompile your program that compiles as intended with the > present version. So, to be future-proof, you have to turn off the > optimizer completely. If your program does a bunch of clever things and assumes nonstandard behaviour, this might be a good precaution. > 2) "Turning off the optimizer" or turning it on is very blunt. It > does not tell the compiler or anyone else what behaviour the > programmer expects of the program. Indeed. That's why I was suggesting some more fine-grained control of optimization, which is where this conversation started. > It's better to compile as intended by default. You can't know what some user might intend. Maybe the user actually wants optimizations that reduce memory traffic, even at the risk of deleting some memory accesses. > And if there is some transformation that would benefit a significant > number of programs, but break others, give the programmer a way to > hint to the compiler that he does not rely on the behaviour that > would break. An example is the READ-ONLY hint that I mentioned > earlier. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-30 10:44 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr30.124433@mips.complang.tuwien.ac.at> |
| In reply to | #29967 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>OK. My take on it is much like Elizabeth's: if you're doing something
>>>>>outside the scope of the standard, you might have to disable an
>>>>>optimizer or in some way tell it what you're doing.
>> ...
>>>> Concerning your appeal to Elizabeth Rather's authority: citation
>>>> needed.
>>>
>>>I did not appeal to anyone's authority. I agreed with Elizabeth when
>>>she said
>>
>>>|On 4/23/14 2:16 PM, Rod Pemberton wrote:
>>>|> On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl
>>>|> <anton@mips.complang.tuwien.ac.at> wrote:
>>>|>
>>>|> [volatile issues in Forth]
>>>|>
>>>|>> In any case, if the programmer wants to write "foo @ dup", they can do
>>>|>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @
>>>|>> dup", and if there are any reasons not to do it, we should refrain
>>>|>> from it.
>>>|>
>>>|> How do you tell a Forth optimizer to selectively not optimize
>>>|> "foo @ foo @" into "foo @ dup"? Forth has no keyword like
>>>|> "volatile" in C to say: "Do not optimize this code."
>>>|
>>>|All the optimizing Forths I know have ways to turn the optimizer off and
>>>|on. It's pretty much essential, for many reasons.
>>
>> I don't read anything about "outside the scope of the standard" here.
>
>Ah, okay. That seems like a nitpick to me
Once upon a time I would have thought so, too, but you have convinced
me otherwise. There is a big difference between the language that
programs are written in and what is specified in the standard; and
that difference means that virtually every real-world program is
"outside the scope of the standard". And therefore an "optimizer"
that is designed to miscompile everything "outside the scope of the
standard" is a bad idea, and one would have to turn it off for every
real-world program.
>> No, there are many optimizations that do not change program behaviour
>> at all.
>
>Well, as discussed, that's not really true if you allow non-standard
>programs. I suspect that any optimization may change some non-
>standard program.
Please present programs that would change behaviour when the following
optimizations are applied:
3 + 4 + => 7 +
swap + => +
drop drop => 2drop
>>>While this may be your personal preference, that is all it is.
>>
>> If it was my personal preference, I would just turn off optimization
>> and be happy.
>
>In what sense is it more than your personal preference?
So now you are down to loaded questions. Will you ask me next whether
I have stopped beating my wife?
>>>Forth is, IMO, far more [flexible] than that, and Forth users can
>>>cope with optimizing compilers and occasionally switch them off.
>>
>> Unfortunately, your "take" that one should disable the "optimizer"
>> when one does "something outside the scope of the standard" means
>> something quite different than "occasionally". Also, the general
>> concept has two problems:
>>
>> 1) It makes miscompilation the default.
>
>Not necessarily, no: optimization does not have to be on by default.
>(And I reject the word "miscompilation" in this context, but you knew
>that.)
Yes, I know that you want to ignore the difference between optimizing
the intended behaviour of the program and changing the intended
behaviour.
Yes, if we are only given a choice between an "optimizer" that
miscompiles previously working code, and no optimization at all, then
turning off optimization is a good idea in certain settings (e.g.,
when releasing a program in source code). But a better idea is to let
the optimizer only perform the same optimizations as in the previous
version by default, and let the programmer enable the new stuff
explicitly, either through a hint in the program, or through a
compiler flag (maybe something as simple as having a
-O<compiler-version> flag).
>> The next version of the compiler may have a new "optimization", and
>> may miscompile your program that compiles as intended with the
>> present version. So, to be future-proof, you have to turn off the
>> optimizer completely.
>
>If your program does a bunch of clever things and assumes nonstandard
>behaviour, this might be a good precaution.
For standards like Forth and C virtually every real-world program
exercises non-standard behaviour. So you are suggesting that
optimization should be turned off for real-world programs. Not a very
useful feature, then.
>> It's better to compile as intended by default.
>
>You can't know what some user might intend.
Sure I can: the behaviour exhibited in the "optimization off" case is
the intended behaviour, as we have discussed here.
>Maybe the user actually
>wants optimizations that reduce memory traffic, even at the risk of
>deleting some memory accesses.
Sure, as long as the program behaves the same, users want their
programs to run fast in little memory; and when accessing cached
non-shared memory, optimizing multiple fetches from the same address
without intervening stores into just one memory load is a valid
optimization. But in the case of memory-mapped I/O registers, it does
not take psychic powers to know that "foo @ foo @" is intended to
produce two memory loads; here the programmer certainly does not want
to "reduce memory traffic".
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-30 09:18 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <BPSdnaRFJrLam_zOnZ2dnUVZ_uednZ2d@supernews.com> |
| In reply to | #30008 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>OK. My take on it is much like Elizabeth's: if you're doing something >>>>>>outside the scope of the standard, you might have to disable an >>>>>>optimizer or in some way tell it what you're doing. >>> ... >>>>> Concerning your appeal to Elizabeth Rather's authority: citation >>>>> needed. >>>> >>>>I did not appeal to anyone's authority. I agreed with Elizabeth when >>>>she said >>> >>>>|On 4/23/14 2:16 PM, Rod Pemberton wrote: >>>>|> On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl >>>>|> <anton@mips.complang.tuwien.ac.at> wrote: >>>>|> >>>>|> [volatile issues in Forth] >>>>|> >>>>|>> In any case, if the programmer wants to write "foo @ dup", they can do >>>>|>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @ >>>>|>> dup", and if there are any reasons not to do it, we should refrain >>>>|>> from it. >>>>|> >>>>|> How do you tell a Forth optimizer to selectively not optimize >>>>|> "foo @ foo @" into "foo @ dup"? Forth has no keyword like >>>>|> "volatile" in C to say: "Do not optimize this code." >>>>| >>>>|All the optimizing Forths I know have ways to turn the optimizer off and >>>>|on. It's pretty much essential, for many reasons. >>> >>> I don't read anything about "outside the scope of the standard" here. >> >>Ah, okay. That seems like a nitpick to me > > Once upon a time I would have thought so, too, but you have convinced > me otherwise. There is a big difference between the language that > programs are written in and what is specified in the standard; and > that difference means that virtually every real-world program is > "outside the scope of the standard". And therefore an "optimizer" > that is designed to miscompile everything "outside the scope of the > standard" is a bad idea, and one would have to turn it off for every > real-world program. But no-one is proposing an "optimizer" that is designed to miscompile everything "outside the scope of the standard". Clearly an implementation could de jure do that, but we're discussing what optimizations are legitimate and reasonable. For example, it would be possible to create an implementation designed to reject all non-standard programs, and such an implementation would be a Standard Forth system. >>> No, there are many optimizations that do not change program behaviour >>> at all. >> >>Well, as discussed, that's not really true if you allow non-standard >>programs. I suspect that any optimization may change some non- >>standard program. > > Please present programs that would change behaviour when the following > optimizations are applied: > > 3 + 4 + => 7 + > swap + => + > drop drop => 2drop OK, I take your point. There may be some limited optimizations that are possible. Maybe that's the real point: this is the sort of optimization that you're prepared to permit. >>>>While this may be your personal preference, that is all it is. >>> >>> If it was my personal preference, I would just turn off optimization >>> and be happy. >> >>In what sense is it more than your personal preference? > > So now you are down to loaded questions. Will you ask me next > whether I have stopped beating my wife? No, and I don't believe that my question was loaded. It seems reasonable enough to me. You have been making some definite statements about what Forth systems should do. >>>>Forth is, IMO, far more [flexible] than that, and Forth users can >>>>cope with optimizing compilers and occasionally switch them off. >>> >>> Unfortunately, your "take" that one should disable the "optimizer" >>> when one does "something outside the scope of the standard" means >>> something quite different than "occasionally". Also, the general >>> concept has two problems: >>> >>> 1) It makes miscompilation the default. >> >>Not necessarily, no: optimization does not have to be on by default. >>(And I reject the word "miscompilation" in this context, but you knew >>that.) > > Yes, I know that you want to ignore the difference between optimizing > the intended behaviour of the program and changing the intended > behaviour. > > Yes, if we are only given a choice between an "optimizer" that > miscompiles previously working code, and no optimization at all, > then turning off optimization is a good idea in certain settings > (e.g., when releasing a program in source code). But a better idea > is to let the optimizer only perform the same optimizations as in > the previous version by default and let the programmer enable the > new stuff explicitly, either through a hint in the program, or > through a compiler flag (maybe something as simple as having a > -O<compiler-version> flag). OK, that is fair. >>> The next version of the compiler may have a new "optimization", and >>> may miscompile your program that compiles as intended with the >>> present version. So, to be future-proof, you have to turn off the >>> optimizer completely. >> >>If your program does a bunch of clever things and assumes nonstandard >>behaviour, this might be a good precaution. > > For standards like Forth and C virtually every real-world program > exercises non-standard behaviour. So you are suggesting that > optimization should be turned off for real-world programs. No, I'm not. I'm saying that if you depend on side-effects guaranteed neither by an implementation or by a language specification, you might want to turn off the optimizer, set some optimization level, or otherwise control the actions of the optimizer. > Not a very useful feature, then. >>> It's better to compile as intended by default. >> >>You can't know what some user might intend. > > Sure I can: the behaviour exhibited in the "optimization off" case > is the intended behaviour, as we have discussed here. As you have *asserted*. There is a difference. >>Maybe the user actually wants optimizations that reduce memory >>traffic, even at the risk of deleting some memory accesses. > > Sure, as long as the program behaves the same, users want their > programs to run fast in little memory; and when accessing cached > non-shared memory, optimizing multiple fetches from the same address > without intervening stores into just one memory load is a valid > optimization. But in the case of memory-mapped I/O registers, it > does not take psychic powers to know that "foo @ foo @" is intended > to produce two memory loads; here the programmer certainly does not > want to "reduce memory traffic". That's certainly true. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-30 17:48 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr30.194811@mips.complang.tuwien.ac.at> |
| In reply to | #30009 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Once upon a time I would have thought so, too, but you have convinced
>> me otherwise. There is a big difference between the language that
>> programs are written in and what is specified in the standard; and
>> that difference means that virtually every real-world program is
>> "outside the scope of the standard". And therefore an "optimizer"
>> that is designed to miscompile everything "outside the scope of the
>> standard" is a bad idea, and one would have to turn it off for every
>> real-world program.
>
>But no-one is proposing an "optimizer" that is designed to miscompile
>everything "outside the scope of the standard". Clearly an
>implementation could de jure do that, but we're discussing what
>optimizations are legitimate and reasonable.
I have been discussing that. From your side the only thing I have
seen most of the time is justifications for miscompiling everything
outside the scope of the standard, and for not considering any other
point of view (and even when you deviated from that, you soon fell
back). Examples:
|if you're doing something
|outside the scope of the standard, you might have to disable an
|optimizer
|If your program does a bunch of clever things and assumes nonstandard
|behaviour, [turning off the optimizer] might be a good precaution.
|The "as if" rule says that no standard program can tell the difference
|between an optimized and an unoptimized program.
|I don't think it's my definition of the "as if" rule. As far as I'm
|aware it's the only definition of the rule that is logically possible.
|You can only define program equivalence in terms of well-defined
|programs.
And earlier you posted stuff about needing psychic powers to determine
programmer intent.
>OK, I take your point. There may be some limited optimizations that
>are possible. Maybe that's the real point: this is the sort of
>optimization that you're prepared to permit.
I actually find more optimizations acceptable, as I wrote. gcc-2.x
performs a number of optimizations and is very effective (-O3 gave a
speedup factor of 6 on Gforth over -O0 at that time) without
introducing miscompilation. But you don't want to discuss such
reasonable optimizations, claiming that it takes psychic powers to
determine whether they are ok or not; in that case, yes, I prefer a
compiler that does these "limited optimizations" over one that does
none and certainly over one that miscompiles.
>>>>>While this may be your personal preference, that is all it is.
>>>>
>>>> If it was my personal preference, I would just turn off optimization
>>>> and be happy.
>>>
>>>In what sense is it more than your personal preference?
>>
>> So now you are down to loaded questions. Will you ask me next
>> whether I have stopped beating my wife?
>
>No, and I don't believe that my question was loaded.
It presupposes the that I want to forbid optimization.
>> Sure I can: the behaviour exhibited in the "optimization off" case
>> is the intended behaviour, as we have discussed here.
>
>As you have *asserted*. There is a difference.
If "optimization off" does not produce the intended behaviour, then
your repeated suggestions to turn optimization off under various
circumstances make no sense.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-01 03:55 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <Dd-dnbvMs5ttlv_OnZ2dnUVZ_sOdnZ2d@supernews.com> |
| In reply to | #30013 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Once upon a time I would have thought so, too, but you have convinced >>> me otherwise. There is a big difference between the language that >>> programs are written in and what is specified in the standard; and >>> that difference means that virtually every real-world program is >>> "outside the scope of the standard". And therefore an "optimizer" >>> that is designed to miscompile everything "outside the scope of the >>> standard" is a bad idea, and one would have to turn it off for every >>> real-world program. >> >>But no-one is proposing an "optimizer" that is designed to miscompile >>everything "outside the scope of the standard". Clearly an >>implementation could de jure do that, but we're discussing what >>optimizations are legitimate and reasonable. > > I have been discussing that. From your side the only thing I have > seen most of the time is justifications for miscompiling everything > outside the scope of the standard, and for not considering any other > point of view Am I considering your point of view; we wouldn't be having this dicussion otherwise. > (and even when you deviated from that, you soon fell > back). Examples: > > |if you're doing something outside the scope of the standard, you > |might have to disable an optimizer > > |If your program does a bunch of clever things and assumes nonstandard > |behaviour, [turning off the optimizer] might be a good precaution. > > |The "as if" rule says that no standard program can tell the difference > |between an optimized and an unoptimized program. > > |I don't think it's my definition of the "as if" rule. As far as I'm > |aware it's the only definition of the rule that is logically possible. > |You can only define program equivalence in terms of well-defined > |programs. I stand by all of those, particularly the last one. You can only define program equivalence in terms of well-defined programs. If the meaning of a program is not well-defined you cannot say that it is equivalent to some other program. You cannot even say what it means. If you disagree with this, why? > And earlier you posted stuff about needing psychic powers to > determine programmer intent. Well, yes, obviously. >>OK, I take your point. There may be some limited optimizations that >>are possible. Maybe that's the real point: this is the sort of >>optimization that you're prepared to permit. > > I actually find more optimizations acceptable, as I wrote. > > gcc-2.x performs a number of optimizations and is very effective > (-O3 gave a speedup factor of 6 on Gforth over -O0 at that time) > without introducing miscompilation. But you don't want to discuss > such reasonable optimizations Of course I do. > , claiming that it takes psychic powers to determine whether they > are ok or not; So it seems to me. Different programmers have different expectations, so the same programming language construct might be intended to do different things depending which programmer wrote it. > in that case, yes, I prefer a compiler that does these "limited > optimizations" over one that does none and certainly over one that > miscompiles. >>>>>>While this may be your personal preference, that is all it is. >>>>> >>>>> If it was my personal preference, I would just turn off optimization >>>>> and be happy. >>>> >>>>In what sense is it more than your personal preference? >>> >>> So now you are down to loaded questions. Will you ask me next >>> whether I have stopped beating my wife? >> >>No, and I don't believe that my question was loaded. > > It presupposes the that I want to forbid optimization. Oh, I see. I think we've already established that you want to forbid all optimizations that might change the behaviour of a program, even an undefined or nonstandard program. (At least I think that's what you want; I'm sure you'll correct me if that's wrong.) >>> Sure I can: the behaviour exhibited in the "optimization off" case >>> is the intended behaviour, as we have discussed here. >> >>As you have *asserted*. There is a difference. > > If "optimization off" does not produce the intended behaviour, then > your repeated suggestions to turn optimization off under various > circumstances make no sense. Sometimes the intent of the programmer is to have optimization, sometimes not. Your assertion that "optimization off" always best conveys the programmer's intent is therefore untrue. Your view that optimization should never affect a program is IMO hopelessly idealistic. It makes much more sense IMO to provide the programmer with the control they need and accept the fact that some optimizations may affect a program in some edge cases. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-01 14:21 +0200 |
| Subject | Re: @ and optimization |
| Message-ID | <ljte8k$5f6$1@online.de> |
| In reply to | #30028 |
Andrew Haley wrote:
> Oh, I see. I think we've already established that you want to forbid
> all optimizations that might change the behaviour of a program, even
> an undefined or nonstandard program. (At least I think that's what
> you want; I'm sure you'll correct me if that's wrong.)
There's a huge difference between "undefined" and "non-standard", which is
the actual problem. A standard can leave some things open as
implementation-defined. Byte order, number representation, type size,
things like that are obvious candidates for implementation defined stuff. A
program that depends on implementation defined stuff is not-quite-standard
("environmental dependency"), but it is 100% well-defined. The
implementation defines some behavior by making a choice (e.g. how to
represent signed numbers), and that choice defines operations beyond the
scope of the standard. That's a trivial thing, and it makes optimization
like removing if(n > n+1) { ... } illegal, because this obviously changes
the behavior of a program on a two's complement system with wraparound on
overflow. And GCC compiles addition on signed numbers as two's complement
addition with wraparound. This stuff is 100% defined if you use GCC, it's
not undefined. There is no question about the result of this operation.
I've already quoted the C standard: you, as implementer, are responsible for
defining what undefined things in the standard will do on your
implementation - if there is a consistent result of these undefined
operations in your implementation, it is now defined, and you have to stick
to that. If it was defined in previous implementations, and you don't like
it anymore, you have to stick with it for a long time; using new switches
and pragmas to allow the user to choose the new behavior.
Example: In Gforth up to 0.7, IO words were deferred. So you could revector
IO words using IS and ACTION-OF to get the current assigned xt (for
restoring). This is certainly a non-standard behavior, but a useful one.
In Gforth git head, IO words are using an IO vector, which is some sort of
cheap OOP system. You can change all the inputs and all the outputs by just
changing the IO vector pointer - this is a lot better, and it allows the IO
replacement to have state. However, old program still run, because IS and
ACTION-OF still work on these methods - they change the xt in the currently
active IO vector. So we did stick to the previous interface, it's
compatible. This sort of change is allowed, because it doesn't break
programs, and it doesn't surprise the user.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-01 10:11 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <FNOdnYv1ZKGU-f_OnZ2dnUVZ8n2dnZ2d@supernews.com> |
| In reply to | #30033 |
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Oh, I see. I think we've already established that you want to forbid
>> all optimizations that might change the behaviour of a program, even
>> an undefined or nonstandard program. (At least I think that's what
>> you want; I'm sure you'll correct me if that's wrong.)
>
> There's a huge difference between "undefined" and "non-standard",
> which is the actual problem. A standard can leave some things open
> as implementation-defined. Byte order, number representation, type
> size, things like that are obvious candidates for implementation
> defined stuff. A program that depends on implementation defined
> stuff is not-quite-standard ("environmental dependency"), but it is
> 100% well-defined.
That's a good point. I agree that a program which is undefined WRT a
source language may well be well-defined in the context of a
particular implementation. Anton's example of memory-mapped I/O is a
case in point: such accesses may be well-defined on an implementation,
but it's not something a language standard can define.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-01 14:20 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014May1.162022@mips.complang.tuwien.ac.at> |
| In reply to | #30028 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> I have been discussing that. From your side the only thing I have
>> seen most of the time is justifications for miscompiling everything
>> outside the scope of the standard, and for not considering any other
>> point of view
>
>Am I considering your point of view; we wouldn't be having this
>dicussion otherwise.
>
>> (and even when you deviated from that, you soon fell
>> back). Examples:
>>
>> |if you're doing something outside the scope of the standard, you
>> |might have to disable an optimizer
>>
>> |If your program does a bunch of clever things and assumes nonstandard
>> |behaviour, [turning off the optimizer] might be a good precaution.
>>
>> |The "as if" rule says that no standard program can tell the difference
>> |between an optimized and an unoptimized program.
>>
>> |I don't think it's my definition of the "as if" rule. As far as I'm
>> |aware it's the only definition of the rule that is logically possible.
>> |You can only define program equivalence in terms of well-defined
>> |programs.
>
>I stand by all of those, particularly the last one.
>
>You can only define program equivalence in terms of well-defined
>programs. If the meaning of a program is not well-defined you cannot
>say that it is equivalent to some other program. You cannot even say
>what it means.
>
>If you disagree with this, why?
You use "well-defined" interchangeably with "standard". So let's do
the replacement:
|You can only define program equivalence in terms of standard
|programs. If the meaning of a program is not standard you cannot
|say that it is equivalent to some other program. You cannot even say
|what it means.
No, I certainly don't agree with that. Why?
1) Because it's useless. There are virtually no standard programs in
the real world.
2) I define program equivalence based on actual behaviour.
>> And earlier you posted stuff about needing psychic powers to
>> determine programmer intent.
>
>Well, yes, obviously.
Not in the least. The programmer expressed his intent in the program,
getting feedback from the actual behaviour the compiler produces.
There is no psychic power involved in that.
>> gcc-2.x performs a number of optimizations and is very effective
>> (-O3 gave a speedup factor of 6 on Gforth over -O0 at that time)
>> without introducing miscompilation. But you don't want to discuss
>> such reasonable optimizations
>
>Of course I do.
>
>> , claiming that it takes psychic powers to determine whether they
>> are ok or not;
>
>So it seems to me.
Please point out the psych module in gcc-2.x.
> Different programmers have different expectations,
>so the same programming language construct might be intended to do
>different things depending which programmer wrote it.
No, the compiler used by the the programmers produces only one actual
behaviour for the same source code (with the same compiler flags); it
does not produce different things depending on which programmer wrote
it.
>Oh, I see. I think we've already established that you want to forbid
>all optimizations that might change the behaviour of a program, even
>an undefined or nonstandard program. (At least I think that's what
>you want; I'm sure you'll correct me if that's wrong.)
Given that virtually all real-world C and Forth programs are
non-standard (and, in C, exercise "undefined behaviour"), yes, I
certainly don't want an optimizer to change the behaviour of a program
just because it's non-standard.
And yes, not changing any behaviour is a much better starting point
than allowing to change virtually every real-world program in
arbitrary ways (including: changing it into a noop, and "optimizing"
it into an infinite loop).
There are some things for which I don't expect consistent behaviour,
and I believe that others don't expect it, either, for practical
reasons. E.g., I don't expect that reading uninitialized data gives
the same value between runs. These things can be used for some more
optimizations.
>>>> Sure I can: the behaviour exhibited in the "optimization off" case
>>>> is the intended behaviour, as we have discussed here.
>>>
>>>As you have *asserted*. There is a difference.
>>
>> If "optimization off" does not produce the intended behaviour, then
>> your repeated suggestions to turn optimization off under various
>> circumstances make no sense.
>
>Sometimes the intent of the programmer is to have optimization,
>sometimes not.
Performance is not behaviour (at least not as far as optimizations
preserving behaviour is concerned). I don't believe that programmers
rely on behaviour-changing optimizations, but if you know
counterexamples, please present them. When did you last get a
complaint that a programmer had put some "undefined behaviour" in his
program, and the programmer expected the compiler to "optimize" a
finite loop into an infinite loop, but the compiler did not do it?
>Your view that optimization should never affect a program is IMO
>hopelessly idealistic. It makes much more sense IMO to provide the
>programmer with the control they need and accept the fact that some
>optimizations may affect a program in some edge cases.
That would also be ok, if there was a conservative default (not just
-O0), i.e., if the next version of the compiler did not break the
program.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-01 12:38 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <0_WdnS4CTpMMG__OnZ2dnUVZ8o6dnZ2d@supernews.com> |
| In reply to | #30036 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> I have been discussing that. From your side the only thing I have >>> seen most of the time is justifications for miscompiling everything >>> outside the scope of the standard, and for not considering any other >>> point of view >> >>Am I considering your point of view; we wouldn't be having this >>dicussion otherwise. >> >>> (and even when you deviated from that, you soon fell >>> back). Examples: >>> >>> |if you're doing something outside the scope of the standard, you >>> |might have to disable an optimizer >>> >>> |If your program does a bunch of clever things and assumes nonstandard >>> |behaviour, [turning off the optimizer] might be a good precaution. >>> >>> |The "as if" rule says that no standard program can tell the difference >>> |between an optimized and an unoptimized program. >>> >>> |I don't think it's my definition of the "as if" rule. As far as I'm >>> |aware it's the only definition of the rule that is logically possible. >>> |You can only define program equivalence in terms of well-defined >>> |programs. >> >>I stand by all of those, particularly the last one. >> >>You can only define program equivalence in terms of well-defined >>programs. If the meaning of a program is not well-defined you cannot >>say that it is equivalent to some other program. You cannot even say >>what it means. >> >>If you disagree with this, why? > > You use "well-defined" interchangeably with "standard". I apologize for that. It's not deliberate. Or rather, it depends on context: of course a program is well-defined if it is completely defined by a language standard, but even one which is not may be well-defined on a particular implementation. > So let's do the replacement: No, let's not. :-) >>> And earlier you posted stuff about needing psychic powers to >>> determine programmer intent. >> >>Well, yes, obviously. > > Not in the least. The programmer expressed his intent in the program, Not really, no. >>> gcc-2.x performs a number of optimizations and is very effective >>> (-O3 gave a speedup factor of 6 on Gforth over -O0 at that time) >>> without introducing miscompilation. But you don't want to discuss >>> such reasonable optimizations >> >>Of course I do. >> >>> , claiming that it takes psychic powers to determine whether they >>> are ok or not; >> >>So it seems to me. > > Please point out the psych module in gcc-2.x. It seems to me that gcc-2.x was well aligned with your inituition about what C programs should do, that's all. >>Different programmers have different expectations, so the same >>programming language construct might be intended to do different >>things depending which programmer wrote it. > > No, the compiler used by the the programmers produces only one > actual behaviour for the same source code (with the same compiler > flags); and the same machine, etc. > it does not produce different things depending on which > programmer wrote it. Sure, but that is a very different question. >>Oh, I see. I think we've already established that you want to >>forbid all optimizations that might change the behaviour of a >>program, even an undefined or nonstandard program. (At least I >>think that's what you want; I'm sure you'll correct me if that's >>wrong.) > > Given that virtually all real-world C and Forth programs are > non-standard (and, in C, exercise "undefined behaviour"), yes, I > certainly don't want an optimizer to change the behaviour of a program > just because it's non-standard. > > And yes, not changing any behaviour is a much better starting point > than allowing to change virtually every real-world program in > arbitrary ways (including: changing it into a noop, and "optimizing" > it into an infinite loop). > > There are some things for which I don't expect consistent behaviour, > and I believe that others don't expect it, either, for practical > reasons. E.g., I don't expect that reading uninitialized data gives > the same value between runs. These things can be used for some more > optimizations. Good. We have established the principle that in some places an optimizer might change the behaviour of a program that is not well-defined. We probably disagree about which set of undefined programs may have their behaviour changed, though. Still, from my point of view this is a huge advance. >>>>> Sure I can: the behaviour exhibited in the "optimization off" case >>>>> is the intended behaviour, as we have discussed here. >>>> >>>>As you have *asserted*. There is a difference. >>> >>> If "optimization off" does not produce the intended behaviour, then >>> your repeated suggestions to turn optimization off under various >>> circumstances make no sense. >> >>Sometimes the intent of the programmer is to have optimization, >>sometimes not. > > Performance is not behaviour (at least not as far as optimizations > preserving behaviour is concerned). I don't believe that > programmers rely on behaviour-changing optimizations, but if you > know counterexamples, please present them. That's not my point: rather that many people, myself included, are willing to accept changes in behaviour to undefined programs in exchange for faster well-defined programs. And you accept that principle too in some cases, as you wrote above. > When did you last get a complaint that a programmer had put some > "undefined behaviour" in his program, and the programmer expected > the compiler to "optimize" a finite loop into an infinite loop, but > the compiler did not do it? I don't think most people are stupid enough to say that. :-) >>Your view that optimization should never affect a program is IMO >>hopelessly idealistic. It makes much more sense IMO to provide the >>programmer with the control they need and accept the fact that some >>optimizations may affect a program in some edge cases. > > That would also be ok, if there was a conservative default (not just > -O0), i.e., if the next version of the compiler did not break the > program. As I said, I don't have any say in what implementers might do by default: it's none of my business. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-29 20:17 +0200 |
| Subject | Re: @ and optimization |
| Message-ID | <ljoqat$ufc$1@online.de> |
| In reply to | #29966 |
Anton Ertl wrote: > Unfortunately, your "take" that one should disable the "optimizer" > when one does "something outside the scope of the standard" means > something quite different than "occasionally". Also, the general > concept has two problems: > > 1) It makes miscompilation the default. The next version of the > compiler may have a new "optimization", and may miscompile your > program that compiles as intended with the present version. So, to be > future-proof, you have to turn off the optimizer completely. To add some experience with VFX: When I started porting MINOS, VFX miscompiled a considerable part of it and I had to turn of significant parts of the optimizer. The result of the discussion with Stephen was that he fixed those bugs, and I could turn on the optimizer again, resulting in better speed. VFX is certainly an experiemnt - it's one of the few Forth compilers that do a lot of optimizations. In so far it is obvious why some attempts to do these optimizations were wrong and had to be rewritten. This is a normal approach to develop programs, especially Forth programs ;-). We certainly had discussions about return stack manipulations using the actual return address, which is a non-standard technique, but actually works in VFX. The tone of this sort of discussion isn't "won't fix, because non-standard", but how the compiler can detect them, and turn some optimizations off - with manual fallbacks as last resort. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-04-29 19:21 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <535ff9ca.533187876@news.demon.co.uk> |
| In reply to | #29970 |
On Tue, 29 Apr 2014 20:17 +0200, Bernd Paysan <bernd.paysan@gmx.de> wrote: >To add some experience with VFX: When I started porting MINOS, VFX >miscompiled a considerable part of it and I had to turn of significant parts >of the optimizer. The result of the discussion with Stephen was that he >fixed those bugs, and I could turn on the optimizer again, resulting in >better speed. Actually a lot of this was because there is currently no way to tell a Forth compiler that the word is actually in two portions both of which need something similar to an xt. That's one of things that DOES> does. And then there were a few bugs by Bernd ... >VFX is certainly an experiemnt - it's one of the few Forth compilers that do >a lot of optimizations. In so far it is obvious why some attempts to do >these optimizations were wrong and had to be rewritten. This is a normal >approach to develop programs, especially Forth programs ;-). As I repeatedly say here, you can never protect against the ingenuity of a good Forth programmer ... >We certainly >had discussions about return stack manipulations using the actual return >address, which is a non-standard technique, but actually works in VFX. By design. >The >tone of this sort of discussion isn't "won't fix, because non-standard", but >how the compiler can detect them, and turn some optimizations off - with >manual fallbacks as last resort. The "won't fix, because non-standard" approach would be a disaster in Forth. Its also non-productive because it breaks the principle of least surprise/astonishment. http://en.wikipedia.org/wiki/Principle_of_least_astonishment 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-29 23:20 +0200 |
| Subject | Re: @ and optimization |
| Message-ID | <ljp53b$9rq$1@online.de> |
| In reply to | #29977 |
Stephen Pelc wrote: > On Tue, 29 Apr 2014 20:17 +0200, Bernd Paysan <bernd.paysan@gmx.de> > wrote: > >>To add some experience with VFX: When I started porting MINOS, VFX >>miscompiled a considerable part of it and I had to turn of significant >>parts >>of the optimizer. The result of the discussion with Stephen was that he >>fixed those bugs, and I could turn on the optimizer again, resulting in >>better speed. > > Actually a lot of this was because there is currently no way to tell > a Forth compiler that the word is actually in two portions both of > which need something similar to an xt. That's one of things that > DOES> does. In the meantime, there is: quotations. It isn't yet standardized, though. IMHO it is the solution to all the problems I tried to solve by using the return address. > And then there were a few bugs by Bernd ... Sure. We all write bugs. I'm always happy if someone finds them, and reports them in a way that allows to fix them. I like to have a bug-free system in the end. >>VFX is certainly an experiemnt - it's one of the few Forth compilers that >>do >>a lot of optimizations. In so far it is obvious why some attempts to do >>these optimizations were wrong and had to be rewritten. This is a normal >>approach to develop programs, especially Forth programs ;-). > > As I repeatedly say here, you can never protect against the ingenuity > of a good Forth programmer ... Hehe. >>We certainly >>had discussions about return stack manipulations using the actual return >>address, which is a non-standard technique, but actually works in VFX. > > By design. Fortunately. >>The >>tone of this sort of discussion isn't "won't fix, because non-standard", >>but how the compiler can detect them, and turn some optimizations off - >>with manual fallbacks as last resort. > > The "won't fix, because non-standard" approach would be a disaster in > Forth. Its also non-productive because it breaks the principle of > least surprise/astonishment. > http://en.wikipedia.org/wiki/Principle_of_least_astonishment Indeed. It's also a disaster elsewhere. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-30 03:02 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <ruadnZel-bOXM_3OnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #29970 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > The tone of this sort of discussion isn't "won't fix, because > non-standard", but how the compiler can detect them, and turn some > optimizations off - with manual fallbacks as last resort. Indeed. There are several layers to this: Whether an optimization is in theory allowed. Whether an optimization should be performed. Whether an optimization should be performed by default. etc. The first is, I think, the easiest, except for some edge cases that weren't thought of at the time the Forth standard was written. The second has to do with what Forth programmers are entiled to expect, and what they do expect. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-26 20:55 +0200 |
| Subject | Re: @ and optimization |
| Message-ID | <ljgvfa$6tk$1@online.de> |
| In reply to | #29876 |
Andrew Haley wrote: > ... then what @ does is not defined by the language, but by the > hardware; or rather a combination of the hardware and the language > implementation. The standard @ has ( a-addr -- x ) with x being the value stored at a-addr, so if you follow the logic that the language is fully defined by the standard, the only way to get x there is by using ! ( x a-addr -- ). And since we don't have a standard multitasker, there's no way a standard program can create a "behind the back" store between these two @s. Looking through the standard, there is an incomplete attempt to define the memory as array of address units. Incomplete in so far that it should be defined that storing a value somewhere will split the value into address- unit-sized chunks, and overwrite all AUs starting with the address up to the size of the object (char, cell, float, ...). Otherwise people could think that storing a character would not change the float stored at the same address or something like that. And of course if the memory you are addressing hasn't been allocated from the dictionary or the heap, but e.g. some memory mapped IO, it's the hardware which defines the semantics. This is usually outside the scope of a standard. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-27 03:28 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <_5adnW19XLFeIsHOnZ2dnUVZ_u2dnZ2d@supernews.com> |
| In reply to | #29885 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >> ... then what @ does is not defined by the language, but by the >> hardware; or rather a combination of the hardware and the language >> implementation. > > The standard @ has ( a-addr -- x ) with x being the value stored at a-addr, > so if you follow the logic that the language is fully defined by the > standard, the only way to get x there is by using ! ( x a-addr -- ). And > since we don't have a standard multitasker, there's no way a standard > program can create a "behind the back" store between these two @s. That's true, and it is a big problem for any programming language in this century. However, it's not quite as bad as all that, as I discovered when I wrote the Forth transactional memory library: to my surprise there was almost no porting to be done between SwiftForth and VFX, even in the very delicate (and supposedly non-portable) area of concurrency. > And of course if the memory you are addressing hasn't been allocated > from the dictionary or the heap, but e.g. some memory mapped IO, > it's the hardware which defines the semantics. This is usually > outside the scope of a standard. Exactly. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-27 13:31 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <535d06ab$0$25076$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29866 |
In article <4dOdncefNIFGVMbOnZ2dnUVZ_s2dnZ2d@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: >>>Do we agree that Forth, as defined, uses "as if" semantics? I think >>>we must, because no-one is suggesting that the stack really has to be >>>implemented as a stack >> >> You mean, as a memory-area plus stack pointer (as on most hardware)? >> As a hardware stack (as on Chuck Moore's chips)? >> >>>all stack accesses may be converted to a >>>series of register moves. >> >> Not in general. > >Point taken. > >>>So, "as if" semantics apply, and merging >>>memory accesses is arguably a legitimate thing for a compiler to do. >>>You can only reasonably describe this as "miscompiling" if you define >>>your memory model. >> >> That's not necessary. If it produces a different behaviour than the >> original code, it's not a legitimate thing for a compiler to do. >> That follows directly from the as-if rule. No need for me to define >> a memory model; that has been done by the hardware maker. >> >> Your suggestion that an "optimization barrier" would be needed is an >> admission that the as-if rule does not hold for the "optimization". > >The "as if" rule says that no standard program can tell the difference >between an optimized and an unoptimized program. If any standard >program can tell the difference, then the optimizer is broken. But no >standard program can tell the difference between "foo @ foo @" and >"foo @ dup", except perhaps by measuring speed. This is not entirely accurate. A standard program can give a resource exception, e.g. a stack overflow. Now an optimized program that has the top of stack in a register, can use a slightly smaller stack area, and run to completion without exception. This kind of difference doesn't damn the optimiser. In general resource exceptions like memory overflow are not taken into account properly in this whole discussion. In particular the question of how large an int is, is in fact a resource matter, and a proper high level language abstracts from that. That makes C into a portable assembler from the getgo, not a high level language. > >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-04-28 15:27 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr28.172730@mips.complang.tuwien.ac.at> |
| In reply to | #29918 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> A standard program can give a resource
>exception, e.g. a stack overflow. Now an optimized program that has
>the top of stack in a register, can use a slightly smaller stack
>area, and run to completion without exception. This kind of difference
>doesn't damn the optimiser.
Actually, in Gforth it is the other way around: gforth-fast arranges
the stack such that accessing a few elements below the bottom of the
stack does not trap (that's because it might load these values into
registers (speculatively) even though the stack is empty), whereas
with the debugging engine gforth every stack access below the bottom
traps. As a result, on the other end of the stack, gforth-fast can
trap a little earlier on a stack overflow, and in some cases it can
trap where gforth does not.
I have thought about making the stack of gforth-fast larger by one
page to avoid the problem of a program running a test successfully
with gforth and failing with a stack overflow in gforth-fast, but have
not done so yet.
- 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-04-27 13:23 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <535d04b5$0$25076$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #29859 |
In article <2014Apr26.133848@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: >>Do we agree that Forth, as defined, uses "as if" semantics? I think >>we must, because no-one is suggesting that the stack really has to be >>implemented as a stack > >You mean, as a memory-area plus stack pointer (as on most hardware)? >As a hardware stack (as on Chuck Moore's chips)? > >>all stack accesses may be converted to a >>series of register moves. > >Not in general. > >>So, "as if" semantics apply, and merging >>memory accesses is arguably a legitimate thing for a compiler to do. >>You can only reasonably describe this as "miscompiling" if you define >>your memory model. > >That's not necessary. If it produces a different behaviour than the >original code, it's not a legitimate thing for a compiler to do. That >follows directly from the as-if rule. No need for me to define a >memory model; that has been done by the hardware maker. > >Your suggestion that an "optimization barrier" would be needed is an >admission that the as-if rule does not hold for the "optimization". > >>That is hard because it forces you to confront the >>reality of today's hardware. > >I don't find it particularly hard, and side effects on reading from an >I/O device have existed for over 30 years. > >>>>>>So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the >>>>>>rare case where you actually must read from foo twice, and this is >>>>>>guaranteed to do so even on machines with relaxed memory ordering. >>>>> >>>>> "Relaxed memory ordering" does not have anything to do with it. >>>> >>>>Huh? In this case it does. >>>> >>>>> Even the most broken machine will not do the second "foo @" before >>>>> the first "foo @". >>>> >>>>Actually, I'm not sure about Alpha, but everything else won't AFAIK. >>> >>> So you cannot name a single machine where relaxed memory ordering has >>> anything to do with it. >> >>Huh? You've lost me. > >Read again, and (if necessary) ask concrete questions! > >>>>and b) even if they don't the hardware may replace two fetches from >>>>the same address with a single one. And this is not "weird" >>>>hardware, but almost every modern (32 bits and up) design. Even the >>>>venerable x86 needs a StoreLoad barrier if you want sequential >>>>consistency. >>> >>> Memory ordering/sequential consistency has nothing to do with this, as >>> established above. And sure, if you have two loads from the same >>> addresses in cached memory, the second one will be served from the >>> cache. >> >>How is that different in effect from converting "foo @ foo @" into >>"foo @ dup" ? > >The difference is that the compiler doesn't know that FOO points to >cached memory. > >>> But devices that have a side effect on reading are not in cached >>> memory, and two loads will result in two accesses (and two times the >>> side effect). >> >>I agree. Memory-mapped I/O is inherently non-portable and cannot be >>discussed outside the context of a particular physical system. > >Sure it can. We are doing so. And while programs doing memory-mapped >I/O may not be portable to platforms that don't have the device, they >can be portable across machines that have the device, and across >different Forth implementations on these machines. What he probably meant was: memory mapped I/O is outside of the scope of a language definition. Pascal a:=10; It is perfectly defined in the context of Pascal what this is supposed to mean. No make `a' point to the control register of an UART. While the compiler may compile the same code, and the result is what the programmer intended, what happens is no longer Pascal. > >- anton >-- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-28 21:32 -0700 |
| Subject | Re: @ and optimization |
| Message-ID | <f636caf0-644a-4a26-b3fa-f152be2e3071@googlegroups.com> |
| In reply to | #29859 |
On Saturday, April 26, 2014 4:38:48 AM UTC-7, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Your suggestion that an "optimization barrier" would be needed is an > admission that the as-if rule does not hold for the "optimization". > > >That is hard because it forces you to confront the > >reality of today's hardware. > > I don't find it particularly hard, and side effects on reading from an > I/O device have existed for over 30 years. The 6502 had memory-mapped I/O so C@ and C! had to be used, whereas the Z80 had a separate memory page for I/O and so it required separate versions of C@ and C! for that memory. I agree with Anton --- this is trivial to solve, and has been for many decades. These threads just wander off into a lot of off-topic triviality --- everybody is avoiding the OP's question of why Forth is an "epic fail" --- stiffen up your spines and face the question!
[toc] | [prev] | [next] | [standalone]
Page 7 of 22 — ← Prev page 1 … 5 6 [7] 8 9 … 22 Next page →
Back to top | Article view | comp.lang.forth
csiph-web