Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #34459 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2014-11-17 02:26 -0800 |
| Last post | 2014-11-21 15:42 -0800 |
| Articles | 19 on this page of 159 — 23 participants |
Back to article view | Back to comp.lang.forth
http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? JUERGEN <epldfpga@aol.com> - 2014-11-17 02:26 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-11-17 14:24 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-17 14:04 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? visualforth@rocketmail.com - 2014-11-17 18:37 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? hughaguilar96@yahoo.com - 2014-11-17 19:58 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-18 04:56 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-18 19:10 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-18 14:06 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-23 19:43 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-18 16:16 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? visualforth@rocketmail.com - 2014-11-18 15:49 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-23 19:45 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-23 23:45 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-24 17:18 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-23 14:04 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-23 11:25 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-24 09:36 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-24 06:02 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-24 13:04 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-24 14:50 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-24 14:06 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Alex McDonald" <blog@rivadpm.com> - 2014-11-24 16:38 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-24 09:04 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-24 16:16 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-24 12:57 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-25 16:18 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-25 14:40 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-26 00:48 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-25 19:10 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-26 02:09 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-26 11:22 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-26 16:11 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-25 16:57 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-26 03:51 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-27 16:10 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-27 10:39 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-28 15:27 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-28 10:26 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-29 01:03 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-29 15:27 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-29 19:04 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-30 15:48 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-30 17:36 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-03 14:25 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? hughaguilar96@gmail.com - 2014-12-04 20:04 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-04 08:37 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-04 21:39 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-05 03:31 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-05 18:33 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-05 14:56 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-29 13:07 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-29 16:00 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-29 11:21 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-30 15:26 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-30 12:49 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-24 18:34 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-25 16:04 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-25 14:48 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-26 00:49 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-25 21:07 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-26 11:45 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-11-26 12:44 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-26 14:11 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-26 16:17 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-26 23:27 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-27 12:28 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-27 09:20 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-27 15:59 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-27 10:42 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-28 15:44 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-28 10:35 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-29 15:38 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-29 19:10 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-30 16:09 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-30 17:40 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-03 16:47 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-04 21:22 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-05 12:37 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-05 19:02 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-06 12:09 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? JUERGEN <epldfpga@aol.com> - 2014-12-06 06:45 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-06 19:58 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-07 13:39 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-12-07 08:04 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-07 22:52 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-10 12:46 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-11 02:08 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-11 10:20 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-11 05:06 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2014-12-11 17:56 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Alex McDonald" <blog@rivadpm.com> - 2014-12-15 15:57 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-16 07:53 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? JUERGEN <epldfpga@aol.com> - 2014-12-17 08:49 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-11 23:46 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-12-11 16:24 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Julian Fondren <julian.fondren@gmail.com> - 2014-12-11 17:46 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-12-11 22:20 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-13 00:24 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-12-12 18:39 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-13 21:06 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-12-13 22:58 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Mark Wills <markwills1970@gmail.com> - 2014-12-04 03:38 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Horse Shit <puke.aguilar@hughfailure.com> - 2014-12-04 13:29 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? JUERGEN <epldfpga@aol.com> - 2014-11-28 05:36 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-28 10:37 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-26 01:14 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-23 20:57 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-24 03:59 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-24 02:14 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-24 06:09 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-24 11:04 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-24 11:49 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-24 13:57 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-24 12:28 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-24 14:50 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-24 13:22 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-24 16:15 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-24 14:38 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-25 01:52 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-25 11:43 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-25 03:35 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-25 09:37 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-26 03:57 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-25 11:16 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-25 02:06 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-24 21:40 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-24 23:57 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-25 03:37 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-25 03:43 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-25 15:26 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-25 15:47 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-25 03:30 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-25 09:32 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-25 11:11 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-24 12:24 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-25 09:45 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-24 10:17 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-17 23:20 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-11-17 23:31 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-18 02:44 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-11-18 00:18 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-18 13:51 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-18 12:06 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Elizabeth D Rather <erather@forth.com> - 2014-11-18 09:23 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Paul Rubin <no.email@nospam.invalid> - 2014-11-18 08:09 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? rickman <gnuarm@gmail.com> - 2014-11-18 18:01 -0500
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Elizabeth D Rather <erather@forth.com> - 2014-11-17 21:58 -1000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-18 14:04 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-18 18:53 +0100
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-18 14:15 -0600
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-23 13:40 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? hughaguilar96@yahoo.com - 2014-11-18 17:48 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-23 14:24 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-23 16:53 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? stephen@mpeforth.com (Stephen Pelc) - 2014-11-23 17:26 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? Mark Wills <markwills1970@gmail.com> - 2014-11-18 03:34 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? m.a.m.hendrix@tue.nl - 2014-11-18 04:19 -0800
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-23 13:50 +0000
Re: http://www.lowrisc.org/ Open Core - is the Forth Community involved in this new 64Bit Core? visualforth@rocketmail.com - 2014-11-21 15:42 -0800
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-11-18 00:18 -0800 |
| Message-ID | <406422bb-8329-474d-b28f-4db9aaee0d68@googlegroups.com> |
| In reply to | #34475 |
> As to your preference for C, I can only say that if you don't comment > your Forth code well enough, it is likely that your C code is also not > commented well enough. In fact, I have seldom seen code that was > adequately commented, including my own. I find this when returning to > code a month or two later and even more so when returning to code a year > or two later. > > -- > > Rick I'm never satisfied with my commenting, although I think that I'm on 6-7 on a 1-10 scale :) I also had to port C code with barely any comment at all, so I'm sure that there can be worse cases... All I'm saying that C helps in this respect, Forth doesn't. In forth you have to put more effort in commenting, that's a fact. I always find myself reading forth code and encounter words that I don't know the stack effect. Not standard words, of course, user words that may be defined previously in the same file (better) or on other files (worse). And frankly, you cannot put stack effect comments on every such word... You have to continually cross-reference such words just for the stack effect. Not good. In this respect a good IDE will help, for example C has many IDE's that when you put the mouse over a function name, it shows you the function prototype. It's just woderfull even for C. But the forthers don't like IDEs at all. It's a paradox :)
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-11-18 13:51 +0000 |
| Message-ID | <546b4eeb$0$15865$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #34478 |
In article <406422bb-8329-474d-b28f-4db9aaee0d68@googlegroups.com>, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >> As to your preference for C, I can only say that if you don't comment >> your Forth code well enough, it is likely that your C code is also not >> commented well enough. In fact, I have seldom seen code that was >> adequately commented, including my own. I find this when returning to >> code a month or two later and even more so when returning to code a year >> or two later. >> >> -- >> >> Rick > >I'm never satisfied with my commenting, although I think that I'm on 6-7 >on a 1-10 scale :) I also had to port C code with barely any comment at >all, so I'm sure that there can be worse cases... >All I'm saying that C helps in this respect, Forth doesn't. In forth you >have to put more effort in commenting, that's a fact. I always find >myself reading forth code and encounter words that I don't know the >stack effect. Not standard words, of course, user words that may be >defined previously in the same file (better) or on other files (worse). >And frankly, you cannot put stack effect comments on every such word... >You have to continually cross-reference such words just for the stack >effect. Not good. >In this respect a good IDE will help, for example C has many IDE's that >when you put the mouse over a function name, it shows you the function >prototype. It's just woderfull even for C. But the forthers don't like >IDEs at all. It's a paradox :) It has been shot down (especially by Samuel Falvo, the only one who cared to look, and someone I respect), but I've this syntax coloring-the-stack-effect The first character of a word gives the input, the last character gives the output. That means green is one,lightgreen is two,yellow is three etc. That really helps to see how the data is flowing though a word. You can find it one my website below. The disadvantage is that it must be tightly coupled to an introspective Forth, one who know all its stack effects. (There are codes though for variable and unknown stack effects.) The idea doesn't sit well with the syntax highlighting of e.g. vim. I've not seen a highlighter that can do two different colors plus no color in one syntactic element. I'm pretty sure this means IDE. It would be interesting to add to Eclipse. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-18 12:06 -0500 |
| Message-ID | <m4fuc8$voe$1@dont-email.me> |
| In reply to | #34478 |
On 11/18/2014 3:18 AM, Raimond Dragomir wrote: >> As to your preference for C, I can only say that if you don't comment >> your Forth code well enough, it is likely that your C code is also not >> commented well enough. In fact, I have seldom seen code that was >> adequately commented, including my own. I find this when returning to >> code a month or two later and even more so when returning to code a year >> or two later. >> >> -- >> >> Rick > > I'm never satisfied with my commenting, although I think that I'm on 6-7 on a 1-10 scale :) I also had to port C code with barely any comment at all, so I'm sure that there can be worse cases... > All I'm saying that C helps in this respect, Forth doesn't. In forth you have to put more effort in commenting, that's a fact. I always find myself reading forth code and encounter words that I don't know the stack effect. Not standard words, of course, user words that may be defined previously in the same file (better) or on other files (worse). And frankly, you cannot put stack effect comments on every such word... You have to continually cross-reference such words just for the stack effect. Not good. > In this respect a good IDE will help, for example C has many IDE's that when you put the mouse over a function name, it shows you the function prototype. It's just woderfull even for C. But the forthers don't like IDEs at all.. It's a paradox :) I think I know what you mean. I have experienced the same feeling of having to remember so many Forth words that my head explodes. But I think the problem is mitigated by the shortness of most Forth words. Many can be examined without digging into the lower level words as long as you have some idea of what they are doing. Once I got the hang of it I found it wasn't so bad. It is always worse reading someone else's code in any language. I know what you mean about the IDE. Forth IDEs are usually not so full featured but then I haven't used a commercial one. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-11-18 09:23 -1000 |
| Message-ID | <VsydnaszFIwxAfbJnZ2dnUU7-KOdnZ2d@supernews.com> |
| In reply to | #34478 |
On 11/17/2014 10:18 PM, Raimond Dragomir wrote: >> As to your preference for C, I can only say that if you don't comment >> your Forth code well enough, it is likely that your C code is also not >> commented well enough. In fact, I have seldom seen code that was >> adequately commented, including my own. I find this when returning to >> code a month or two later and even more so when returning to code a year >> or two later. >> >> -- >> >> Rick > > I'm never satisfied with my commenting, although I think that I'm on 6-7 on a 1-10 scale :) I also had to port C code with barely any comment at all, so I'm sure that there can be worse cases... > All I'm saying that C helps in this respect, Forth doesn't. In forth you have to put more effort in commenting, that's a fact. I always find myself reading forth code and encounter words that I don't know the stack effect. Not standard words, of course, user words that may be defined previously in the same file (better) or on other files (worse). And frankly, you cannot put stack effect comments on every such word... You have to continually cross-reference such words just for the stack effect. Not good. > In this respect a good IDE will help, for example C has many IDE's that when you put the mouse over a function name, it shows you the function prototype. It's just woderfull even for C. But the forthers don't like IDEs at all. It's a paradox :) > SwiftForth has what I think is a pretty good IDE. We put a lot of effort into it. Our Linux and OSX versions don't use it, because Linux customers (who are also our main OSX users) are pretty command-line oriented. You should try it! 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-18 08:09 -0800 |
| Message-ID | <7xtx1webi1.fsf@ruckus.brouhaha.com> |
| In reply to | #34475 |
rickman <gnuarm@gmail.com> writes: > I don't know what REPL is, so I can't comment on that. But otherwise > I think you agreed with me that it is hard to make the design of a > RISC CPU unsuitable for Forth. REPL (read-eval-print loop) is a Lisp term that means an interactive interpreter where you can type stuff and see the results immediately, define new functions and test them one at a time, etc. The Forth term for it is "text interpreter" but it more specifically connotes interactive use.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-18 18:01 -0500 |
| Message-ID | <m4gj47$g94$7@dont-email.me> |
| In reply to | #34488 |
On 11/18/2014 11:09 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I don't know what REPL is, so I can't comment on that. But otherwise >> I think you agreed with me that it is hard to make the design of a >> RISC CPU unsuitable for Forth. > > REPL (read-eval-print loop) is a Lisp term that means an interactive > interpreter where you can type stuff and see the results immediately, > define new functions and test them one at a time, etc. The Forth term > for it is "text interpreter" but it more specifically connotes > interactive use. Ok, now that I know what it means, I don't see how it applies in the original context. Why would an optimized Forth lose the REPL capability? Does it run too slowly to interpret an input line and execute it in a brief time? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-11-17 21:58 -1000 |
| Message-ID | <IMidnYRYH7WtYffJnZ2dnUU7-d2dnZ2d@supernews.com> |
| In reply to | #34474 |
On 11/17/2014 9:31 PM, Raimond Dragomir wrote: > marți, 18 noiembrie 2014, 06:21:34 UTC+2, rickman a scris: >> On 11/17/2014 5:26 AM, JUERGEN wrote: >>> Is anybody here involved in thei project, to make them aware of requirements to run Forth efficiently? >>> >>> http://www.lowrisc.org/ >>> >>> From the website: >>> >>> lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco-system. >>> >>> Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. There are more details on our plans in these slides from a recent talk >>> >>> lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community. >>> >>> To keep track of the project, follow @lowRISC or join our announcements list by entering your email below: >> >> I'm curious, why do you think this processor might *not* implement Forth >> efficiently? In reality Forth is just a language and can be implemented >> as efficiently as any other language on a given machine. It just >> requires a well written compiler. >> >> -- >> >> Rick > > Well, forth may be just a language, but it has an explicit stack which will make its life harder on register based architectures. Forth can compete with C compilers on older processors with very few registers (Z80, HC08, etc) where the C is forced to do parameter passing on stack, like the forth. On the new architectures with lots of registers, there is virtually no parameter passing on stack anymore, almost all parameters are passed in registers. This is hard to fit in a forth compiler. All that a forth compiler can do is to optimize the local body of a function to use registers as much as possible, and the resulting code will hardly look like the original source. I don't know if this is good or bad, C uses the same approach, but C at least doesn't claim to be REPL, and when forth looses its REPL, what else it remains? I personally find that for big designs, the C is better mostly because it is just more descriptive and self commenting due to the explicit parameter passing. Every thing in C have names, parameters, local variables. In forth parameters are hidden, even some locals are hidden because of the use of stack instead of local variables. This is a big minus for forth, at least regarding big projects. When you read forth sources, you invariably find names that you just don't know (or just forgot) what parameters are they expected on the stack and what results they leave. Hmmm, many comments. * Forth has been running on register-based architectures for over 40 years, including not only those with few registers as well as later cpus with more (and more, and the list goes on). * There's a wide range of Forth compilers, many of which generate very good code and deliver excellent performance. * I don't understand your REPL issue. Modern Forths with optimizing compilers cannot regenerate source from compiled code, but most come with source and good debugging features. * Competently-written Forth code documents its stack arguments, so the only thing you're missing in terms of parameter passing is the extra code that C needs to manage its parameters and Forth doesn't. * Good Forth compilers have features that help you LOCATE the source for names you "just don't know (or just forgot), which should include the stack documentation and other usage commentary. I'll grant that incompetently-written Forth has readability issues. I'll bet incompetently written C does, too. I suspect you haven't spent much time with modern, professional-grade Forths. 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-11-18 14:04 +0000 |
| Message-ID | <546b51f5$0$15906$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #34477 |
In article <IMidnYRYH7WtYffJnZ2dnUU7-d2dnZ2d@supernews.com>, Elizabeth D Rather <erather@forth.com> wrote: <SNIP> > >* Competently-written Forth code documents its stack arguments, so the >only thing you're missing in terms of parameter passing is the extra >code that C needs to manage its parameters and Forth doesn't. This only helps for those with photographic memory. If you're reading a word then you don't know the stack arguments of the words that are called. > >* Good Forth compilers have features that help you LOCATE the source for >names you "just don't know (or just forgot), which should include the >stack documentation and other usage commentary. True enough and helpful but in C you get a first shot at the meaning without looking something up. Even with an IDE-like LOCATE that executes while hovering over a word, this can be painful. And then if the documentation is in stackish ( n d -- u) instead of English, you get that information in C without looking up anything. Example q = ape( 16, note ); In the c context you know that q is an unsigned, 16 is obvious and note is a double. > >I'll grant that incompetently-written Forth has readability issues. I'll >bet incompetently written C does, too. I suspect you haven't spent much >time with modern, professional-grade Forths. I've seen a lot of incompetently written C. And it can be moderately easily followed. Of course reading code is not the final goal. You want to read it, understand it, and then get convinced that it is right, because mostly you read it to find a defect. There C has still an advantage over Forth. If a routine returns an int, it returns an int. If you read Forth code and the documentation says it returns an int, you still have to check. (The premise is that there is a defect, and you're searching for the cause.) > >Cheers, >Elizabeth Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-18 18:53 +0100 |
| Message-ID | <m4g11s$bav$1@dont-email.me> |
| In reply to | #34474 |
Raimond Dragomir wrote: > Well, forth may be just a language, but it has an explicit stack which > will make its life harder on register based architectures. Forth can > compete with C compilers on older processors with very few registers (Z80, > HC08, etc) where the C is forced to do parameter passing on stack, like > the forth. On the new architectures with lots of registers, there is > virtually no parameter passing on stack anymore, almost all parameters are > passed in registers. This is hard to fit in a forth compiler. All that a > forth compiler can do is to optimize the local body of a function to use > registers as much as possible, and the resulting code will hardly look > like the original source. I don't know if this is good or bad, C uses the > same approach, but C at least doesn't claim to be REPL, and when forth > looses its REPL, what else it remains? Native code Forths exist for quite some time, and systems like VFX or iForth compile code with similar speed as C compilers. And of course, both VFX and iForth still has an interpeter and a command line (REPL). A good backend doesn't mean batch compilation, and it also doesn't have to be awfully slow. For sure, analytical compilers are slower to compile code than threaded code or simple peephole optimizing native code compilers. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-18 14:15 -0600 |
| Message-ID | <N_6dneWWy9pRNfbJnZ2dnUU7-c2dnZ2d@supernews.com> |
| In reply to | #34474 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > All that a forth compiler can do is to optimize the local body of a > function to use registers as much as possible, and the resulting > code will hardly look like the original source. I don't know if this > is good or bad, C uses the same approach, but C at least doesn't > claim to be REPL, and when forth looses its REPL, what else it > remains? Okay, let's pick this apart a bit. There's nothing about Forth which prevents global optimizations. All you have to do is inline and then optimize the whole thing. Yes, there are limitations to how much of this you can do before you hit an optimization barrier (e.g. an EXECUTE with unpredictable stack) or run out of registers, but some Forths do this quite successfully. The text interpreter (what we call our REPL) functions perfectly well in such a scenario. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-23 13:40 +0000 |
| Message-ID | <2014Nov23.144011@mips.complang.tuwien.ac.at> |
| In reply to | #34499 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>There's nothing about Forth which prevents global optimizations. All
>you have to do is inline and then optimize the whole thing. Yes,
>there are limitations to how much of this you can do before you hit an
>optimization barrier (e.g. an EXECUTE with unpredictable stack)
And there are some Forths designed to eliminate such problems, in
particular PAF. In particular, PAF has tagged xts, and all xts with
the same tag are required to have the same stack effect. And the
replacement for EXECUTE may call only xts with a specific tag (this
restriction is not normally checked).
@InProceedings{ertl13-paf,
author = {M. Anton Ertl},
title = {{PAF}: A Portable Assembly Language},
crossref = {euroforth13},
pages = {30--38},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf},
OPTnote = {not refereed},
abstract = {A portable assembly language provides access to
machine-level features like memory addresses,
machine words, code addresses, and modulo
arithmetics, like assembly language, but abstracts
away differences between architectures like the
assembly language syntax, instruction encoding,
register set size, and addressing modes. Forth
already satisfies a number of the characteristics of
a portable assembly language, and is therefore a
good basis. This paper presents PAF, a portable
assembly language based on Forth, and specifically
discusses language features that other portable
assembly languages do not have, and their benefits;
it also discusses the differences from Forth. The
main innovations of PAF are: tags indicate the
control flow for indirect branches and calls; and
PAF has two kinds of calls and definitions: the ABI
ones follow the platform's calling convention and
are useful for interfacing to the outside world,
while the PAF ones allow tail-call elimination and
are useful for implementing general control
structures.}
}
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-11-18 17:48 -0800 |
| Message-ID | <2aaa490b-a09f-4a0a-a5cd-84a8249bb472@googlegroups.com> |
| In reply to | #34474 |
On Tuesday, November 18, 2014 12:31:58 AM UTC-7, Raimond Dragomir wrote: > Well, forth may be just a language, but it has an explicit stack which will make its life harder on register based architectures. Forth can compete with C compilers on older processors with very few registers (Z80, HC08, etc) where the C is forced to do parameter passing on stack, like the forth. On the new architectures with lots of registers, there is virtually no parameter passing on stack anymore, almost all parameters are passed in registers. This is hard to fit in a forth compiler. All that a forth compiler can do is to optimize the local body of a function to use registers as much as possible, and the resulting code will hardly look like the original source. I don't know if this is good or bad, C uses the same approach, but C at least doesn't claim to be REPL, and when forth looses its REPL, what else it remains? I've changed my compiler design; I now hold all local variables in registers for speed. One downside of this is that I can only allow a maximum of six locals in a function. This isn't much of a problem, because it is pretty rare for anybody to use more than four. Another downside, is that I now have a restricted use of quotations. Instead of pasting the local-frame together with the cfa to form an xt, I now just use the cfa as the xt, as there is no local-frame. The restriction is that the higher-order function can't use local variables at all (it can use >R that is on a different stack and doesn't clash) --- the result of this is that the parent function's locals are still in the registers when the quotation gets EXECUTEd inside of the higher-order function, and it has access to them. It is somewhat of an awkward restriction regarding the higher-order function not being allowed to use locals, but it results in very fast code. I'm targeting the AVR now. I figure if I can get my language to work on an AVR, I can get it to work on anything, as the AVR is the smallest processor in use today. Also, I'm generating compact code with very little inlining, so this works well with the AVR that is usually chosen because it is small and inexpensive. Also, AVR assembly-language is easy to learn because it is so simple. It lacks the BL of the ARM, which was pretty cool, but it has most everything that I need. It has pre-decrement and post-increment addressing-modes that are needed for stacks --- that is pretty much the primary feature that I look for in a processor to determine if Forth will work well or not --- I haven't looked at this RISC-V yet, so I don't know if it has this feature or not. I keep anywhere from 0 to 3 of the top stack elements in registers. I'm not just combining primitives together into "combos" as before, but I'm doing an actual analytic optimization now, to minimize how much push and pop of registers to the parameter-stack is done. You are totally mistaken when you say: "Forth can compete with C compilers on older processors with very few registers (Z80, HC08, etc) where the C is forced to do parameter passing on stack, like the forth." Forth needs two registers available that can be used for stack pointers (the return-stack and the parameter-stack). C only needs one register, as it puts parameters on the return-stack. It helps if it has a second register that can be used as a local-frame pointer (BP on the 8086), but this isn't strictly necessary, and it can get by with one register. A lot of the old processors, such as the 6808 that you mentioned, have only one register that can be used as a pointer. The 6808 has a lot of addressing modes for the return-stack pointer, because it is expecting parameters to be on the return-stack as done in C. It doesn't have a second register that can be used as a parameter-stack pointer as needed in Forth, so it is a terrible choice for Forth. It can use the H:X pair as a pointer, but this is really needed for @ and ! etc., so H:X can't be used a parameter-stack pointer. I looked into the 6808 when I was at Testra before the MiniForth project began. I quickly dismissed the 6808 as being useless for Forth. The Z80 is pretty much useless too, as the IX or IY registers can be used as a parameter-stack pointer, but they are incredibly slow. The 6812 could be used for Forth, but it is not a very good choice. It has very few registers. One of those registers can be used as a parameter-stack pointer, but this reduces the number of general-purpose registers significantly, so Forth is at a disadvantage compared to C in that the C system has more general-purpose registers available to play with, and hence can do better optimization. Weirdly enough, the 6809 had an extra U register that the 6812 lacks, although the 6812 was the upgrade from the 6809 --- I think the reason why Motorola failed in the micro-controller world, is because they kept changing their design, and none of their new processors were compatible with their old processors --- if you pull the rug out from under your customers' feet too many times, they eventually leave! All in all, 16 registers such as the AVR has, make Forth easy to implement --- the 8 registers of the 32-bit x86 or the PDP-11 are about the minimum that you would really want to target Forth for. After the AVR version is complete, I will most likely go to the PIC24 and make that version commercial --- the AVR version is just for fun --- the PIC24 is a pretty awesome processor by any standard.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-23 14:24 +0000 |
| Message-ID | <2014Nov23.152403@mips.complang.tuwien.ac.at> |
| In reply to | #34474 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>Well, forth may be just a language, but it has an explicit stack which will=
> make its life harder on register based architectures.
Harder than what? Sure, standard Forth needs extra effort compared to
PAF [ertl13-paf] for code that does not follow PAF restrictions, and
such code will be relatively slow. But every language has it's warts;
e.g., C has varargs, and they prevent tail call elimination.
In general, though, Forth has been designed as a language close to
hardware, and as a result, is relatively easy to implement on
hardware, even 44 years after its conception.
The stacks were originally designed to reside in memory, but the
actual usage is such that nearly all stack items can be mapped to
registers [ertl92]. No special stack hardware is needed.
Even for languages that are much farther from the hardware than Forth,
architectural support has not really caught on. E.g., SPARC has
special support for tagged data, but at least one significant LISP
compiler (Franz LISP IIRC) did not use that, as the benefits were not
enough to justify the additional implementation costs (the compiler
also had to implement a solution for architectures without such
instructions, and the tagging support in SPARC did not quite fit the
model that was best for the other architectures).
>Forth can compete wi=
>th C compilers on older processors with very few registers (Z80, HC08, etc)=
> where the C is forced to do parameter passing on stack, like the forth. On=
> the new architectures with lots of registers, there is virtually no parame=
>ter passing on stack anymore, almost all parameters are passed in registers=
>. This is hard to fit in a forth compiler.
Not really. It does take some effort, though.
> All that a forth compiler can do=
> is to optimize the local body of a function to use registers as much as po=
>ssible, and the resulting code will hardly look like the original source. I=
> don't know if this is good or bad, C uses the same approach, but C at leas=
>t doesn't claim to be REPL, and when forth looses its REPL, what else it re=
>mains?
Others have pointed out that the text interpreter (REPL) has nothing
to do with what the generated code looks like. But maybe you were
thinking of SEE, not the text interpreter. In a sophisticated Forth
system, one may have several ways to look at the source code or the
generated code of a word; e.g., Gforth has (from the most source-like
to the most target-like) Emacs or vi tags-search, SEE, SIMPLE-SEE, and
SEE-CODE. What is best to use depends on what one ist doing.
@InProceedings{ertl13-paf,
author = {M. Anton Ertl},
title = {{PAF}: A Portable Assembly Language},
crossref = {euroforth13},
pages = {30--38},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf},
OPTnote = {not refereed},
abstract = {A portable assembly language provides access to
machine-level features like memory addresses,
machine words, code addresses, and modulo
arithmetics, like assembly language, but abstracts
away differences between architectures like the
assembly language syntax, instruction encoding,
register set size, and addressing modes. Forth
already satisfies a number of the characteristics of
a portable assembly language, and is therefore a
good basis. This paper presents PAF, a portable
assembly language based on Forth, and specifically
discusses language features that other portable
assembly languages do not have, and their benefits;
it also discusses the differences from Forth. The
main innovations of PAF are: tags indicate the
control flow for indirect branches and calls; and
PAF has two kinds of calls and definitions: the ABI
ones follow the platform's calling convention and
are useful for interfacing to the outside world,
while the PAF ones allow tail-call elimination and
are useful for implementing general control
structures.}
}
@InProceedings{ertl92,
author = "M. Anton Ertl",
title = "A New Approach to {Forth} Native Code Generation",
crossref = "euroforth92",
pages = "73--78",
url = "http://www.complang.tuwien.ac.at/papers/ertl92.ps.gz",
abstract = "RAFTS is a framework for applying state of the art
compiler technology to the compilation of Forth. The
heart of RAFTS is a simple method for transforming
Forth programs into data flow graphs and static
single assignment form. Standard code generation and
optimization techniques can be applied to programs in
these forms. Specifically, RAFTS uses interprocedural
register allocation to eliminate nearly all stack
accesses. It also removes nearly all stack pointer
updates. Inlining and tail call optimization reduce
the call overhead. RAFTS compiles all of Forth,
including difficult cases like unknown stack heights,
{\tt PICK}, {\tt ROLL} and {\tt EXECUTE}. And last,
but not least, RAFTS is designed for interactive
Forth systems; it is not restricted to batch
compilers"
}
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-11-23 16:53 +0000 |
| Message-ID | <54721125$0$15892$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #34474 |
In article <354f6fc9-7a56-4e7f-9336-2c3aa0003eb5@googlegroups.com>, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >Well, forth may be just a language, but it has an explicit stack which >will make its life harder on register based architectures. Forth can >compete with C compilers on older processors with very few registers >(Z80, HC08, etc) where the C is forced to do parameter passing on stack, >like the forth. On the new architectures with lots of registers, there >is virtually no parameter passing on stack anymore, almost all >parameters are passed in registers. This is hard to fit in a forth >compiler. Like in CODE SYSTEM-CALL POP R1 # Extra instruction to move stack items to registers POP R2 # Extra instruction to move stack items to registers POP R3 # Extra instruction to move stack items to registers INT 0x80 push R1 # Extra instruction to move stack items to registers ... ENDCODE That must be one of the hardest nuts to crack in software engineering ;-) What the heck, let's drop in some real code (for Hugh) from a typical register machine the DEC Alpha. (Sorry to go over the 72 char limit.) 7405 81bd 000000 .ascii "LINOS" 7406 81c0 00000000 .align 3 7406 00000000 7407 81c8 00000000 LINOS: .quad .+(CW*(PH_OFFSET-C_HOFFSET)) 7407 00000000 7408 81d0 00000000 .quad .+(CW*(PH_OFFSET-D_HOFFSET)) 7408 00000000 7409 81d8 00000000 .quad 0 7409 00000000 7410 81e0 00000000 .quad ARROW-(CW*(C_HOFFSET)) 7410 00000000 7411 .quad N_LINOS 7412 X_LINOS: 7413 81e8 00001DA4 7414 81ec 08005DA6 LDQ $0, (CW*(0))($29) # Function number 7415 81f0 10003DA6 LDQ $18, (CW*(1))($29) # Third parameter, if any 7416 81f4 18001DA6 LDQ $17, (CW*(2))($29) # Second parameter, if any 7417 81f8 1D14A443 LDQ $16, (CW*(3))($29) # First parameter. 7418 81fc 83000000 ADDQ $29, (CW*(4)), $29 7419 8200 2105E043 CALLSYS # Generic call on LINUX 7420 8204 C0046146 SUBQ $31,$0, $1 #Negated: the error number. 7421 8208 3D15A143 CMOVNE $19, $1, $0 #If $19 set: error. 7422 820c 00001DB4 SUBQ $29, CW, $29 7423 8210 00001EA4 STQ $0, 0($29) 7424 8214 1E14C143 LDQ $0, 0($30) 7425 8218 000020A4 ADDQ $30, CW, $30 7426 821c 0000E16B LDQ $1, 0($0) 7427 JMP $31, ($1), 0 # Positive means okay. Negative means -errno. 7428 # I can't make it look harder than that. From then on we can use the stack for parameters: : bye 0 0 0 1 LINOS ; Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-11-23 17:26 +0000 |
| Message-ID | <547215cd.17103824@news.eternal-september.org> |
| In reply to | #34474 |
On Mon, 17 Nov 2014 23:31:57 -0800 (PST), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >Well, forth may be just a language, but it has an explicit stack which will= > make its life harder on register based architectures. Forth can compete wi= >th C compilers on older processors with very few registers (Z80, HC08, etc)= > where the C is forced to do parameter passing on stack, like the forth. On= > the new architectures with lots of registers, there is virtually no parame= >ter passing on stack anymore, almost all parameters are passed in registers There are two separate issues here 1) Compiling stack code for register machines 2) Binary ABIs Having done VFX code generators for at least six CPU architectures, MPE feels that code quality for compiling Forth to register machines is just a matter of the the time, effort and money you are prepared to spend. Parameter passing and the "best" canonical stack format is a matter of preference within a Forth, but the numbers seem to suggest that one register cached is probably best, although some people claim two on some architectures. For parameter passing to routines to shared libraries, there is no reason why the Forth and the external calls have to use the same format. >. This is hard to fit in a forth compiler. All that a forth compiler can do= > is to optimize the local body of a function to use registers as much as po= >ssible, and the resulting code will hardly look like the original source. And your point is? I have read far too many C disassemblies ... >Everything in C have names, parameters, local variables. In = >forth parameters are hidden, even some locals are hidden because of the use= > of stack instead of local variables. This is a big minus for forth, at lea= >st regarding big projects. It is true that Forth requires discipline for large projects. I'm involved in maintaining a Forth application that now exceeds 1,100,000 lines of Forth source code. With discipline and appropriate tools, such an app can be maintained and developed by a surprisingly small team. The key here is management. I have read far too much C code to believe that maintaining a large C application is easier. 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-11-18 03:34 -0800 |
| Message-ID | <46bdb5f7-78bb-44d0-82fd-996c0e4ea3e0@googlegroups.com> |
| In reply to | #34473 |
On Tuesday, 18 November 2014 04:21:34 UTC, rickman wrote: > I'm curious, why do you think this processor might *not* implement Forth > efficiently? In reality Forth is just a language and can be implemented > as efficiently as any other language on a given machine. It just > requires a well written compiler. > Indeed. I was thinking the same thing. I can imagine that in some instances, a "regular" register-based CPU might actually be a better fit. For example, take the SWAP instruction. On a pure stack-based CPU the SWAP instruction *has* to execute, taking at least one cycle. On a register-based CPU, if the top few stack items are held in registers then SWAP can be optimised out completely by the compiler, therefore SWAP takes 0 cycles. A counter argument to this is that SWAP on a stack-based CPU could possibly executed in parallel with another instruction, reducing its effective cycle time. I don't think it's a black-and-white argument... I'm sure there are arguments either way, but a regular register-based CPU seems like a good fit for any Forth system IMO, with the exception of the register-starved chips from the 70's such as the 6502 etc! Modern CPUs that have lots of registers would probably take some beating.
[toc] | [prev] | [next] | [standalone]
| From | m.a.m.hendrix@tue.nl |
|---|---|
| Date | 2014-11-18 04:19 -0800 |
| Message-ID | <4714eeae-b812-4744-8a04-d891966af114@googlegroups.com> |
| In reply to | #34482 |
On Tuesday, November 18, 2014 12:34:55 PM UTC+1, Mark Wills wrote: [..] > For example, take the SWAP instruction. On a pure stack-based CPU > the SWAP instruction *has* to execute, taking at least one cycle. > On a register-based CPU, if the top few stack items are held in registers > then SWAP can be optimised out completely by the compiler, therefore > SWAP takes 0 cycles. Not necessarily, "SWAP SWAP" would be zero instructions on both types. If a stack CPU has only standard Forth instructions, it can only optimize by rewriting the program to another standard Forth one that is more efficient (if it isn't optimal already). If the underlying Forth has non-standard extensions (like ": swap- swap - ;") it could additionally optimize using these non-standard instructions. > A counter argument to this is that SWAP on a stack-based CPU could > possibly executed in parallel with another instruction, reducing > its effective cycle time. But a register-based machine could use the same hardware resources to execute two USEFUL instructions in parallel. The key is that some Forth instructions do no useful work (like SWAP ROT OVER DUP ..) and that they therefore can be optimized away, given "certain hardware extensions." The question is of course what these "certain extensions" should be. A register machine can only be less efficient than a stack engine when the code really needs two stacks AND when emulating two stacks is slower than having them in hardware. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-23 13:50 +0000 |
| Message-ID | <2014Nov23.145052@mips.complang.tuwien.ac.at> |
| In reply to | #34483 |
m.a.m.hendrix@tue.nl writes:
>A register machine
>can only be less efficient than a stack engine when the code
>really needs two stacks AND when emulating two stacks is slower than
>having them in hardware.
In Forth code the stack depth is typically statically determinable,
and therefore stack items can be mapped to registers (if there are
enough, or a common stack if there are not).
Concerning the efficiency of register machines, stack CPUs like the
b16 need less area than competing register machines. If you go for
bigger designs, 4stack can do 4 operations per cycle, but it's a lot
of work to get from ordinary Forth code to efficient 4-stack code (not
really easier than for an Algol-like language).
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-11-21 15:42 -0800 |
| Message-ID | <04d15f26-4259-41cf-9c48-cc3aab76f242@googlegroups.com> |
| In reply to | #34459 |
On Monday, November 17, 2014 5:26:05 AM UTC-5, JUERGEN wrote: > Is anybody here involved in their project, to make them aware of requirements to run Forth efficiently? > http://www.lowrisc.org/ It looks like the Open Core approach is outdated before it begins, because the trend is reconfigurability in Computer Systems Design: The ability to dynamically reconfigure hardware has powerful possibilities. Reconfigurability can be implemented in various ways as well as with field programmable gate arrays (FPGA) and coarse-grained reconfigurable arrays (CGRA). Source: http://www.computer.org/portal/web/computingnow/archive/november2014 That means, future reconfigurable hardware using FPGAs may give a chance for Forth again. In this article it says it's a concept that is difficult to implement, but with Forth it should be feasable. Power issues in modern processor design have become overwhelming and various efforts have been made to reduce the total power consumption of the chip. The well-known "dark silicon" problem points to the serious issue of power consumption of the chip due to both leakage and dynamic power. Another chance for Chuck's technology!
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.forth
csiph-web