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 8 of 19 — ← Prev page 1 … 6 7 [8] 9 10 … 19 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 04:48 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <AJadnYBfbbJDHcbOnZ2dnUVZ_sqdnZ2d@supernews.com> |
| In reply to | #29835 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > 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. That's not my intention. I'm suggesting a way that programs can be made portable. My suggestion is a simple way to do that and achieve equivalent behaviour on different hardware. > 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. It's worse than that. If you want all memory operations to be visible to alll theads in the order they were written, i.e. sequential consistency, you're going to have to emit barriers at possibly every fetch and store, with increased bus traffic and power consumption. Consider a system with loosely-coupled shared memory and many cores. Probably only a few memory accesses in your program need to be synchronized, but you'd be forcing synchronization across the whole system for every fetch and store. That would make Forth useless for programming such a system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 11:09 +0100 |
| Subject | Re: @ and optimization |
| Message-ID | <821nl91fgct02l7pr4rq3tkdm2n6gd1ro8@4ax.com> |
| In reply to | #29852 |
On Sat, 26 Apr 2014 04:48:14 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: >> 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. > >That's not my intention. I'm suggesting a way that programs can be >made portable. My suggestion is a simple way to do that and achieve >equivalent behaviour on different hardware. Ok, but then wouldn't Anton's suggestion then be equivalent but better: I believe he is suggesting that the compiler should not turn foo @ foo @ into foo @ dup unless explicitly permitted to do so by the programmer. This is better because a person who is unaware of the issue has a slight penalty, but has his code preserved exactly as he wrote it -- so there can be no quibble about non-equivalent transformations. And if he is aware of the issue, then he has the choice to code it himself properly or tell the compiler to do it for him. Throughout, it is the programmer that retains the control. - Assad
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-28 21:24 -0700 |
| Subject | Re: @ and optimization (was: Epic Fail) |
| Message-ID | <c6e9b4eb-5c37-4e2e-a15e-93ada3f2d2c8@googlegroups.com> |
| In reply to | #29821 |
On Friday, April 25, 2014 1:40:47 AM UTC-7, Anton Ertl wrote: > In particular, optimizing @ has come up a number of times over the > years. One idea I had was @CONST, which would be applicable if we > knew that the data at the address will never change, e.g.: > > : constant ( n -- ) > create , > does> > @const ; > > Another idea (from Stephen Pelc) is to declare certain memory areas as > read-only, e.g.: > > : constant ( n -- ) > create here swap , 1 cells read-only > does> > @ ; > > That is good for data that is in memory permanently. I avoid this whole problem in my novice package (which is ANS-Forth) by using :NAME and compiling literal data with LIT, --- how easy is that? --- by comparison, in VFX, Pelc abandons ANS-Forth compatibility with his compile-time directive to indicate which data is constant, just so that he can stick with CREATE DOES> (and why he wants to stick with CREATE DOES> I don't know, as it has other problems as well). I pointed out this inefficiency of CREATE DOES> fetching constant data at run-time way back in 2009 or 2010 when I first wrote the novice package, and everybody just said that my code "sucks" and that I don't know how CREATE DOES> works --- now in 2014 you are still speculating on how to solve the problem that I solved many years ago.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-24 19:17 +0000 |
| Message-ID | <53596331$0$27134$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29807 |
In article <2014Apr24.191024@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>>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"?
>
>Selectively?
>
>As a programmer, I just write "foo @ foo @" if I want two loads from
>memory, and "foo @ dup" if I want one. As a compiler writer, I just
>mark @ as one of the words where common subexpression elimination (if
>I implement it; seems questionable in Forth) is not applicable.
Seems a fat looser to me. Just today I wrote:
"
VARIABLE P
\ Find the power of `` P '' occurring in the M th binomial index.
: #power >R N @ P @ #f N @ R@ - P @ #f - R> P @ #f - check ;
"
Putting P in a register seems indicated. Moreover, if #power is inlined,
the register must remain valid. A big win.
Instead I would have
: poke-hardware foo @ ; OPTIMIZED
OPTIMIZED to the optimiser means that it is optimised as good as
possible, and that it should leave poke-hardware alone.
(Or call it FORBID-INLINE , whatever).
>
>>1) disable all pointer based optimizations to prevent compiler
>>optimization errors. (Didn't you just have a large rant on
>>erroneous optimizations in C? ...)
>
>Not sure what "pointer"-based optimizations you have in mind, but yes,
>I would not "optimize" a @ away.
Pointer based optimisation must be done only if there is a no-aliasing
guarantee. This guarantee can be had by code analysis, or (like in
FORTRAN) it can be given by the user. Leaving out pointer optimisation
seems a fat looser.
>
>>2) implement a minimal type system in the optimizer so that when
>>it recognizes "dup" in "foo @ dup" it can determine that the stack
>>value is a pointer and do the opposite of optimizing, by converting
>>"dup" into "foo @".
>
>What would be the point of that? If the programmer writes "foo @
>dup", the compiler should produce only one memory load.
And if you go that way, you end up with a 1Gbyte optimiser.
>
>- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-25 08:27 +0000 |
| Message-ID | <2014Apr25.102739@mips.complang.tuwien.ac.at> |
| In reply to | #29810 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2014Apr24.191024@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>As a programmer, I just write "foo @ foo @" if I want two loads from
>>memory, and "foo @ dup" if I want one. As a compiler writer, I just
>>mark @ as one of the words where common subexpression elimination (if
>>I implement it; seems questionable in Forth) is not applicable.
>
>Seems a fat looser to me. Just today I wrote:
>"
> VARIABLE P
> \ Find the power of `` P '' occurring in the M th binomial index.
> : #power >R N @ P @ #f N @ R@ - P @ #f - R> P @ #f - check ;
>"
>
>Putting P in a register seems indicated.
Then do it. Forth gives you various features that can be mapped to
registers easily, e.g., stack items and locals and (without
multi-threading) VALUEs (or with multi-threading, a thread-local
variant of VALUEs). VARIABLEs are not one of them. E.g., you could
fetch P once and put the result in a local:
: #power P @ { p } >R N @ p #f N @ R@ - p #f - R> p #f - check ;
My recommendation would be to pass parameters on the stack though,
instead of through variables. Then that works, too:
> Moreover, if #power is inlined,
>the register must remain valid. A big win.
If you write bubble-sort tomorrow, don't expect the optimizer to
change it into quicksort. Forth allows you to write quicksort. You
don't need the optimizer for that.
>>What would be the point of that? If the programmer writes "foo @
>>dup", the compiler should produce only one memory load.
>
>And if you go that way, you end up with a 1Gbyte optimiser.
What's that supposed to mean?
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-25 23:44 +0200 |
| Message-ID | <ljekv2$ttb$1@online.de> |
| In reply to | #29820 |
Anton Ertl wrote: >>>What would be the point of that? If the programmer writes "foo @ >>>dup", the compiler should produce only one memory load. >> >>And if you go that way, you end up with a 1Gbyte optimiser. > > What's that supposed to mean? I'm not sure what he means, but the "volatile problem" (as Stephen had named it) is that @ is not a predictable operation in general. I.e. it does not have the referential transparency property it needs to have if you want to replace it by its value (this is something you do on CSE). In any case, to perform an optimization, you need a proof of semantical equivalence. foo @ foo @ is semantically equivalent to foo @ dup if and only if foo is referentially transparent. This is only the case when it is a) real memory (as opposed to e.g. a memory mapped register of some hardware) and b) only accessed by a single thread. If you can prove that, go ahead and optimize. If the task creation is actually part of the language, you could in fact prove that some memory regions are only used by a single thread, and then optimize those. This part might create a bigger optimizer, the "@ results are irreproducible" stuff isn't making the optimizer large. If you want to help the optimizer, add a way to mark memory regions or passed pointers as "constant". When fetching from such a region, @ is allowed to treat the result as referentially transparent, i.e. arbitrary reordering is allowed, it doesn't matter if there is aliasing, and so on. -- 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-26 14:37 +0000 |
| Message-ID | <535bac58.251218659@news.demon.co.uk> |
| In reply to | #29617 |
On Sun, 13 Apr 2014 23:44:11 +0200, Bernd Paysan <bernd.paysan@gmx.de> wrote: >There are some corner cases, which Stephen called "the volatile issue": Is > >foo @ foo @ > >identical to > >foo @ dup I'm amazed that this discussion has lasted so long. In order to give it a bit of context, the original problem was noted by Andrew and occurred because earlier versions of x86 VFX converted foo @ dup into foo @ foo @ This occurs because the x86 has a limited number of registers *and* has a memory to register architecture. For example, you can add from memory to to a register. By defining a memory fetch as a data resource on the stack, DUP in the compiler just duplicates the fetch. Hence, foo @ dup becomes foo @ foo @ >The problem is still there, this is apparently difficult for VFX to fix. >The code looks a bit different: > >variable foo >: wait ( -- result ) foo @ begin foo @ tuck <> until ; > >The loop compiles to > >( 080BF350 3B1D40240A08 ) CMP EBX, [080A2440] >( 080BF356 8B1D40240A08 ) MOV EBX, [080A2440] >( 080BF35C 74F2 ) JZ/E 080BF350 In the current development version, the loop compiles to: ( 004CA780 8B151C244600 ) MOV EDX, [0046241C] ( 004CA786 3BDA ) CMP EBX, EDX ( 004CA788 8BDA ) MOV EBX, EDX ( 004CA78A 74F4 ) JZ/E 004CA780 One more instruction, but only one memory reference and two bytes shorter. On a related topic, it would be sensible to have an I/O operation that cannot be optimised away and cannot be reordered. Many Forth systems used PC@, PW@ and P@ to refer to x86 I/O ports. Perhaps MMC@, MMW@ ... for memory mapped I/O. 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 15:04 -0700 |
| Message-ID | <5cb167bf-1408-42d5-b3e9-4b5084b211d2@googlegroups.com> |
| In reply to | #29616 |
On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: > (B2) We're actually not all that interested in C anyway --- what we > would really like is to be able to take *any* language, transform it > to a machine independent intermediate language, and then write out > 'optimised' code to any given target machine. So what we're after is > a universal middle-language, with reasonably sound translators from C, > Fortran, C++, Objective-C, even Java, maybe even Python, into it, and > then reasonably sound translators from this middle language into any > of a vast number of machine languages. This is what C-- was designed to do. I'm on the mailing list, which is dead now. The designers are not supporting C-- anymore because they lost their funding --- you may be interested in picking up the baton. In regard to Forth-like languages, there is Cat --- this was also designed more to be an intermediate language such as you are describing, rather than something that people would write manually.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 09:58 +0100 |
| Message-ID | <9ssml9phf0dqnh6drjve8igb4jsqkitmuj@4ax.com> |
| In reply to | #29618 |
On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com wrote: >On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >> (B2) We're actually not all that interested in C anyway --- what we >> would really like is to be able to take *any* language, transform it >> to a machine independent intermediate language, and then write out >> 'optimised' code to any given target machine. So what we're after is >> a universal middle-language, with reasonably sound translators from C, >> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >> then reasonably sound translators from this middle language into any >> of a vast number of machine languages. > >This is what C-- was designed to do. I'm on the mailing list, which is dead now. The designers are not supporting C-- anymore because they lost their funding --- you may be interested in picking up the baton. > >In regard to Forth-like languages, there is Cat --- this was also designed more to be an intermediate language such as you are describing, rather than something that people would write manually. Actually, I wrote (B1) and (B2) as simple statements of what I see as two diametrically opposed points of view. B1 expresses a position that is closer to Bernd and Anton's point of view. B2 is closer to Andrew's and the current GCC's point of view. My point of view is, incidentally, closer to B1 ---- I would rather have C return to its former heritage of a portable assembler, with a relatively stable C compiler that does some non-hazardous code optimisations, but views its mission as portable assembly, not fancy universal language compiler. So while it's interesting to read your take on C-- and Cat, I would be more likely to participate in a move to return C back to its original heritage. - Assad
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 10:16 +0100 |
| Message-ID | <s0uml955qbtk3tu9guvkktnecejcgfcfvh@4ax.com> |
| In reply to | #29848 |
On Sat, 26 Apr 2014 09:58:11 +0100, Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: Apologies -- I didn't quote myself properly (!)... corrected now below. > >Actually, I wrote (A1-A3) and (B1-B3) > as simple statements of what I see as >two diametrically opposed points of view. See A1-A3 below from the original post: >> On Sun, 13 Apr 2014 18:42 GMT, Assad Ebrahim wrote: >>> Is the below a fair representation of your and Bernd's point of view? >>> >>> (A1) we want some of the optimisations that optimising compilers >>> produce >>> >>> (A2) but we don't want them to do so at the expense of taking too >>> many liberties with the code >>> >>> (A3) we'd rather agree that if we want to improve code beyond what a >>> non-libertine compiler could legitimately do, then we must take on >>> that further improvement ourselves using profilers and targeted >>> improvements ourselves. >>> So now: A1-A3... > > expresses a position that is closer to Bernd and Anton's point of >view. > B1-B3... > is closer to Andrew's and the current GCC's point of view. > >My point of view is, incidentally, closer to A1-A3, i.e. >I would rather have C return to its former heritage of a portable assembler, with a >relatively stable C compiler that does some non-hazardous code >optimisations, but views its mission as portable assembly, not fancy >universal language compiler. > >So while it's interesting to read your take on C-- and Cat, I would be >more likely to participate in a move to return C back to its original >heritage. > >- Assad
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 05:06 -0500 |
| Message-ID | <GIqdnRdJS-OsGMbOnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #29848 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >>On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >>> (B2) We're actually not all that interested in C anyway --- what we >>> would really like is to be able to take *any* language, transform it >>> to a machine independent intermediate language, and then write out >>> 'optimised' code to any given target machine. So what we're after is >>> a universal middle-language, with reasonably sound translators from C, >>> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >>> then reasonably sound translators from this middle language into any >>> of a vast number of machine languages. >> >>This is what C-- was designed to do. I'm on the mailing list, which >>is dead now. The designers are not supporting C-- anymore because >>they lost their funding --- you may be interested in picking up the >>baton. >> >>In regard to Forth-like languages, there is Cat --- this was also >>designed more to be an intermediate language such as you are >>describing, rather than something that people would write manually. > > Actually, I wrote (B1) and (B2) as simple statements of what I see as > two diametrically opposed points of view. > > B1 expresses a position that is closer to Bernd and Anton's point of > view. > > B2 is closer to Andrew's and the current GCC's point of view. Actually, that's not really my position. I am arguing for a literalist interpretation of language semantics. That is to say, believe that the specification means what it says: when it says something is undefined, it really is undefined. And if you invoke undefined behaviour and something bad happens, it really is your fault. I have no objection to tightening up areas of undefined behaviour, and in many cases it would improve programming languages to do so, even if it meant fewer optimization opportunities. From what I can see this view is becoming more widespread. > My point of view is, incidentally, closer to B1 ---- I would rather > have C return to its former heritage of a portable assembler, with a > relatively stable C compiler that does some non-hazardous code > optimisations, but views its mission as portable assembly, not fancy > universal language compiler. I don't have any objection to that, but it requires some work on the language's specification. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 11:16 +0100 |
| Message-ID | <gh1nl9leejr0pp6m3mstt60l0r27imjmi9@4ax.com> |
| In reply to | #29854 |
On Sat, 26 Apr 2014 05:06:41 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: >> On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com >> wrote: >> >>>On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >>>> (B2) We're actually not all that interested in C anyway --- what we >>>> would really like is to be able to take *any* language, transform it >>>> to a machine independent intermediate language, and then write out >>>> 'optimised' code to any given target machine. So what we're after is >>>> a universal middle-language, with reasonably sound translators from C, >>>> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >>>> then reasonably sound translators from this middle language into any >>>> of a vast number of machine languages. >>> >> >> B2 is closer to Andrew's and the current GCC's point of view. > >Actually, that's not really my position. I am arguing for a >literalist interpretation of language semantics. That is to say, >believe that the specification means what it says: when it says >something is undefined, it really is undefined. And if you invoke >undefined behaviour and something bad happens, it really is your >fault. Fair enough. But in life, law, and technical specifications, isn't it the case the *nothing* can every be completely specified to cover every possible case now and also every possible case in the future. Areas will always be discovered that are undefined in the latest spec. I think the issue is what the fallback position of a compiler writer is in these cases. IMO, this should be guided be the *spirit* or *intent* of the language. That's why reference to "C as a portable assembler" is so important -- it defines a *spirit* which should be used to guide what is done when an undefined case is found. What do you think? > >I have no objection to tightening up areas of undefined behaviour, and >in many cases it would improve programming languages to do so, even if >it meant fewer optimization opportunities. From what I can see this >view is becoming more widespread. > >> My point of view is, incidentally, closer to B1 ---- I would rather >> have C return to its former heritage of a portable assembler, with a >> relatively stable C compiler that does some non-hazardous code >> optimisations, but views its mission as portable assembly, not fancy >> universal language compiler. > >I don't have any objection to that, but it requires some work on the >language's specification. > >Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-26 03:43 -0700 |
| Message-ID | <7x4n1g9xr0.fsf@ruckus.brouhaha.com> |
| In reply to | #29856 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: >>believe that the specification means what it says: when it says >>something is undefined, it really is undefined... > Fair enough. But in life, law, and technical specifications, isn't it > the case the *nothing* can every be completely specified to cover > every possible case now and also every possible case in the future. > Areas will always be discovered that are undefined in the latest spec. 1) I don't think most of the disagreement over undefined behavior has been about weird combinations that the specification overlooked. They've been about situations where section XYZ of the specification explicitly says "the result of doing X is undefined". And "undefined" in turn is explicitly different from "implementation defined". The standard does in fact say some other things are implementation defined, which means the compiler writer gets to choose the behaviour (from some set of sensible alternatives) and is supposed to implement it in some consistent way. "Undefined" means "this program state has no meaning and the user program should never enter it and expect any sane outcome, don't expect consistency: here be dragons." 2) Language specifications that try to cover every possible case are, in fact, reasonably successful at doing so. Examples: Algol-60, Scheme, Java, Ada, ML. The C specification leaves various constructs undefined on purpose, not by incompleteness or informality, but in order to present more optimization opportunities to the compiler writer. That is a philosophical choice that the C designers made and that C users presumptively embrace when they choose to use C. Evidence is mounting that it's a BAD philosophical choice, but the solution is fix the specification or choose another language. The Forth specification seems to be in a related situation, leaving a lot unspecified though maybe not explicitly undefined like C does. The result is there are grey areas where it's not clear what to do.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 14:24 +0000 |
| Message-ID | <2014Apr26.162421@mips.complang.tuwien.ac.at> |
| In reply to | #29857 |
Paul Rubin <no.email@nospam.invalid> writes:
>2) Language specifications that try to cover every possible case are, in
>fact, reasonably successful at doing so. Examples: Algol-60, Scheme,
Matthias Felleisen writes
<http://blog.regehr.org/archives/213#comment-703>:
|What's really sad is that some so-called high-level languages like
|Scheme intentionally include undefined behavior, too.
If one example is wrong, what about the others?
>Java, Ada, ML. The C specification leaves various constructs undefined
>on purpose, not by incompleteness or informality, but in order to
>present more optimization opportunities to the compiler writer.
That's what Andrew Haley is claiming, but I find that claim very
doubtful, especially because it is ahistorical; at the time of C89,
GCC 1.x was a leader in the performance of the generated code, and it
did not use "undefined behaviour" for "optimization" opportunities.
So who would have pushed for that in the C89 committee, and how would
they have convinced all the others?
I also doubt it when looking at the way we work in Forth
standardization. We do not define various things, and explicitly
undefine some ("ambiguous condition"). Especially in explicit
undefinition, the reason has never been "optimization opportunities".
Reasons were:
*) Several implementation variants exist, and we could not agree on
one (or did not even try).
*) Several implementation variants are imaginable, but the proposer
and/or the committee did not see a good reason to nail it down.
*) Differences in environment/platform. E.g., the Xchars proposal
does not define that Forth uses UTF-8, because there are other
encodings in use (notably 8-bit, but also others).
>That is
>a philosophical choice that the C designers made and that C users
>presumptively embrace when they choose to use C.
We certainly did not embrace it when we chose to use C; in fact we were
unaware of that supposed philisophical choice, and the issue did not
come up until over 10 years later.
I also doubt that the C designer made that choice. But since he is
dead, he cannot deny it.
>The Forth specification seems
>to be in a related situation, leaving a lot unspecified though maybe not
>explicitly undefined like C does. The result is there are grey areas
>where it's not clear what to do.
The Forth standard would certainly benefit from tightening, but
fortunately the mental disease that befell the C compiler writers has
not spread to Forth compiler writers 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-26 23:58 -0400 |
| Message-ID | <op.xeyiocof6zenlw@localhost> |
| In reply to | #29870 |
On Sat, 26 Apr 2014 10:24:21 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > [...] GCC 1.x was a leader in the performance of the generated code, > [...] So, you're actually claiming that GCC - at some point in time - actually outperformed Watcom, or now OpenWatcom, in terms of generated code? You're aware that one religion asks people to believe in a female, invisible, pink unicorn too? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-27 12:46 +0000 |
| Message-ID | <2014Apr27.144619@mips.complang.tuwien.ac.at> |
| In reply to | #29896 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Sat, 26 Apr 2014 10:24:21 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> [...] GCC 1.x was a leader in the performance of the generated code,
>> [...]
>
>So, you're actually claiming that GCC - at some point in time - actually
>outperformed Watcom, or now OpenWatcom, in terms of generated code?
Sure. E.g., Watcom did not produce code for HP9000/300 (68k-based)
machines. The only game in town was HP's compiler (which was probably
derived from PCC), and GCC (maybe also Green Hills). So GCC
definitely outperformed Watcom on these machines. And when it was
released, the code it produced was significantly faster than that of
HP's compiler; the HP people then worked on it for a year and managed
to get close to the performance of GCC.
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-28 00:41 -0400 |
| Message-ID | <op.xe0fb0pp6zenlw@localhost> |
| In reply to | #29915 |
On Sun, 27 Apr 2014 08:46:19 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes: >> On Sat, 26 Apr 2014 10:24:21 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >>> [...] GCC 1.x was a leader in the performance of the generated code, >>> [...] >> >> So, you're actually claiming that GCC - at some point in time - actually >> outperformed Watcom, or now OpenWatcom, in terms of generated code? > > Sure. E.g., Watcom did not produce code for HP9000/300 (68k-based) > machines. The only game in town was HP's compiler (which was probably > derived from PCC), and GCC (maybe also Green Hills). So GCC > definitely outperformed Watcom on these machines. And when it was > released, the code it produced was significantly faster than that of > HP's compiler; the HP people then worked on it for a year and managed > to get close to the performance of GCC. > Of course, that clarifies your earlier statement which made no constraints as to which platforms GCC was a performance leader. Obviously, if we take x86 into account, GCC was *never* a performance leader. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-28 21:54 -0700 |
| Message-ID | <ca8aed1b-e3e8-4800-a1c6-ce94c26aad93@googlegroups.com> |
| In reply to | #29870 |
On Saturday, April 26, 2014 7:24:21 AM UTC-7, Anton Ertl wrote:
> >Java, Ada, ML. The C specification leaves various constructs undefined
> >on purpose, not by incompleteness or informality, but in order to
> >present more optimization opportunities to the compiler writer.
> ...
> I also doubt it when looking at the way we work in Forth
> standardization. We do not define various things, and explicitly
> undefine some ("ambiguous condition"). Especially in explicit
> undefinition, the reason has never been "optimization opportunities".
> Reasons were:
>
> *) Several implementation variants exist, and we could not agree on
> one (or did not even try).
>
> *) Several implementation variants are imaginable, but the proposer
> and/or the committee did not see a good reason to nail it down.
>
> *) Differences in environment/platform. E.g., the Xchars proposal
> does not define that Forth uses UTF-8, because there are other
> encodings in use (notably 8-bit, but also others).
Now we are finally getting back to the OP's question of why Forth was an "epic fail" --- lack of ability of the ANS-Forth committee to agree on important issues, which resulted in a lot of wishy-washy "may or may not" nonsense in the ANS-Forth document. There were two causes for this:
1.) None of the committee members had the authority to over-ride Forth Inc.. They knew that there was an intelligent way to do something (for example: to make the control-stack distinct from the data-stack), but SwiftForth did this in an unintelligent manner (used the data-stack for control-flow data in order to make the compiler-writer's job slightly easier), so the result was to have the standard say that *either* the intelligent way or the SwiftForth way was standard. The result is that the application programmer has to choose the most restrictive way in order for his code to work on every ANS-Forth compiler, and so SwiftForth effectively becomes the standard. He has to assume that the control-flow stuff is on the data stack in his way, for example, so that his code will run under SwiftForth, even if he is using a Forth system that implements this in the intelligent way (with the control-stack being separate from the data-stack).
2.) The committee members were just too dumb to understand the issue being discussed, so they didn't make any decision at all --- they essentially said: "Well, um, whatever anybody does will be considered to be standard."
Because the title of this thread is "Epic Fail," section 3.2.3.2. begs to be quoted:
"The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed."
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-26 17:17 +0100 |
| Message-ID | <temnl9ten13pfrcs06n2q8v4ue68kacg82@4ax.com> |
| In reply to | #29857 |
On Sat, 26 Apr 2014 03:43:47 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >2) Language specifications that try to cover every possible case are, in >fact, reasonably successful at doing so. Examples: Algol-60, Scheme, >Java, Ada, ML. The C specification leaves various constructs undefined >on purpose, not by incompleteness or informality, but in order to >present more optimization opportunities to the compiler writer. That is >a philosophical choice that the C designers made and that C users >presumptively embrace when they choose to use C. Evidence is mounting >that it's a BAD philosophical choice, but the solution is fix the >specification or choose another language. Perhaps that's why Dennis Ritchie and Rob Pike started the Go language --- displeasure with the state of affairs in what C is becoming. If so, then we have a new pun on the name: an oblique reference to the fact that the direction of the new C is likely to be a "No Go"... Assad
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-26 10:08 -0500 |
| Message-ID | <HLCdnRy0JvJuVsbOnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #29856 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: > On Sat, 26 Apr 2014 05:06:41 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> wrote: >>> On Sun, 13 Apr 2014 15:04:47 -0700 (PDT), hughaguilar96@yahoo.com >>> wrote: >>> >>>>On Sunday, April 13, 2014 10:42:54 AM UTC-7, Assad Ebrahim wrote: >>>>> (B2) We're actually not all that interested in C anyway --- what we >>>>> would really like is to be able to take *any* language, transform it >>>>> to a machine independent intermediate language, and then write out >>>>> 'optimised' code to any given target machine. So what we're after is >>>>> a universal middle-language, with reasonably sound translators from C, >>>>> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >>>>> then reasonably sound translators from this middle language into any >>>>> of a vast number of machine languages. >>>> >>> >>> B2 is closer to Andrew's and the current GCC's point of view. >> >>Actually, that's not really my position. I am arguing for a >>literalist interpretation of language semantics. That is to say, >>believe that the specification means what it says: when it says >>something is undefined, it really is undefined. And if you invoke >>undefined behaviour and something bad happens, it really is your >>fault. > > Fair enough. But in life, law, and technical specifications, isn't it > the case the *nothing* can every be completely specified to cover > every possible case now and also every possible case in the future. > Areas will always be discovered that are undefined in the latest spec. Exactly so: from time to time unexpected questions arise, and have to be answered by specification revisions. This can be done either by revising the language specification itself or adding clarifying local documentation to an implementation. > I think the issue is what the fallback position of a compiler writer > is in these cases. Not quite. It's what you do about cases that have deliberately been left undefined. > IMO, this should be guided be the *spirit* or *intent* of the > language. > > That's why reference to "C as a portable assembler" is so important -- > it defines a *spirit* which should be used to guide what is done when > an undefined case is found. > > What do you think? That such a thing is so hopelessly vague as to be impossible to implement; it would make a compiler writer's job impossible and it would make it very difficult to move code between implementations because their implementors disagreed about the spirit of the language. Leave all this talk about intent and spirit to lawyers and witchdoctors: we need proper specifications. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 8 of 19 — ← Prev page 1 … 6 7 [8] 9 10 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web