Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #20738 > unrolled thread
| Started by | AKE <assadebrahim2000@gmail.com> |
|---|---|
| First post | 2013-03-17 08:52 -0700 |
| Last post | 2013-03-21 04:53 -0700 |
| Articles | 20 on this page of 205 — 23 participants |
Back to article view | Back to comp.lang.forth
Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-17 08:52 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-17 10:41 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-17 11:08 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-03-17 08:52 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-17 12:28 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-17 13:09 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-17 13:25 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-17 13:53 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-17 23:31 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-18 02:13 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-19 16:45 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-03-28 18:58 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-17 23:27 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-18 02:14 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) mhx@iae.nl (Marcel Hendrix) - 2013-03-18 00:22 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Sieur de Bienville <morrimichael@gmail.com> - 2013-03-20 12:27 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-03-17 16:19 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-18 00:45 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Elizabeth D Rather <erather@forth.com> - 2013-03-19 10:34 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-19 13:49 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-17 13:39 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-17 14:42 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-17 14:49 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-03-18 11:02 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Pablo Hugo Reda <pabloreda@gmail.com> - 2013-03-17 15:11 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-17 21:40 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-18 04:26 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-18 15:46 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-19 04:15 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-19 05:03 -0500
Re: INTERLUDE SUMMARY --- Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-19 04:07 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) mhx@iae.nl (Marcel Hendrix) - 2013-03-19 20:56 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 21:03 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-20 05:53 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-18 01:07 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-18 01:53 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-18 02:32 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-18 02:45 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-18 03:28 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-18 10:20 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-18 18:23 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Brad Eckert <hwfwguy@gmail.com> - 2013-03-18 10:19 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Elizabeth D Rather <erather@forth.com> - 2013-03-18 10:44 -1000
And what about locals? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-18 23:28 +0000
Re: And what about locals? mhx@iae.nl (Marcel Hendrix) - 2013-03-19 01:20 +0200
Re: And what about locals? Elizabeth D Rather <erather@forth.com> - 2013-03-18 17:17 -1000
Re: And what about locals? m.a.m.hendrix@tue.nl - 2013-03-19 00:42 -0700
Re: And what about locals? stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 10:06 +0000
Re: And what about locals? Alex McDonald <blog@rivadpm.com> - 2013-03-19 12:53 -0700
Re: And what about locals? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-19 09:46 +0000
Re: And what about locals? stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 11:52 +0000
Re: And what about locals? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-19 16:08 +0000
Re: And what about locals? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 22:40 +0100
Re: And what about locals? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 11:43 +0000
Re: And what about locals? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 19:05 +0100
Re: And what about locals? "WJ" <w_a_x_man@yahoo.com> - 2013-04-06 12:00 +0000
Re: And what about locals? Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-08 18:38 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-18 14:24 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Elizabeth D Rather <erather@forth.com> - 2013-03-18 11:59 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 15:42 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Brad Eckert <hwfwguy@gmail.com> - 2013-03-18 15:04 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-18 15:22 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-19 04:07 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-19 12:49 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-20 05:33 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-20 19:52 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-21 05:53 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 10:30 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Brad Eckert <hwfwguy@gmail.com> - 2013-04-08 09:32 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-08 19:54 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-09 09:58 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 14:27 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-19 08:02 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-03-19 08:07 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 20:50 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-20 05:47 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-20 10:28 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-20 09:34 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-20 18:41 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-21 00:07 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-21 00:16 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-21 00:42 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-03-20 21:55 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-21 16:22 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-03-21 10:59 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 16:05 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 04:42 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-21 10:54 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-21 16:37 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Brad Eckert <hwfwguy@gmail.com> - 2013-03-22 08:34 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-22 10:44 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-22 21:00 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-22 21:04 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 16:34 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-06 04:05 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-06 17:11 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-08 19:47 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-22 18:10 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 10:44 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-05 22:12 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-06 02:46 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-08 17:53 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 20:30 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 21:05 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 01:58 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 16:39 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-06 04:07 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-20 05:43 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-20 05:06 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 10:45 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-20 11:08 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 17:40 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-20 13:25 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, r kenney@cix.compulink.co.uk - 2013-03-21 05:42 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-21 18:14 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 15:05 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 15:48 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-30 12:00 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-31 12:36 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-01 04:41 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-01 14:12 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-21 18:46 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-21 05:51 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-21 04:04 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-22 03:15 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-22 00:16 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-22 04:11 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 07:21 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-21 17:45 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 15:13 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-27 17:38 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-27 13:23 -0500
Language for implementing other languages (was: Algorithm design ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 11:08 +0000
Re: Language for implementing other languages Paul Rubin <no.email@nospam.invalid> - 2013-03-30 08:50 -0700
Re: Language for implementing other languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-31 13:15 +0000
Re: Language for implementing other languages Paul Rubin <no.email@nospam.invalid> - 2013-03-31 08:03 -0700
Re: Language for implementing other languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-30 11:08 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-22 03:52 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-22 04:15 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-24 15:03 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-03-24 14:36 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-25 05:05 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-25 12:02 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-25 07:26 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Alex McDonald <blog@rivadpm.com> - 2013-03-25 08:25 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-29 18:09 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-30 04:52 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 10:36 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-30 10:58 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-30 09:40 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-29 18:13 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-29 18:12 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-27 17:25 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-27 22:19 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-28 11:19 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-28 07:19 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-28 17:58 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-28 16:22 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-29 02:06 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-29 04:23 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "WJ" <w_a_x_man@yahoo.com> - 2013-03-28 15:41 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-28 18:00 +0100
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-28 16:26 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-29 14:11 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-29 14:53 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-29 08:49 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-29 16:54 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-30 13:06 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-31 11:36 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-01 02:18 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Paul Rubin <no.email@nospam.invalid> - 2013-03-31 19:33 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-01 16:18 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-01 11:17 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-02 04:30 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-01 15:54 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, ro kenney@cix.compulink.co.uk - 2013-04-01 14:54 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-30 13:08 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 16:00 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-02 16:47 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-03 11:27 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-23 01:57 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 16:45 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-06 03:00 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-08 16:11 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-08 15:43 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:49 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-09 04:02 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-09 07:03 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-09 04:04 -0500
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-04-08 14:34 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-09 00:02 +0200
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-09 07:06 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 10:23 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 15:13 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 15:27 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-04-05 15:02 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:52 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-04-05 13:22 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-04-06 12:34 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-04-07 02:39 -0700
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Elizabeth D. Rather" <erather@forth.com> - 2013-04-07 09:11 -1000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:48 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:51 -0400
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-19 17:38 +0000
Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Michael L Gassanenko <m_l_g3@yahoo.com> - 2013-03-21 04:53 -0700
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | AKE <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2013-03-21 00:16 -0700 |
| Message-ID | <8bc67568-a140-4b5a-818c-34704eac3800@googlegroups.com> |
| In reply to | #20943 |
On Thursday, March 21, 2013 7:07:47 AM UTC, AKE wrote:
> On Wednesday, March 20, 2013 6:41:37 PM UTC, Stephen Pelc wrote:
>
> > On Wed, 20 Mar 2013 09:34:35 -0700 (PDT), AKE wrote:
>
> > >Given the simplicity / appeal of the stack model (at least to people who
> > >like Forth), and the 'low impedance' benefits that go along, in principle,
> > >with a processor instruction matched closely to the programming language
> > >(faster development and testing, better factored code, predictable running
> > >times, and significantly reduced complexity of compilers), I would expect
> > >there to either have been or soon to come a resurgence of Forth processors
> > >-- not in silicon now, but in reconfigurable computing devices.
>
>
> Thanks also for the references. Very interesting.
>
I should also have added the following
http://www.fpgacpu.org/links.html
which lists a host of FPGA CPUs, including a number of Forth cores.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-03-21 00:42 -0700 |
| Message-ID | <7xboad19nc.fsf@ruckus.brouhaha.com> |
| In reply to | #20943 |
AKE <assadebrahim2000@gmail.com> writes: > x30 speedup vs. a Forth program targeted to a 68HC12 processor > While x30 speedup is not bad, I guess I was expecting greater gains > vs. any software algorithm compiled to run on a generic register based > processor. As I understand it, Forth processors probably take more instructions (or at least about the same number) as reasonably good compiled Forth code running on a register processor. The main reason the Forth processor is so much faster is that the simplified hardware allows running at much higher clock frequencies for a given amount of silicon and a given process technology. That 30x speedup is probably compared to an interpreter on an older cpu, so maybe there's a combination of newer process tech, avoiding interpretation overhead, and the clock speedup mentioned above.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-03-20 21:55 -1000 |
| Message-ID | <CLudnYSaybOUINfMnZ2dnUVZ_oidnZ2d@supernews.com> |
| In reply to | #20946 |
On 3/20/13 9:42 PM, Paul Rubin wrote: > AKE <assadebrahim2000@gmail.com> writes: >> x30 speedup vs. a Forth program targeted to a 68HC12 processor >> While x30 speedup is not bad, I guess I was expecting greater gains >> vs. any software algorithm compiled to run on a generic register based >> processor. > > As I understand it, Forth processors probably take more instructions (or > at least about the same number) as reasonably good compiled Forth code > running on a register processor. The main reason the Forth processor is > so much faster is that the simplified hardware allows running at much > higher clock frequencies for a given amount of silicon and a given > process technology. That 30x speedup is probably compared to an > interpreter on an older cpu, so maybe there's a combination of newer > process tech, avoiding interpretation overhead, and the clock speedup > mentioned above. > That x30 is pretty meaningless unless we know something about the Forth in question. Haskell says it's a subroutine-threaded model, and apparently he wrote it himself. We have no comparison of this with other 68HC12 Forths, so it's hard to judge the results. We see variations of x4 or more from different Forths for the same processor. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-21 16:22 +0100 |
| Message-ID | <kif8jl$iad$1@online.de> |
| In reply to | #20946 |
Paul Rubin wrote: > As I understand it, Forth processors probably take more instructions (or > at least about the same number) as reasonably good compiled Forth code > running on a register processor. The main reason the Forth processor is > so much faster is that the simplified hardware allows running at much > higher clock frequencies for a given amount of silicon and a given > process technology. That 30x speedup is probably compared to an > interpreter on an older cpu, so maybe there's a combination of newer > process tech, avoiding interpretation overhead, and the clock speedup > mentioned above. To throw in some numbers: The b16 was developed as a "response" to the 8051 I had to put on silicon as the customer wished so. This was a 0.5ยต process, and the 8051, a two-cycle machine, could barely run at 16MHz (which makes it 8 MIPS for simple instructions). The b16 trial synthesis would have run IIRC at ~200MHz, single-cycle instructions. The flash for reading the instructions from then would have limited the speed to ~75 MIPS, it would have been the bottleneck (40ns access time, SRAM is much faster, so in case speed would have mattered, the performance critical parts of the program could have moved to SRAM). For the 8051, the flash was not the bottleneck. For this kind of small controller, speed is rarely a real problem. The 8051 application had some issues, it was too slow. But with our b16 products, speed was always like Rolls Royce motors: "more than enough". I could give another figure: The battery monitor was - a decade earlier, not by me - implemented in a PIC16, and did take (for one calculation slot) about 70ms at 500kHz. Given that the PIC16 is a four-phase CPU, these are about 17k instructions. The b16 program completed in <4k instructions, adding bilinear interpolations to the tables, which we didn't dare on the PIC16 (too slow). There's one particular point, where I agree with Hugh: Small controllers should be programmed in their respective assembly language, not with any other layer of abstraction in between hardware and programmer. This is why it makes so much sense to have a Forth processor there: It's kind of a HLL, and certainly easier to program than assembler. I recall a very small Forth processor (4 bit architecture), which could be said to be a commercial success: The MARC4. It was later bought by Atmel. That's about the right size to make a successful language-specific processor, because this sort of processor will always only be used in its native language. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | AKE <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2013-03-21 10:59 -0700 |
| Message-ID | <cc66e19c-8d17-449d-acf6-226b792f1b31@googlegroups.com> |
| In reply to | #20974 |
On Thursday, March 21, 2013 3:22:28 PM UTC, Bernd Paysan wrote: > > I recall a very small Forth processor (4 bit architecture), which could be > said to be a commercial success: The MARC4. It was later bought by Atmel. > That's about the right size to make a successful language-specific > processor, because this sort of processor will always only be used in its > native language. > > Interesting -- hadn't heard of this one. Link to the MARC4 datasheet from Atmel: http://www.atmel.com/Images/doc4747.pdf
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-04-05 16:05 -0400 |
| Message-ID | <kjnamh$2hb$1@dont-email.me> |
| In reply to | #20946 |
On 3/21/2013 3:42 AM, Paul Rubin wrote: > AKE<assadebrahim2000@gmail.com> writes: >> x30 speedup vs. a Forth program targeted to a 68HC12 processor >> While x30 speedup is not bad, I guess I was expecting greater gains >> vs. any software algorithm compiled to run on a generic register based >> processor. > > As I understand it, Forth processors probably take more instructions (or > at least about the same number) as reasonably good compiled Forth code > running on a register processor. The main reason the Forth processor is > so much faster is that the simplified hardware allows running at much > higher clock frequencies for a given amount of silicon and a given > process technology. That 30x speedup is probably compared to an > interpreter on an older cpu, so maybe there's a combination of newer > process tech, avoiding interpretation overhead, and the clock speedup > mentioned above. There are far too many generalizations involved. Even apples vs apples comparisons can end up being between a golden delicious and a granny smith. Any comparison is only good for some specific purpose. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-21 04:42 -0500 |
| Message-ID | <y-OdnQYMrPaBS9fMnZ2dnUVZ_jidnZ2d@supernews.com> |
| In reply to | #20926 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > > In a private email, someone commented to me that stack machine > hardware is a substitute for a good code generator. That's true: by closing the semantic gap betwen language and machine, you make the need for a complex layer of software go away. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2013-03-21 10:54 +0000 |
| Message-ID | <514ae611.649429619@news.demon.co.uk> |
| In reply to | #20954 |
On Thu, 21 Mar 2013 04:42:52 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Stephen Pelc <stephenXXX@mpeforth.com> wrote: >> >> In a private email, someone commented to me that stack machine >> hardware is a substitute for a good code generator. > >That's true: by closing the semantic gap betwen language and machine, >you make the need for a complex layer of software go away. At the cost of writing another one. The choice is to buy an off the shelf chip and write a complex compiler, or to write a simple compiler and a CPU. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-21 16:37 +0100 |
| Message-ID | <kif9gn$irg$1@online.de> |
| In reply to | #20961 |
Stephen Pelc wrote: > On Thu, 21 Mar 2013 04:42:52 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: >>That's true: by closing the semantic gap betwen language and machine, >>you make the need for a complex layer of software go away. > > At the cost of writing another one. The choice is to buy an off the > shelf chip and write a complex compiler, or to write a simple compiler > and a CPU. Then you can compare: The cost of an off-the-shelf 8051 is between $10k and $100k. The cost of integrating it into a chip is 3 months of Bernd's salery, and, due to the bugs in the $100k industry standard stuff, you need three mask spins to get it right ($300k), and are one year late to market (another year for struggling with the 8051, to get the software right). The cost of writing a Forth CPU is one week of Bernd's salery, and you save 10 cents die size cost per chip you sell, and we did have first-time-right silicons. Plus you don't need to write a good code generator for the 8051, which is for sure in the "priceless" category. I think it only pays off if your volume is too low to do your own chip. Which, for this cheap consumer products, is a show-stopper for the entire business plan. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-03-22 08:34 -0700 |
| Message-ID | <571399f8-4c85-4b30-a4e5-c72e73cdde27@googlegroups.com> |
| In reply to | #20954 |
On Thursday, March 21, 2013 2:42:52 AM UTC-7, Andrew Haley wrote: > Stephen Pelc wrote: > > > In a private email, someone commented to me that stack machine > > hardware is a substitute for a good code generator. > > That's true: by closing the semantic gap between language and machine, > you make the need for a complex layer of software go away. > This would encourage MPE to favor register machines, such as the very popular ARM, and think of stack machines as the red headed stepchild. To be fair to register machines, they do have an advantage in that they can be deeply pipelined to get a faster clock speed. OTOH, this makes a difference more in application processors than in control processors. With the latter, requirements are more bounded so you don't need "as fast as possible".
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-22 10:44 -0500 |
| Message-ID | <CZydnTqu3onQ4dHMnZ2dnUVZ_rCdnZ2d@supernews.com> |
| In reply to | #21044 |
Brad Eckert <hwfwguy@gmail.com> wrote: > On Thursday, March 21, 2013 2:42:52 AM UTC-7, Andrew Haley wrote: >> Stephen Pelc wrote: >> >> > In a private email, someone commented to me that stack machine >> > hardware is a substitute for a good code generator. >> >> That's true: by closing the semantic gap between language and machine, >> you make the need for a complex layer of software go away. >> > This would encourage MPE to favor register machines, such as the > very popular ARM, and think of stack machines as the red headed > stepchild. Why? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-22 21:00 +0100 |
| Message-ID | <kiid96$4lb$1@online.de> |
| In reply to | #21044 |
Stephen Pelc wrote: > Rather than pushing us to register machines, it pushes us to popular > commercial CPUs, which happen to be register machines. Register > machines happen to good at code like > dup 2 cells + @ > which require only one instruction when indexed addressing is > available. On register machines, several common Forth patterns > reduce to fewer machine instructions than Forth source tokens. That's somehow missing the point. Simple stack machines like the b16 certainly rarely spent their precious opcode space for @+offset instructions, but e.g. the 4stack can do the above in the load/store unit (occupying both slots, one for the load, one for the immediate, i.e. you can't pair this with another load, though there are two load/store units. This is an artefact of the code word compression). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-22 21:04 +0100 |
| Message-ID | <kiidgm$4sl$1@online.de> |
| In reply to | #21044 |
Brad Eckert wrote:
> To be fair to register machines, they do have an advantage in that they
> can be deeply pipelined to get a faster clock speed.
This doesn't help them, compared to stack machines. They need the deep
pipeline to be equally fast. A stack machine is internally something like
TOS \
ALU -> TOS
NOS /
and TOS+NOS are directly connected to the ALU (as DFFs). If you have a
register file, you need such a structure, too, it's called the bypass logic.
Unlike a stack machine, you need an additional multiplexer to feed in values
from the register file. If you don't use a bypass logic, you can't have
dependend single-cycle operations.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-04-05 16:34 -0400 |
| Message-ID | <kjncbi$eal$1@dont-email.me> |
| In reply to | #21053 |
On 3/22/2013 4:04 PM, Bernd Paysan wrote: > Brad Eckert wrote: >> To be fair to register machines, they do have an advantage in that they >> can be deeply pipelined to get a faster clock speed. > > This doesn't help them, compared to stack machines. They need the deep > pipeline to be equally fast. A stack machine is internally something like > > TOS \ > ALU -> TOS > NOS / > > and TOS+NOS are directly connected to the ALU (as DFFs). If you have a > register file, you need such a structure, too, it's called the bypass logic. > Unlike a stack machine, you need an additional multiplexer to feed in values > from the register file. If you don't use a bypass logic, you can't have > dependend single-cycle operations. I've never heard the term "bypass logic" before. I also don't know what you mean by "dependend" [sic]. I'm sure you mean depended, but I'm still not sure what that is intended to represent. In general I think your comparison is a bit simplistic. The register file must include multiplexors to select which registers are used at the inputs to the ALU. But the stack machine has to have a mux at the input to the TOS as well. In fact, I found in my design this is where the bulk of the LUTs were used, in that mux! Every item that can be pushed to the data stack must have an input to that mux. I think that was some 13 items in my design with only two of them having to do with I/O. Many stack designs also include a mux at the input to the NOS to support some of the more complex stack ops. A register file in an FPGA comes with a very highly optimized mux for the RAM itself whether from distributed memory or from block RAMs. I know you are working at the chip level, so your muxes are a bit more expensive. In an FPGA I get some amount of free muxes by using the RAM resources. But regardless, the stack machine uses its share of data and return path muxes as well. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-04-06 04:05 +0200 |
| Message-ID | <kjnvtd$uj$1@online.de> |
| In reply to | #21433 |
rickman wrote: > On 3/22/2013 4:04 PM, Bernd Paysan wrote: > I've never heard the term "bypass logic" before. There is a website called www.google.com, which probably could help you. Try putting it into quotes, as you want the combined term, not just sites that contain "bypass" and "logic". > I also don't know what you mean by "dependend" [sic]. "dependent." I'm German, we pronounce all closing consonants hard ;-). > I'm sure you mean depended, but I'm > still not sure what that is intended to represent. Let's say you have the following instructions, expressed as arithmetic assignments: r3 := r2 + r1 r4 := r3 + r5 Then the second instruction depends on completion of the first one. If you pipeline it in the typical read register | alu | write register fashion found in most RISC processors, you have to wait two cycles until you can start the second instruction. That sounds pretty slow. The solution to this is to use a "bypass logic", which injects the result of instruction 1 into instruction 2. > In general I think your comparison is a bit simplistic. The register > file must include multiplexors These things are called multiplexers. I'm sure you don't see the difference, because English people pronounce "er" more like "or" ;-). > to select which registers are used at the > inputs to the ALU. But the stack machine has to have a mux at the input > to the TOS as well. In fact, I found in my design this is where the > bulk of the LUTs were used, in that mux! Every item that can be pushed > to the data stack must have an input to that mux. Yes, but *that* multiplexer doesn't go away when you change the concept to a register architecture. All those different operations which all write their result to one register needs to go through this MUX. > I think that was some > 13 items in my design with only two of them having to do with I/O. Many > stack designs also include a mux at the input to the NOS to support some > of the more complex stack ops. > > A register file in an FPGA comes with a very highly optimized mux for > the RAM itself whether from distributed memory or from block RAMs. I > know you are working at the chip level, so your muxes are a bit more > expensive. In an FPGA I get some amount of free muxes by using the RAM > resources. But regardless, the stack machine uses its share of data and > return path muxes as well. Yes, the FPGA has a much faster RAM than real hardware, or let's say it: it has much slower logic than real hardware of the same structure size, but the RAM is equal. Therefore, your cycle time doesn't increase much. You probably need two dual ported RAM blocks with identical content to get two reads and one write in one cycle (write to both at the same location, read from both asynchronously at different locations). FPGA design indeed has other tradeoffs. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-04-06 17:11 -0400 |
| Message-ID | <kjq2tb$38r$1@dont-email.me> |
| In reply to | #21451 |
On 4/5/2013 10:05 PM, Bernd Paysan wrote: > rickman wrote: > >> On 3/22/2013 4:04 PM, Bernd Paysan wrote: >> I've never heard the term "bypass logic" before. > > There is a website called www.google.com, which probably could help you. > Try putting it into quotes, as you want the combined term, not just sites > that contain "bypass" and "logic". Smartass replies aren't useful. I tried googling it and after four pages of hits didn't find anything explanatory. >> I also don't know what you mean by "dependend" [sic]. > > "dependent." I'm German, we pronounce all closing consonants hard ;-). > >> I'm sure you mean depended, but I'm >> still not sure what that is intended to represent. > > Let's say you have the following instructions, expressed as arithmetic > assignments: > > r3 := r2 + r1 > r4 := r3 + r5 > > Then the second instruction depends on completion of the first one. If > you pipeline it in the typical read register | alu | write register > fashion found in most RISC processors, you have to wait two cycles until > you can start the second instruction. That sounds pretty slow. > > The solution to this is to use a "bypass logic", which injects the result > of instruction 1 into instruction 2. So why wouldn't a stack machine need this? >> In general I think your comparison is a bit simplistic. The register >> file must include multiplexors > > These things are called multiplexers. I'm sure you don't see the > difference, because English people pronounce "er" more like "or" ;-). Or maybe you don't understand English well enough to know that both spellings are used. You might try using google to see that... Google is your friend! >> to select which registers are used at the >> inputs to the ALU. But the stack machine has to have a mux at the input >> to the TOS as well. In fact, I found in my design this is where the >> bulk of the LUTs were used, in that mux! Every item that can be pushed >> to the data stack must have an input to that mux. > > Yes, but *that* multiplexer doesn't go away when you change the concept to > a register architecture. All those different operations which all write > their result to one register needs to go through this MUX. > >> I think that was some >> 13 items in my design with only two of them having to do with I/O. Many >> stack designs also include a mux at the input to the NOS to support some >> of the more complex stack ops. >> >> A register file in an FPGA comes with a very highly optimized mux for >> the RAM itself whether from distributed memory or from block RAMs. I >> know you are working at the chip level, so your muxes are a bit more >> expensive. In an FPGA I get some amount of free muxes by using the RAM >> resources. But regardless, the stack machine uses its share of data and >> return path muxes as well. > > Yes, the FPGA has a much faster RAM than real hardware, or let's say it: > it has much slower logic than real hardware of the same structure size, > but the RAM is equal. Therefore, your cycle time doesn't increase much. > You probably need two dual ported RAM blocks with identical content to get > two reads and one write in one cycle (write to both at the same location, > read from both asynchronously at different locations). > > FPGA design indeed has other tradeoffs. I'm not sure what "real" hardware is really. I also can't make a lot of sense from this. The cycle time doesn't increase much... when? BTW, most block rams have two ports. You can do one operation on each port on each clock cycle. 2 reads, 2 writes, 1 read/1 write. In other words, the limiting feature is the address bus. There are two of them. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-04-08 19:47 +0200 |
| Message-ID | <kjuvsf$ng8$1@online.de> |
| In reply to | #21467 |
rickman wrote: > Smartass replies aren't useful. I tried googling it and after four > pages of hits didn't find anything explanatory. Must be your filter bubble. The first hit I get is a PDF with slides, which explains it pretty well, including nice drawings: http://people.ee.duke.edu/~sorin/prior-courses/ece152-spring2009/lectures/5.3-pipelining.pdf >> The solution to this is to use a "bypass logic", which injects the result >> of instruction 1 into instruction 2. > > So why wouldn't a stack machine need this? Because it does not need to access a register file to get TOS and NOS. These DFFs don't need any indirection, they are directly sourcing the ALU inputs, and the output of the instruction MUX (selecting between ALU and fetch) goes directly into TOS. > Or maybe you don't understand English well enough to know that both > spellings are used. You might try using google to see that... Google > is your friend! Yes. Google found "Results for 'multiplexers'. Search instead for 'multiplexors'". That's a strong hint that I was misspelling the word, and that this happens rather often. If I insist, I get results for any misspelling I want ;-). Maybe filter bubble again... The ratio multiplexers:multiplexors is just 2:1, so it's pretty common, and the fact that I'm getting redirected means someone at Google is really mad about this misspelling ;-). >> FPGA design indeed has other tradeoffs. > > I'm not sure what "real" hardware is really. I also can't make a lot of > sense from this. The cycle time doesn't increase much... when? When you have async block RAM. As you discovered, new FPGAs have sync block RAM, which means you get that cycle adder you see in "real hardware", too. The FPGA is a hardware emulator for hardware design. By emulating gates and wires with SRAM-based logic cells, you increase the gate delay of logic cells easily by a factor of 5-10. You don't increase the delay of RAMs, because they are just RAMs, without emulation. > BTW, most block rams have two ports. You can do one operation on each > port on each clock cycle. 2 reads, 2 writes, 1 read/1 write. In other > words, the limiting feature is the address bus. There are two of them. Yes, I know. In "real hardware" you don't do this, because it's about twice as large as a single-ported memory. So unless you can't avoid the dual- ported RAM, you use a single-ported RAM. I've once spent a few weeks to convert some FPGA design with dual ported RAMs to single ported RAMs, and that reduced the area of the total chip by 1/4th or so. From "won't fit" to "pad/core-limited" which is the point when you don't need to bother much about further squeezing the design. -- 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 | 2013-03-22 18:10 +0000 |
| Message-ID | <514c9da2.761958522@news.demon.co.uk> |
| In reply to | #21044 |
On Fri, 22 Mar 2013 08:34:09 -0700 (PDT), Brad Eckert <hwfwguy@gmail.com> wrote: >On Thursday, March 21, 2013 2:42:52 AM UTC-7, Andrew Haley wrote: >> Stephen Pelc wrote: >>=20 >> > In a private email, someone commented to me that stack machine >> > hardware is a substitute for a good code generator. >>=20 >> That's true: by closing the semantic gap between language and machine, >> you make the need for a complex layer of software go away. >>=20 >This would encourage MPE to favor register machines, such as the very popul= >ar ARM, and think of stack machines as the red headed stepchild. > >To be fair to register machines, they do have an advantage in that they can= > be deeply pipelined to get a faster clock speed. OTOH, this makes a differ= >ence more in application processors than in control processors. With the la= >tter, requirements are more bounded so you don't need "as fast as possible"= >. Rather than pushing us to register machines, it pushes us to popular commercial CPUs, which happen to be register machines. Register machines happen to good at code like dup 2 cells + @ which require only one instruction when indexed addressing is available. On register machines, several common Forth patterns reduce to fewer machine instructions than Forth source tokens. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-04-05 10:44 -0400 |
| Message-ID | <kjn7fb$agu$2@dont-email.me> |
| In reply to | #20926 |
On 3/20/2013 2:41 PM, Stephen Pelc wrote: > On Wed, 20 Mar 2013 09:34:35 -0700 (PDT), AKE > <assadebrahim2000@gmail.com> wrote: > >> So with FPGA / PLD technology having advanced considerably over the last de= >> cade or so, presumably now the requirement for silicon can be relaxed, remo= >> ving the costs of fabrication from consideration? > > FPGAs are not particularly cheap, their advantage is in the custom > peripherals that you define yourself. Plenty of our customers use > an off-the-shelf CPU with a smaller FPGA for custom peripherals. I get tired of hearing the myth that FPGAs are not cheap. You can get low end FPGAs under $3 with more than enough capacity to implement multiple processors. At high volumes I am led to believe the cost can get under $1. The last product I built used an FPGA instead of a processor just because a PLD was required for an interface while a processor was not required at all! The signal processing could be done in the FPGA in a direct manner and if needed a processor could have been added to the FPGA. >> Given the simplicity / appeal of the stack model (at least to people who li= >> ke Forth), and the 'low impedance' benefits that go along, in principle, wi= >> th a processor instruction matched closely to the programming language (fas= >> ter development and testing, better factored code, predictable running time= >> s, and significantly reduced complexity of compilers), I would expect there= >> to either have been or soon to come a resurgence of Forth processors -- no= >> t in silicon now, but in reconfigurable computing devices. > > Complete determinism is probably the only significant remaining > design goal, but you do not have to use a stack machine to get that. > A good example of Forth engine for hard real time is MicroCore: > http://www.microcore.org/ > Also interesting is the NIGE machine, from EuroForth 2012 > http://www.complang.tuwien.ac.at/anton/euroforth/ef12/papers/read.pdf > https://github.com/Anding/N.I.G.E.-Machine > > In a private email, someone commented to me that stack machine > hardware is a substitute for a good code generator. Do you consider that to be true? Is a code generator for a small, register based CPU like one of the low end PICs really that difficult? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-04-05 22:12 +0200 |
| Message-ID | <kjnb87$jo8$1@online.de> |
| In reply to | #21426 |
rickman wrote: > I get tired of hearing the myth that FPGAs are not cheap. You can get > low end FPGAs under $3 with more than enough capacity to implement > multiple processors. At high volumes I am led to believe the cost can > get under $1. Altera still has this "Hardcopy" program, which is about the last logic gate array standing. The hardcopy chips can be programmed with a single mask or so, because Altera converted all the setting bits into vias; and the result is that they had the cheapest gate array on the market (all other gate arrays require three masks), "cheap" as in "setup costs", the die area is bigger than other gate arrays; but then you have the embedded RAMs and multipliers, which - when used - gives you a much better density. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web