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-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 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: 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-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 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-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 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 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
Page 6 of 19 — ← Prev page 1 … 4 5 [6] 7 8 … 19 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-26 14:35 +0200 |
| Subject | Re: @ and optimization |
| Message-ID | <ljg969$lli$1@online.de> |
| In reply to | #29859 |
Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>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. If this "inherently non-portable" nature would be true, OpenFirmware wouldn't make sense (or work at all). However, it does make sense and it works. -- 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-26 09:59 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <4dOdncefNIFGVMbOnZ2dnUVZ_s2dnZ2d@supernews.com> |
| In reply to | #29859 |
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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 10:14 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <HLCdnR60JvLsUMbOnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #29866 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> 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. Err, assuming that foo has no side-effects. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 15:30 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.173025@mips.complang.tuwien.ac.at> |
| In reply to | #29866 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>The "as if" rule says that no standard program can tell the difference
>between an optimized and an unoptimized program.
There are no real-world standard programs in C nor in Forth, so this
form of the as-if rule is totally useless. If would allow
"optimizing" every real-world program into a noop.
> 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.
If FOO points to an I/O register with a side effect on reading, there
is a difference. And if a Forth compiler wants to be useful in the
real world and not just for benchmarks, it has to preserve this
difference.
- 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-26 12:05 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <jsydnVZAf6j8esbOnZ2dnUVZ_tadnZ2d@supernews.com> |
| In reply to | #29871 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>The "as if" rule says that no standard program can tell the difference >>between an optimized and an unoptimized program. > > There are no real-world standard programs in C nor in Forth, so this > form of the as-if rule is totally useless. If would allow > "optimizing" every real-world program into a noop. I take that point, but it does not change the definition of the "as if" rule. >>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. > > If FOO points to an I/O register ... then what @ does is not defined by the language, but by the hardware; or rather a combination of the hardware and the language implementation. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 17:27 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.192747@mips.complang.tuwien.ac.at> |
| In reply to | #29876 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>The "as if" rule says that no standard program can tell the difference
>>>between an optimized and an unoptimized program.
>>
>> There are no real-world standard programs in C nor in Forth, so this
>> form of the as-if rule is totally useless. If would allow
>> "optimizing" every real-world program into a noop.
>
>I take that point, but it does not change the definition of the "as
>if" rule.
In that case, my answer on using your definition of "as-if" semantics
for Forth is "no". Your definition of "as-if" semantics is useless,
because the specification of Forth in the standard is incomplete, and
therefore cannot be used as a basis for judging transformations.
- 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-26 12:39 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <37-dnQJBQ_rycsbOnZ2dnUVZ_qydnZ2d@supernews.com> |
| In reply to | #29879 |
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: >>>>The "as if" rule says that no standard program can tell the difference >>>>between an optimized and an unoptimized program. >>> >>> There are no real-world standard programs in C nor in Forth, so this >>> form of the as-if rule is totally useless. If would allow >>> "optimizing" every real-world program into a noop. >> >>I take that point, but it does not change the definition of the "as >>if" rule. > > In that case, my answer on using your definition of "as-if" semantics > for Forth is "no". Your definition of "as-if" semantics is useless, > because the specification of Forth in the standard is incomplete, and > therefore cannot be used as a basis for judging transformations. 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 18:07 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.200704@mips.complang.tuwien.ac.at> |
| In reply to | #29880 |
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:
>>>>>The "as if" rule says that no standard program can tell the difference
>>>>>between an optimized and an unoptimized program.
>>>>
>>>> There are no real-world standard programs in C nor in Forth, so this
>>>> form of the as-if rule is totally useless. If would allow
>>>> "optimizing" every real-world program into a noop.
>>>
>>>I take that point, but it does not change the definition of the "as
>>>if" rule.
>>
>> In that case, my answer on using your definition of "as-if" semantics
>> for Forth is "no". Your definition of "as-if" semantics is useless,
>> because the specification of Forth in the standard is incomplete, and
>> therefore cannot be used as a basis for judging transformations.
>
>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 define program equivalence through actual behaviour, and for
languages like Forth and C that have no well-defined programs (at
least not in the real world), that's the only definition that makes
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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-27 03:24 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <_5adnXJ9XLFLI8HOnZ2dnUVZ_u2dnZ2d@supernews.com> |
| In reply to | #29883 |
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: >>>>>>The "as if" rule says that no standard program can tell the difference >>>>>>between an optimized and an unoptimized program. >>>>> >>>>> There are no real-world standard programs in C nor in Forth, so this >>>>> form of the as-if rule is totally useless. If would allow >>>>> "optimizing" every real-world program into a noop. >>>> >>>>I take that point, but it does not change the definition of the "as >>>>if" rule. >>> >>> In that case, my answer on using your definition of "as-if" semantics >>> for Forth is "no". Your definition of "as-if" semantics is useless, >>> because the specification of Forth in the standard is incomplete, and >>> therefore cannot be used as a basis for judging transformations. >> >>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 define program equivalence through actual behaviour, OK, but how do you know how a program is supposed to be behave? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-27 13:00 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr27.150017@mips.complang.tuwien.ac.at> |
| In reply to | #29905 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I define program equivalence through actual behaviour,
>
>OK, but how do you know how a program is supposed to be behave?
Sure when I write my first compiler for such a language, I may have
this problem (but see below). But that's not the issue for gcc. You
have the behaviour of earlier versions of gcc as reference; in
addition, gcc without optimization mostly behaves right.
As for the first-compiler issue, I remember that people who wanted to
implement Forth asked questions about what various things specified in
the standard should do, and a frequent answer was that they should not
look in the standard to understand the language, but instead learn to
program in Forth, and then these questions should be clear.
- 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-27 11:18 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <56udnRBwU_h1sMDOnZ2dnUVZ_oSdnZ2d@supernews.com> |
| In reply to | #29916 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> I define program equivalence through actual behaviour, >> >>OK, but how do you know how a program is supposed to be behave? > > Sure when I write my first compiler for such a language, I may have > this problem (but see below). But that's not the issue for gcc. AFAIK we weren't talking about GCC, we were talking about Forth. I suppose some of the same issues arise, but it's not the same thing. > As for the first-compiler issue, I remember that people who wanted > to implement Forth asked questions about what various things > specified in the standard should do, and a frequent answer was that > they should not look in the standard to understand the language, but > instead learn to program in Forth, and then these questions should > be clear. I don't believe it. We're talking about edge cases here, and it's not at all clear that experienced Forth programmers will agree. I suppose everyone could agree to use the "ask the Oracle" standard, but there may be some holdouts against that idea. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-28 15:12 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr28.171232@mips.complang.tuwien.ac.at> |
| In reply to | #29919 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> I define program equivalence through actual behaviour,
>>>
>>>OK, but how do you know how a program is supposed to be behave?
>>
>> Sure when I write my first compiler for such a language, I may have
>> this problem (but see below). But that's not the issue for gcc.
>
>AFAIK we weren't talking about GCC, we were talking about Forth.
I was writing about Forth and C. But ok, let's stick with the issue
of what "FOO @" means if FOO is the address of a memory-mapped I/O
register.
>> As for the first-compiler issue, I remember that people who wanted
>> to implement Forth asked questions about what various things
>> specified in the standard should do, and a frequent answer was that
>> they should not look in the standard to understand the language, but
>> instead learn to program in Forth, and then these questions should
>> be clear.
>
>I don't believe it. We're talking about edge cases here, and it's not
>at all clear that experienced Forth programmers will agree.
While people here disagree about lots of things (including things that
are explicitly written in the standard), I have never seen anyone
suggest that if FOO is the address of a memory-mapped I/O register,
"FOO @" should do anything other than a machine-level load from that
address. I am sure that there no program that does that where the
programmer expects anything else. Edge case? Not in the least. Just
not standardized.
> I suppose
>everyone could agree to use the "ask the Oracle" standard, but there
>may be some holdouts against that idea.
I don't know what standard that is, but your phrasing indicates that
it is a straw-man argument.
- 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 03:52 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <j_OdnQY5H8mq9cLOnZ2dnUVZ_uGdnZ2d@supernews.com> |
| In reply to | #29937 |
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: >>>>> I define program equivalence through actual behaviour, >>>> >>>>OK, but how do you know how a program is supposed to be behave? >>> >>> Sure when I write my first compiler for such a language, I may have >>> this problem (but see below). But that's not the issue for gcc. >> >>AFAIK we weren't talking about GCC, we were talking about Forth. > > I was writing about Forth and C. But ok, let's stick with the issue > of what "FOO @" means if FOO is the address of a memory-mapped I/O > register. 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. >>> As for the first-compiler issue, I remember that people who wanted >>> to implement Forth asked questions about what various things >>> specified in the standard should do, and a frequent answer was that >>> they should not look in the standard to understand the language, but >>> instead learn to program in Forth, and then these questions should >>> be clear. >> >>I don't believe it. We're talking about edge cases here, and it's not >>at all clear that experienced Forth programmers will agree. > > While people here disagree about lots of things (including things > that are explicitly written in the standard), I have never seen > anyone suggest that if FOO is the address of a memory-mapped I/O > register, "FOO @" should do anything other than a machine-level load > from that address. I am sure that there no program that does that > where the programmer expects anything else. Edge case? Not in the > least. Just not standardized. But that doesn't help address the more general point. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-04-29 03:09 -0700 |
| Subject | Re: @ and optimization |
| Message-ID | <7082eaa8-b68a-46c8-be0b-2e9540be033e@googlegroups.com> |
| In reply to | #29955 |
On Tuesday, 29 April 2014 09:52:07 UTC+1, Andrew Haley wrote: > > I was writing about Forth and C. But ok, let's stick with the issue > > of what "FOO @" means if FOO is the address of a memory-mapped I/O > > register. > > > 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. In what respect is FOO @ "outside the scope of the standard"? FOO places an address on the stack. @ reads from it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-29 09:24 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <K8SdnQhRzLWnK8LOnZ2dnUVZ_v-dnZ2d@supernews.com> |
| In reply to | #29956 |
Mark Wills <markwills1970@gmail.com> wrote: > On Tuesday, 29 April 2014 09:52:07 UTC+1, Andrew Haley wrote: >> > I was writing about Forth and C. But ok, let's stick with the issue >> > of what "FOO @" means if FOO is the address of a memory-mapped I/O >> > register. >> >> >> 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. > > In what respect is FOO @ "outside the scope of the standard"? > > FOO places an address on the stack. @ reads from it. So, it depends on what FOO does. @ is only defined in terms of data space: anything else is outside the scope of the standard. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-29 08:36 -1000 |
| Subject | Re: @ and optimization |
| Message-ID | <K82dnUAO_eSibMLOnZ2dnUVZ_vCdnZ2d@supernews.com> |
| In reply to | #29956 |
On 4/29/14 12:09 AM, Mark Wills wrote: > On Tuesday, 29 April 2014 09:52:07 UTC+1, Andrew Haley wrote: >>> I was writing about Forth and C. But ok, let's stick with the issue >>> of what "FOO @" means if FOO is the address of a memory-mapped I/O >>> register. >> >> >> 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. > > In what respect is FOO @ "outside the scope of the standard"? > > FOO places an address on the stack. @ reads from it. > If the address is a memory-mapped I/O register, its behavior is determined by the device on the other end. The device's characteristics need to be documented in order for a @ to be really useful. Therefore, that case should be appropriately described as "implementation-defined". In most cases like that I've seen, @ would return the value input from the device in the low-order part of the cell, but there may be more to it than that: you might need to know under what circumstances the value will change or be valid, for example. There's no way a language standard can fully prescribe the behavior in this case, although it may be appropriate to put in a 1-sentence caveat in Section 3 regarding memory-mapped devices. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-29 14:38 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr29.163806@mips.complang.tuwien.ac.at> |
| In reply to | #29955 |
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:
>>>>>> I define program equivalence through actual behaviour,
>>>>>
>>>>>OK, but how do you know how a program is supposed to be behave?
...
>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.
So how the program is supposed to behave is not in question. You know
it and you implement it correctly when you don't optimize it.
Concerning your appeal to Elizabeth Rather's authority: citation
needed.
>>>I don't believe it. We're talking about edge cases here, and it's not
>>>at all clear that experienced Forth programmers will agree.
>>
>> While people here disagree about lots of things (including things
>> that are explicitly written in the standard), I have never seen
>> anyone suggest that if FOO is the address of a memory-mapped I/O
>> register, "FOO @" should do anything other than a machine-level load
>> from that address. I am sure that there no program that does that
>> where the programmer expects anything else. Edge case? Not in the
>> least. Just not standardized.
>
>But that doesn't help address the more general point.
For other cases it's the same. You know what behaviour programmers
expect, and you implement it in the non-optimizing case.
- 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 10:21 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <wuadnTOgBLTvXsLOnZ2dnUVZ_ridnZ2d@supernews.com> |
| In reply to | #29963 |
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: >>>>>>> I define program equivalence through actual behaviour, >>>>>> >>>>>>OK, but how do you know how a program is supposed to be behave? > ... >>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. > > So how the program is supposed to behave is not in question. You know > it and you implement it correctly when you don't optimize it. Well, that's your contention. > 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 believe it. We're talking about edge cases here, and it's not >>>>at all clear that experienced Forth programmers will agree. >>> >>> While people here disagree about lots of things (including things >>> that are explicitly written in the standard), I have never seen >>> anyone suggest that if FOO is the address of a memory-mapped I/O >>> register, "FOO @" should do anything other than a machine-level load >>> from that address. I am sure that there no program that does that >>> where the programmer expects anything else. Edge case? Not in the >>> least. Just not standardized. >> >>But that doesn't help address the more general point. > > 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. While this may be your personal preference, that is all it is. Forth is, IMO, far more fexible than that, and Forth users can cope with optimizing compilers and occasionally switch them off. Andrew.
[toc] | [prev] | [next] | [standalone]
| 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]
Page 6 of 19 — ← Prev page 1 … 4 5 [6] 7 8 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web