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 10 of 19 — ← Prev page 1 … 8 9 [10] 11 12 … 19 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-14 13:22 +0000 |
| Message-ID | <2014Apr14.152248@mips.complang.tuwien.ac.at> |
| In reply to | #29615 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>I don't believe that this is generally true: AIUI code quality is
>>>measured regularly and is not decreasing.
>>
>> Looking at Figure 7 and 8 of
>>
>> http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf
>>
>> you can see that Gforth 0.6.2 is much slower on newer gccs than on
>> older ones.
>
>Well, yes, but that's GForth, which as discussed is written neither in
>Standard C or GNU C.
...
>> How do you measure code quality?
>
>There's a bunch of industry-standard benchmarks. AFAIK SPECint is the
>best general-purpose one.
And SPECint is not written in Standard C, either, as was widely
publicized. As for "GNU C", has the non-standard compliant behaviour
of SPECint been documented as a GNU C feature? If not, then by your
standards, SPECint is not GNU C, either. Or do you use a different
meaning of "written in GNU C"? If so, what is it?
So, since SPECint is written neither in Standard C nor in GNU C (as
you define it), why does it matter whether Gforth is written in
standard C or in GNU C (as you define it).
So you restrict the language that you compile as intended to the
language used in these benchmarks, and you measure the code quality
with these benchmarks. Sounds like a pure benchmark compiler to me.
Pity, it used to be useful.
>> Anyway, the reason why we used gcc is because it was a good way to
>> combine our goals of portability and efficiency, and to avoid having
>> to get involved with native-code compilers and their retargeting
>> issues. If I get involved with writing a native-code compilers, I
>> will do one for Forth; this is probably much less work than cleaning
>> up gcc, and it will result in a faster Forth system.
>
>Probably. And it might even make GForth into what it should have been
>in the first place.
What is that, IYO?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-14 10:08 -0500 |
| Message-ID | <r7idnU7_fL-fZ9bOnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #29637 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>I don't believe that this is generally true: AIUI code quality is >>>>measured regularly and is not decreasing. >>> >>> Looking at Figure 7 and 8 of >>> >>> http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf >>> >>> you can see that Gforth 0.6.2 is much slower on newer gccs than on >>> older ones. >> >>Well, yes, but that's GForth, which as discussed is written neither in >>Standard C or GNU C. > ... >>> How do you measure code quality? >> >>There's a bunch of industry-standard benchmarks. AFAIK SPECint is the >>best general-purpose one. > > And SPECint is not written in Standard C, either, as was widely > publicized. As for "GNU C", has the non-standard compliant behaviour > of SPECint been documented as a GNU C feature? IIRC it turned out that the optimization which broke SPECint wasn't really a useful optimization at all, so there was no point keeping it. If it had been useful, I suppose a switch to disable it would have been added. > If not, then by your standards, SPECint is not GNU C, either. Indeed not. It's a real shame: IMO benchmarks should be written in the standard language. It's not entirely SPEC's fault, given that they didn't write the banchmarks themselves. > So you restrict the language that you compile as intended to the > language used in these benchmarks, and you measure the code quality > with these benchmarks. That's a fair comment, but remember that these are not synthetic benchmarks: they are a wide range of real programs. So, making a compiler perform well on them is not unreasonable. >>Probably. And it might even make GForth into what it should have >>been in the first place. > > What is that, IYO? A Forth system written in Forth. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Spam@ControlQ.com |
|---|---|
| Date | 2014-04-14 11:59 -0400 |
| Message-ID | <alpine.BSF.2.00.1404141156160.45110@yoko.controlq.com> |
| In reply to | #29640 |
On Mon, 14 Apr 2014, Andrew Haley wrote: >>> Probably. And it might even make GForth into what it should have >>> been in the first place. >> >> What is that, IYO? > > A Forth system written in Forth. > > Andrew. > IIRC, Gforth was originally described as a reference implementation which could run on as many systems as possible. It appears to have grown far beyond the original vision, as the implementation quickly became highly optimized, and the word list extensive. For a C based implementation, it does run very fast on any systems I've run it on. Cheers, Rob.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-17 16:56 +0000 |
| Message-ID | <2014Apr17.185616@mips.complang.tuwien.ac.at> |
| In reply to | #29640 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>I don't believe that this is generally true: AIUI code quality is
>>>>>measured regularly and is not decreasing.
>>>>
>>>> Looking at Figure 7 and 8 of
>>>>
>>>> http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf
>>>>
>>>> you can see that Gforth 0.6.2 is much slower on newer gccs than on
>>>> older ones.
>>>
>>>Well, yes, but that's GForth, which as discussed is written neither in
>>>Standard C or GNU C.
>> ...
>>>> How do you measure code quality?
>>>
>>>There's a bunch of industry-standard benchmarks. AFAIK SPECint is the
>>>best general-purpose one.
>>
>> And SPECint is not written in Standard C, either, as was widely
>> publicized. As for "GNU C", has the non-standard compliant behaviour
>> of SPECint been documented as a GNU C feature?
>
>IIRC it turned out that the optimization which broke SPECint wasn't
>really a useful optimization at all, so there was no point keeping it.
As evalutated with SPECint, which was broken by the optimization?
Sure.
Meanwhile, the "optimizations" since gcc-2.95 (at
least as a whole, but I suspect, also individually) are not useful for
Gforth 0.7.0, even though it's not broken by them.
>If it had been useful, I suppose a switch to disable it would have
>been added.
I would love to have an optimization option that gives me the gcc-2.x
optimizations and nothing more.
>> If not, then by your standards, SPECint is not GNU C, either.
>
>Indeed not. It's a real shame: IMO benchmarks should be written in
>the standard language. It's not entirely SPEC's fault, given that
>they didn't write the banchmarks themselves.
>
>> So you restrict the language that you compile as intended to the
>> language used in these benchmarks, and you measure the code quality
>> with these benchmarks.
>
>That's a fair comment, but remember that these are not synthetic
>benchmarks: they are a wide range of real programs. So, making a
>compiler perform well on them is not unreasonable.
Indeed, for a compiler that aspires to compile real programs. But
unfortunately I don't see such aspirations in GCC anymore.
Actually, Bernd Paysan wrote IIRC that the way that the SPECint
problem was fixed still breaks the real program that the SPECint
benchmark is based on. If that is the case, you don't get the "real
program" brownie points anyway.
>>>Probably. And it might even make GForth into what it should have
>>>been in the first place.
>>
>> What is that, IYO?
>
>A Forth system written in Forth.
Why do you think that Gforth should have been that in the first place?
If you want a purist Forth systems that is built only with Forth
tools, there are a significant number of them around. No need to turn
Gforth into one of them.
Among Gforth's goals, OTOH, was portability, and it achieved that
portability by using GCC as a portable assembler (among other things).
As a result, Gforth 0.6.2 ran on AMD64 and IA-64 without us having
tested it on these platforms (we did not have them available when we
released Gforth 0.6.2). Actually, even Gforth 0.5.0 (released in
2000) can be built for and then runs on AMD64 (released in 2003) and
IA-64 (introduced in 2001).
So using GCC as a portable assembler was the right decision and a
success. And it would still be the way to go if GCC still was a
reliable portable assembler. Unfortunately, it no longer is, so we
will migrate away from it, but it was good while it lasted.
- 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 | Spam@ControlQ.com |
|---|---|
| Date | 2014-04-17 15:16 -0400 |
| Message-ID | <alpine.BSF.2.00.1404171511200.2392@yoko.controlq.com> |
| In reply to | #29693 |
On Thu, 17 Apr 2014, Anton Ertl wrote: [...] >>> >>> What is that, IYO? >> >> A Forth system written in Forth. > > Why do you think that Gforth should have been that in the first place? > > If you want a purist Forth systems that is built only with Forth > tools, there are a significant number of them around. No need to turn > Gforth into one of them. > > Among Gforth's goals, OTOH, was portability, and it achieved that > portability by using GCC as a portable assembler (among other things). > As a result, Gforth 0.6.2 ran on AMD64 and IA-64 without us having > tested it on these platforms (we did not have them available when we > released Gforth 0.6.2). Actually, even Gforth 0.5.0 (released in > 2000) can be built for and then runs on AMD64 (released in 2003) and > IA-64 (introduced in 2001). > > So using GCC as a portable assembler was the right decision and a > success. And it would still be the way to go if GCC still was a > reliable portable assembler. Unfortunately, it no longer is, so we > will migrate away from it, but it was good while it lasted. > > - anton > Anton, What would constitute a successor to gcc for gforth? Certainly LLVM/Clang is not on enough platforms, and is evolving in its own right. Targetting Java VM's and Parrot make no sense, as they are too far away from the iron that Gforth has traditionally maintained close relations with ... so how might you proceed, and what might constitute a viable replacement? Cheers, Rob.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-17 23:59 +0200 |
| Message-ID | <lipisq$244$2@online.de> |
| In reply to | #29694 |
Spam@ControlQ.com wrote: > What would constitute a successor to gcc for gforth? Certainly LLVM/Clang > is not on enough platforms, and is evolving in its own right. Targetting > Java VM's and Parrot make no sense, as they are too far away from the iron > that Gforth has traditionally maintained close relations with ... so how > might you proceed, and what might constitute a viable replacement? Well, we'll bite the bullet and write native code generation for at least the most popular targets. The gcc part won't go away quickly. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-18 04:38 -0700 |
| Message-ID | <7xtx9qamv9.fsf@ruckus.brouhaha.com> |
| In reply to | #29693 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > So using GCC as a portable assembler was the right decision and a > success. And it would still be the way to go if GCC still was a > reliable portable assembler. There's a constituency of C users who considered C to be something like a portable assembler, and another constituency that considered it to be a language for high performance computation on big computers. The standards committee tried to address the desires of both sides, but in some cases, the desires are in conflict, so it wasn't possible to give everyone what they wanted. C is a lousy assembly language anyway, as the C-- doex explain. Maybe there should be something like a C-- front end for GCC.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-18 09:17 -0400 |
| Message-ID | <op.xeikjw0s6zenlw@localhost> |
| In reply to | #29699 |
On Fri, 18 Apr 2014 07:38:34 -0400, Paul Rubin <no.email@nospam.invalid> wrote: > C is a lousy assembly language anyway, [...] Having written 75% of a basic operating system in ANSI C for x86 PCs with very minimal assembly, I can't understand how you can make that claim. C captures the essence of microprocessors. I.e., almost everything that general purpose microprocessor instructions do, C can do too. For my OS project, I need a few special x86 instructions to setup the processor mode or access I/O ports, an assembly routine for interrupts to transfer from assembly to C and back, and I support an additional, special startup method that needs assembly. I do use some C library calls, but they're independent of the host. The majority of the code is ANSI C. I.e., those calls will likely be implemented in ANSI C too or rewritten, if I ever have time to return to it. For non-x86 PCs, you'd likely only need the interrupt wrapper, if the C compiler doesn't support an "interrupt" keyword. Non-x86 PCs shouldn't need any special processor instructions. > [...] as the C-- doex explain. Well, I'll have to peruse that yet again to see why... AIR, from what I saw, C-- sucked as an assembly language. I remember thinking you could do what it did in C much easier, in C, with far less syntax. I also recall thinking LLVM had some potential, but I don't recall if that was for use as an assembler or not. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-18 11:44 -0500 |
| Message-ID | <vs-dnSiUiZv4y8zOnZ2dnUVZ8uadnZ2d@supernews.com> |
| In reply to | #29699 |
Paul Rubin <no.email@nospam.invalid> wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> So using GCC as a portable assembler was the right decision and a >> success. And it would still be the way to go if GCC still was a >> reliable portable assembler. > > There's a constituency of C users who considered C to be something like > a portable assembler, and another constituency that considered it to be > a language for high performance computation on big computers. The > standards committee tried to address the desires of both sides, but in > some cases, the desires are in conflict, so it wasn't possible to > give everyone what they wanted. > > C is a lousy assembly language anyway, as the C-- doex explain. Maybe > there should be something like a C-- front end for GCC. It wouldn't be possible with the current structure. C-style paramater passing and stack frames are pretty much baked-in. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-18 17:06 +0000 |
| Message-ID | <2014Apr18.190654@mips.complang.tuwien.ac.at> |
| In reply to | #29699 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> So using GCC as a portable assembler was the right decision and a
>> success. And it would still be the way to go if GCC still was a
>> reliable portable assembler.
>
>There's a constituency of C users who considered C to be something like
>a portable assembler, and another constituency that considered it to be
>a language for high performance computation on big computers. The
>standards committee tried to address the desires of both sides, but in
>some cases, the desires are in conflict, so it wasn't possible to
>give everyone what they wanted.
According to Andrew Haley, the C standard gives us anything but a
portable assembly language, and if the C standard is interpreted as
the GCC maintainers do it, I agree with him (I just don't think this
is the right way to interpret it).
That narrow view of the C standard also does not cater to high
performance computation on big computers either (whatever you may mean
by that; I usually know "high-performance computing" as a synonym for
"supercomputing" or "scientific computing" etc, i.e. stuff with lots
of FP numbers, but I will assume you mean people who want to get the
maximum speed out of their hardware without dropping to assembly
language): Many idioms used by people who want high performance are
undefined behaviour or somesuch according to the C standard.
The only one that the C standard caters to is people who write Pascal
programs with Java syntax. And apparently optimizing that is the
be-all and end-all of current C compilers. Great, they can optimize
away some induction variables in such programs (while "optimizing"
loops in some other programs into infinite loops), but I don't need
that optimiziation in C! I can eliminate these induction variables in
source code if need be.
>C is a lousy assembly language anyway, as the C-- doex explain.
We certainly make good use of GNU C extensions. Without them, Gforth
would be slower by a factor of about 8 on IA-32 and AMD64 (factor 2
from dynamic superinstructions (based on labels-as-values), factor 2
from direct threading (based on labels-as-values), factor 2 from
explicit register allocation). But with these extensions, C does
nicely.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-18 11:41 -0500 |
| Message-ID | <vs-dnSmUiZsvyMzOnZ2dnUVZ8uadnZ2d@supernews.com> |
| In reply to | #29693 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>I don't believe that this is generally true: AIUI code quality is >>>>>>measured regularly and is not decreasing. >>>>> >>>>> Looking at Figure 7 and 8 of >>>>> >>>>> http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl.pdf >>>>> >>>>> you can see that Gforth 0.6.2 is much slower on newer gccs than on >>>>> older ones. >>>> >>>>Well, yes, but that's GForth, which as discussed is written neither in >>>>Standard C or GNU C. >>> ... >>>>> How do you measure code quality? >>>> >>>>There's a bunch of industry-standard benchmarks. AFAIK SPECint is the >>>>best general-purpose one. >>> >>> And SPECint is not written in Standard C, either, as was widely >>> publicized. As for "GNU C", has the non-standard compliant behaviour >>> of SPECint been documented as a GNU C feature? >> >>IIRC it turned out that the optimization which broke SPECint wasn't >>really a useful optimization at all, so there was no point keeping it. > > As evalutated with SPECint, which was broken by the optimization? No. >>>>Probably. And it might even make GForth into what it should have >>>>been in the first place. >>> >>> What is that, IYO? >> >>A Forth system written in Forth. > > Why do you think that Gforth should have been that in the first place? It's my personal preference, I suppose. IME Forth written in Forth is easier to explore, easier to understand, and easier to change. Because of this Forth is a great tool for learning how to bootstrap systems. If you depend on non-Forth you lose all of these advantages. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-18 16:55 +0000 |
| Message-ID | <2014Apr18.185525@mips.complang.tuwien.ac.at> |
| In reply to | #29704 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>IIRC it turned out that the optimization which broke SPECint wasn't
>>>really a useful optimization at all, so there was no point keeping it.
>>
>> As evalutated with SPECint, which was broken by the optimization?
>
>No.
What did you use then?
>>>A Forth system written in Forth.
>>
>> Why do you think that Gforth should have been that in the first place?
>
>It's my personal preference, I suppose. IME Forth written in Forth is
>easier to explore, easier to understand, and easier to change.
>Because of this Forth is a great tool for learning how to bootstrap
>systems. If you depend on non-Forth you lose all of these advantages.
Maybe, although the success of JonesForth is counterevidence for your claim.
As for exploring, understanding, and changing, Gforth is not the
easiest system in these areas, but that has more to do with it leaning
more towards the fat-and-featureful side rather than than
lean-and-mean side. That would not change if Gforth employed, say, an
assembler written in Forth to write the engine.
And even with the assembler-written-in-Forth approach, you either have
to put the complexity of executable file formats in the Forth system
(reducing portability even more) or employ a loader written in a
non-Forth language for which there are tools that contain that
complexity.
- 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-18 19:20 +0200 |
| Message-ID | <lirms2$qgl$1@online.de> |
| In reply to | #29706 |
Anton Ertl wrote: > Maybe, although the success of JonesForth is counterevidence for your > claim. > > As for exploring, understanding, and changing, Gforth is not the > easiest system in these areas, but that has more to do with it leaning > more towards the fat-and-featureful side rather than than > lean-and-mean side. That would not change if Gforth employed, say, an > assembler written in Forth to write the engine. It actually does; if you build Gforth EC, it uses the assembler written in Forth and the cross compiler written in Forth. This is just another option how to build Gforth: With the C-based engine, the cross compiler's only task for the primitives is to create headers with numbers which are resolved by the engine; without it, the cross compiler actually compiles either code or corresponding high-level stuff. Most of Gforth is written in Forth. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-20 14:52 +0000 |
| Message-ID | <2014Apr20.165219@mips.complang.tuwien.ac.at> |
| In reply to | #29707 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> As for exploring, understanding, and changing, Gforth is not the
>> easiest system in these areas, but that has more to do with it leaning
>> more towards the fat-and-featureful side rather than than
>> lean-and-mean side. That would not change if Gforth employed, say, an
>> assembler written in Forth to write the engine.
>
>It actually does; if you build Gforth EC, it uses the assembler written in
>Forth and the cross compiler written in Forth.
Yes, and Gforth EC is probably easier to explore, understand and
change, because the rest of the code base is leaner. And yet, despite
these advantages, nobody has done, say, a Gforth EC for Linux PCs.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-18 12:21 -0500 |
| Message-ID | <QbOdnZg9rOGwwszOnZ2dnUVZ8t6dnZ2d@supernews.com> |
| In reply to | #29706 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>IIRC it turned out that the optimization which broke SPECint wasn't >>>>really a useful optimization at all, so there was no point keeping it. >>> >>> As evalutated with SPECint, which was broken by the optimization? >> >>No. > > What did you use then? I didn't, personally speaking. IIRC (and it was some time ago) the generated code for some special cases was inspected and found not to be a significant improvement in any of the cases that it was suppoed to improve. >>>>A Forth system written in Forth. >>> >>> Why do you think that Gforth should have been that in the first place? >> >>It's my personal preference, I suppose. IME Forth written in Forth is >>easier to explore, easier to understand, and easier to change. >>Because of this Forth is a great tool for learning how to bootstrap >>systems. If you depend on non-Forth you lose all of these advantages. > > Maybe, although the success of JonesForth is counterevidence for > your claim. In what way is it conter-evidence? JonesForth isn't written in Forth and is a pig to understand and change. > As for exploring, understanding, and changing, Gforth is not the > easiest system in these areas, but that has more to do with it > leaning more towards the fat-and-featureful side rather than than > lean-and-mean side. That would not change if Gforth employed, say, > an assembler written in Forth to write the engine. That's a shame. > And even with the assembler-written-in-Forth approach, you either > have to put the complexity of executable file formats in the Forth > system (reducing portability even more) or employ a loader written > in a non-Forth language for which there are tools that contain that > complexity. I take your point, but generating simple ELF files isn't that hard. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-20 14:36 +0000 |
| Message-ID | <2014Apr20.163659@mips.complang.tuwien.ac.at> |
| In reply to | #29708 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>It's my personal preference, I suppose. IME Forth written in Forth is
>>>easier to explore, easier to understand, and easier to change.
>>>Because of this Forth is a great tool for learning how to bootstrap
>>>systems. If you depend on non-Forth you lose all of these advantages.
>>
>> Maybe, although the success of JonesForth is counterevidence for
>> your claim.
>
>In what way is it conter-evidence? JonesForth isn't written in Forth
>and is a pig to understand and change.
Maybe a pig to change, but all those people who learned about Forth
(implementation) from JonesForth indicate that it is not a pig to
understand; instead, it seems to be much easier to understand for
people without Forth background than the large number of
Forth-in-Forth systems.
Another example is eForth: Ting's stripped-down assembly version is
more popular than Bill Muench's Forth-in-Forth original.
>> And even with the assembler-written-in-Forth approach, you either
>> have to put the complexity of executable file formats in the Forth
>> system (reducing portability even more) or employ a loader written
>> in a non-Forth language for which there are tools that contain that
>> complexity.
>
>I take your point, but generating simple ELF files isn't that hard.
And then we would have limited Gforth to ELF platforms only.
But of course you are free to show the superiority of this approach.
E.g., you could start with the current Gforth and replace all the
non-Forth parts with Forth parts. It will be interesting to see how
you replace various parts, e.g. libltdl.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-20 08:17 -0700 |
| Message-ID | <7xy4z0hvxl.fsf@ruckus.brouhaha.com> |
| In reply to | #29732 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Another example is eForth: Ting's stripped-down assembly version is > more popular than Bill Muench's Forth-in-Forth original. Interesting. I really enjoyed looking at the Forth version. I think Andrew's point about Forth-in-Forth being easier to understand meant by experienced Forthers rather than newbies (not that I'm so experienced but I guess I'm a non-newbie by now). I remember his describing running out of code space on some microprocessor in the middle of developing a big program, and converting the address interpreter to token threading to save space. >>I take your point, but generating simple ELF files isn't that hard. > And then we would have limited Gforth to ELF platforms only. It might be reasonable to have a system layer in C, that would export some system calls and have an assembly stub that jumps to user machine code emitted by a Forth-in-Forth compiler, or alternatively it could be configured with a portable, minimalistic bytecode interpreter written in C. The compiler would have machine code backends for supported cpus, and a bytecode backend for other cpus. The amount of C code could be pretty small, like in the Retroforth virtual machine.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-20 11:35 -0500 |
| Message-ID | <II2dnQbNFdGlas7OnZ2dnUVZ_vadnZ2d@supernews.com> |
| In reply to | #29732 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I take your point, but generating simple ELF files isn't that hard. > > And then we would have limited Gforth to ELF platforms only. Mmmm, but ELF is rather complex as executable formats go. So, if ELF isn't very hard none of them should be very hard. > But of course you are free to show the superiority of this approach. > E.g., you could start with the current Gforth and replace all the > non-Forth parts with Forth parts. It will be interesting to see how > you replace various parts, e.g. libltdl. I don't quite see what you're getting at here. Of course, Forth- in-Forth requires more work to port; I'm not claiming otherwise. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-21 10:51 -0700 |
| Message-ID | <lj3lr6$jt4$1@dont-email.me> |
| In reply to | #29732 |
on 20/04/2014 15:37:00, wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>> And even with the assembler-written-in-Forth approach, you either >>> have to put the complexity of executable file formats in the Forth >>> system (reducing portability even more) or employ a loader written >>> in a non-Forth language for which there are tools that contain that >>> complexity. >> >>I take your point, but generating simple ELF files isn't that hard. > > And then we would have limited Gforth to ELF platforms only. There are a couple of solutions here, some more attractive than others. In Linux, binfmt_misc can be used to run any loader you might wish. For OSX, there's XBinary that provides an equivalent function (although you can cover Linux and OSX with ELF). In Windows, everything has to be a PE, but it is relatively easy to implement, and Win32Forth generates PEs. My version also generates 64bit PEs (although alas, the code for 64bit is incomplete). That's 3 formats that cover a large chunk of the OS space. And then there's the redoubtable Agner Fogg's GPL object format converter; http://www.agner.org/optimize/#objconv which "can be used for converting object files between COFF/PE, OMF, ELF and Mach-O formats for all 32-bit and 64-bit x86 platforms".
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-21 19:54 +0200 |
| Message-ID | <lj3m12$p6n$1@online.de> |
| In reply to | #29732 |
Anton Ertl wrote: > But of course you are free to show the superiority of this approach. > E.g., you could start with the current Gforth and replace all the > non-Forth parts with Forth parts. It will be interesting to see how > you replace various parts, e.g. libltdl. libltdl is just onion programming of the GNU project around direct access to shared libraries like dlopen and dlsym (of course you need to link your executable with libdl.so first to be able to use these functions ;-). On reasonable OSes, where these calls work as they should, there is no reason for libltdl, and the unreasonable OSes aren't that important anymore. A lot of this onion programming is there for historical reasons. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 10 of 19 — ← Prev page 1 … 8 9 [10] 11 12 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web