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 7 of 19 — ← Prev page 1 … 5 6 [7] 8 9 … 19 Next page →
| 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]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 08:50 -0400 |
| Subject | Re: @ and optimization |
| Message-ID | <op.xexcmiim6zenlw@localhost> |
| In reply to | #29832 |
On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> 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. 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). Coherency means what is in the cache matches what is in memory. With two reads to the same address, if memory hasn't changed any, then both "foo @" will be from the cache and have the same value. With two reads to the same address, if memory has changed between reads, e.g., perhaps via memory mapped hardware, then the first and second "foo @" will have the different values. The first will be loaded from the cache. The second may be loaded from the memory or loaded from an invalidated and re-loaded cache, depending on the design of the coherency logic. If what's in the cache doesn't match memory for the second read, then the microprocessor's coherency logic is *broken*. Excluding the improved memory speed of caching, the caching operation should function as if there was no cache present, i.e., as if the read or write was directly to memory without buffering, without memory read optimization, etc. If the memory changes between reads, the processor can update the cache at various points in time depending on the design. E.g., at the hardware write to memory, at the next read, etc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-26 22:52 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <ljh9rb$1j8$1@dont-email.me> |
| In reply to | #29861 |
on 26/04/2014 13:50:35, "Rod Pemberton" wrote: > On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>> 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. 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). > > Coherency means what is in the cache matches what is in memory. Coherency says nothing about what value is in memory. Coherency ensures that the value of an item retrieved from non-disjoint locations by a coupled processor is the most up-to-date value. [snip]
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 20:33 -0400 |
| Subject | Re: @ and optimization |
| Message-ID | <op.xex86wef6zenlw@localhost> |
| In reply to | #29889 |
On Sat, 26 Apr 2014 17:52:43 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 26/04/2014 13:50:35, "Rod Pemberton" wrote: >> On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> 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. 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). >> >> Coherency means what is in the cache matches what is in memory. > > Coherency says nothing about what value is in memory. Coherency ensures > that the value of an item retrieved from non-disjoint locations by a > coupled processor is the most up-to-date value. > http://en.wikipedia.org/wiki/Cache_coherency RP
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-27 11:53 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <ljinja$g3g$1@dont-email.me> |
| In reply to | #29892 |
on 27/04/2014 01:34:01, "Rod Pemberton" wrote: > On Sat, 26 Apr 2014 17:52:43 -0400, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 26/04/2014 13:50:35, "Rod Pemberton" wrote: > > wrote: >>> On Fri, 25 Apr 2014 13:22:30 -0400, Anton Ertl > > wrote: >>> <anton@mips.complang.tuwien.ac.at> wrote: > > wrote: >>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > wrote: > >>>>> 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. 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). >>> >>> Coherency means what is in the cache matches what is in memory. >> >> Coherency says nothing about what value is in memory. Coherency ensures >> that the value of an item retrieved from non-disjoint locations by a >> coupled processor is the most up-to-date value. >> > > http://en.wikipedia.org/wiki/Cache_coherency > > > RP > (On the presumption that you believe the wiki supports your incorrect assertion.) If you're interested then any decent set of articles on MESI MOESI or MESIF protocols will help. You could also read up about memory snooping and write back cahces. There you would find how processor caches work, and how your description of their operation is wrong.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-28 01:05 -0400 |
| Subject | Re: @ and optimization |
| Message-ID | <op.xe0ge1gx6zenlw@localhost> |
| In reply to | #29911 |
On Sun, 27 Apr 2014 06:53:30 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 27/04/2014 01:34:01, "Rod Pemberton" wrote: >> On Sat, 26 Apr 2014 17:52:43 -0400, Alex McDonald <blog@rivadpm.com >> wrote: >>> on 26/04/2014 13:50:35, "Rod Pemberton" wrote: >>>> Coherency means what is in the cache matches what is in memory. >>> >>> Coherency says nothing about what value is in memory. Coherency ensures >>> that the value of an item retrieved from non-disjoint locations by a >>> coupled processor is the most up-to-date value. >>> >> >> http://en.wikipedia.org/wiki/Cache_coherency >> > > (On the presumption that you believe the wiki supports your incorrect > assertion.) The wiki stated what I stated. It would be a contradiction for only one to be correct. > If you're interested then any decent set of articles on MESI MOESI or > MESIF protocols will help. You could also read up about memory snooping > and write back cahces. There you would find how processor caches work, > and how your description of their operation is wrong. I know how processor caches work from the software level all the way down to the integrated circuit level, although perhaps not every design, or more recent ones. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-25 21:34 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <bofll9p0bnb8mlf6nfb216g1t3mv7i5jln@4ax.com> |
| In reply to | #29822 |
On Fri, 25 Apr 2014 06:13:56 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >IMO, the Right Way to do it is to have explicit read and write >barriers. These would insert barrier instructions on machines that >need them and an optimization barrier on machines that don't. 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. > This IMO introduces what appears an extra layer of unnecessary complexity. Yes, a programmer needs to know their hardware. Yes, they need to know their language of choice. But what you're suggesting would require that they also know intimately about the inner workings of their optimiser. Not sure I agree with this. IMO an optimiser should be limited to doing transformations that have *guaranteed* no side-effects, i.e. equivalent transformations. If that means doing fewer optimisations automatically, fine. Where there MAY be are further opportunities for optimisation, but "at your own risk" because they involve non-equivalent code transformations, why not adopt the philosophy that the optimiser be given an 'advisory mode' that can be switched on if the programmer wants further recommendations made. This would be akin to various levels of warning modes. Ba compiler, IMO, should not be permitted to automatically change code in a way that is not an equivalent transformation. What I cannot understand is, if given a choice, who want to use something more complicated and potentially unreliable over a simpler, predictable and reliable optimiser, even if the simpler optimiser did less? Most casual users are risk averse and would not. And most advanced users would rather have the recommendations made and then use their experience to go forward. Adopting the other approach --- optimise anything even at the risk of breaking stuff, and require the programmer to have to code even more defensively against yet another source of uncertainty --- seems to me to run counter to all of the cautionary quotes around code optimisation: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." — W.A. Wulf "Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is." — Rob Pike (part of the UNIX / C team at Bell Labs) "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" — Donald Knuth, Structured Programming with Goto Statements. Computing Surveys 6:4 (1974), 261–301 And again from Knuth: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered." (Knuth, same paper as above) - Assad
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-25 13:37 -0700 |
| Subject | Re: @ and optimization |
| Message-ID | <7xvbtxf8m9.fsf@ruckus.brouhaha.com> |
| In reply to | #29835 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > IMO an optimiser should be limited to doing transformations that have > *guaranteed* no side-effects, i.e. equivalent transformations. Interesting suggestion. Can you list any transformations that are *guaranteed* no side-effects? I'm having a hard time thinking of any, given the lack of specification here of what a side effect is.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-25 22:03 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <tfill9dj4dbvdkvmc9rsc4oeint4r39fhv@4ax.com> |
| In reply to | #29836 |
On Fri, 25 Apr 2014 13:37:50 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: >> IMO an optimiser should be limited to doing transformations that have >> *guaranteed* no side-effects, i.e. equivalent transformations. > >Interesting suggestion. Can you list any transformations that are >*guaranteed* no side-effects? I'm having a hard time thinking of >any, given the lack of specification here of what a side effect is. Sure. Here are three. * Dead code elimination (by definition). * Address Optimisation (since you're just changing the location of global variables in memory) * Constant Folding (evaluate an expression at compile time instead of run-time) What criteria? By side-effect, I mean something that fails in an edge-case. By equivalent transformation of the code, I mean that an optimisation should be rejected (or marked for recommendation but not automatic implementation ) if there is a situation in which doing that transformation would alter the behaviour of the untransformed code and thereby produce a different result. AFAIK this is part of the definition: "Compiler optimization is the process of improving the quality of object code without changing the results it produces." http://en.wikipedia.org/wiki/History_of_compiler_construction#Optimizing_compilers - Assad
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 15:38 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.173859@mips.complang.tuwien.ac.at> |
| In reply to | #29836 |
Paul Rubin <no.email@nospam.invalid> writes:
>Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes:
>> IMO an optimiser should be limited to doing transformations that have
>> *guaranteed* no side-effects, i.e. equivalent transformations.
>
>Interesting suggestion. Can you list any transformations that are
>*guaranteed* no side-effects?
Using the commutative law. Using the associative and distributive
laws with modulo arithmetics (not with FP, saturating, or
trap-on-overflow arithmetics). Or equivalent stack manipulations.
E.g.:
SWAP + => +
1+ 2 + => 3 +
SWAP DROP => NIP
>I'm having a hard time thinking of
>any, given the lack of specification here of what a side effect is.
My guess is that he meant cases where there are no circumstances under
which the transformation causes an observable 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 | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 17:24 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <14mnl9dbrfs3q5poo2jp4klm89clfkb103@4ax.com> |
| In reply to | #29872 |
On Sat, 26 Apr 2014 15:38:59 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >My guess is that he meant cases where there are no circumstances under >which the transformation causes an observable difference. > Same criteria as you and Bernd are expressing. Bernd calls it semantical equivalence | In any case, to perform an optimization, you need a proof of semantical | equivalence. Anton refers to different behaviour | If it produces a different behaviour than the | original code, it's not a legitimate thing for a compiler to do. I wrote in my reply to Paul. >> By side-effect, I mean something that fails in an >> edge-case. By equivalent transformation of the code, I mean that an >> optimisation should be rejected (or marked for recommendation but not >> automatic implementation ) if there is a situation in which doing that >> transformation would alter the behaviour of the untransformed code and >> thereby produce a different result. >> >> AFAIK this is part of the definition: >> "Compiler optimization is the process of improving the quality of >> object code without changing the results it produces." >> http://en.wikipedia.org/wiki/History_of_compiler_construction#Optimizing_compilers - Assad
[toc] | [prev] | [next] | [standalone]
Page 7 of 19 — ← Prev page 1 … 5 6 [7] 8 9 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web