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 | 20 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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-24 14:06 +0000 |
| Message-ID | <2014Nov24.150624@mips.complang.tuwien.ac.at> |
| In reply to | #34602 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>Thankfully, AArch64 mostly gets this stuff right.
>>
>> Aren't you under NDA or something? This architecture still is not
>> publically available, so you probably are not allowed to talk about
>> it. In any case, I will not comment on claims that cannot be veryfied
>> by me.
>
>There's a GCC released for it. And there's an ISA reference manual,
>published from ARM:
>
>https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf
Element14 is not ARM. This looks like a bootleg (or mistakenly posted
document) to me. And in any case, it's an instruction set overview
from 2011, not the architecture reference manual.
>You can buy an iPhone, iPad or Nexus 9 with that architecture;
Sure, and I can buy a graphics card with an Nvidia GPU, too. That does
not mean that its programming documentation has been published.
>ARM64 is really a well thought through ISA.
As mentioned, I don't comment on claims that I cannot verify.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-11-24 16:38 +0000 |
| Message-ID | <m4vmtc$uso$1@dont-email.me> |
| In reply to | #34603 |
on 24/11/2014 14:06:25, wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>>>Thankfully, AArch64 mostly gets this stuff right. >>> >>> Aren't you under NDA or something? This architecture still is not >>> publically available, so you probably are not allowed to talk about >>> it. In any case, I will not comment on claims that cannot be veryfied >>> by me. >> >>There's a GCC released for it. And there's an ISA reference manual, >>published from ARM: >> >>https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf > > Element14 is not ARM. This looks like a bootleg (or mistakenly posted > document) to me. And in any case, it's an instruction set overview > from 2011, not the architecture reference manual. > >>You can buy an iPhone, iPad or Nexus 9 with that architecture; > > Sure, and I can buy a graphics card with an Nvidia GPU, too. That does > not mean that its programming documentation has been published. > >>ARM64 is really a well thought through ISA. > > As mentioned, I don't comment on claims that I cannot verify. > > - anton The document is not confidential. It says so on (numbered) page 2.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-24 09:04 -0600 |
| Message-ID | <EJSdnVqe4tJ31e7JnZ2dnUU7-dWdnZ2d@supernews.com> |
| In reply to | #34601 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Here is some data from an old posting:
>>>
>>> |Here's some data on code size of Gforth-0.5.0 on various systems
>>> |("text" size reported by size; for HP/UX text size-$LIT$ size):
>>> |
>>> | engine-fast.o main-fast.o gcc version
>>> |386 Linux libc5 21184 6523 2.95.1
>>> |386 Linux libc6 21441 8764 2.7.2.3
>>> |386 Linux libc6.1 16744 9214 2.95.2 --enable-force-reg
>>> |SPARC SunOS4 18976 7640 2.5.8
>>> |SPARC Solaris 20560 9446 2.8.1
>>> |MIPS Ultrix 19552 5088 2.4.5
>>> |MIPS Irix6.2 25124 8652 2.95
>>> |Alpha DU 24464 9568 2.95.1
>>> |Alpha Linux 22624 11968 egcs-1.0.3
>>> |HPPA HP/UX 14952 8048 2.95.2
>>> |PowerPC Linux 19168 10204 2.95.2
>>>
>>> Note that for main-fast.o MIPS Ultrix has the smalles text (i.e.,
>>> code) size. So the instruction set obviously does not prevent dense
>>> code.
>>
>>I don't think this follows at all. You'd have to get some much
>>clearer information to determine such a thing. In order to determine
>>the effect of ISA on code size you have to eliminate the compiler as
>>one of the variables, and that is very hard to do.
>
> If code size is as important as you claim,
Which claim was that? I don't remember saying how important it was.
> Interestingly, the architectural features the authors look into do not
> include differences in available addressing modes. Apparently the
> authors did not think that this difference is important.
Perhaps not.
>>>>I'm rather surprised to see anyone doing it in 2014.
>>>
>>> The MIPS people are doing it in 2014 as well.
>>
>>By "it" I meant "designing a new architcecture with this feature".
>
> Every time they design a new MIPS processor (and they released some in
> 2014), they have the opportunity to add new new addressing modes.
Maybe, but there's a lot of inertia in an ISA like the MIPS. There's
tooling, documentation, implementations, and so on. It's not like a
clean-sheet design.
> There is not as much difference between "new" and "old"
> architectures as you seem to believe.
Eh? What do you think I believe? That there isn't much difference
between this "new" design and the early RISCs is obvious from looking
at the spec.
> The MIPS people have not done so yet, and neither have the RISC-V
> people.
Indeed they haven't.
>>Thankfully, AArch64 mostly gets this stuff right.
>
> Aren't you under NDA or something? This architecture still is not
> publically available, so you probably are not allowed to talk about
> it.
The full Architectural Reference Manual isn't public (and probably
never will be) but there's plenty of information available on the net.
You really are making an awful lot of fuss because I said that indexed
addressing would be a nice thing for an ISA to have.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-24 16:16 +0000 |
| Message-ID | <2014Nov24.171609@mips.complang.tuwien.ac.at> |
| In reply to | #34604 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Here is some data from an old posting:
>>>>
>>>> |Here's some data on code size of Gforth-0.5.0 on various systems
>>>> |("text" size reported by size; for HP/UX text size-$LIT$ size):
>>>> |
>>>> | engine-fast.o main-fast.o gcc version
>>>> |386 Linux libc5 21184 6523 2.95.1
>>>> |386 Linux libc6 21441 8764 2.7.2.3
>>>> |386 Linux libc6.1 16744 9214 2.95.2 --enable-force-reg
>>>> |SPARC SunOS4 18976 7640 2.5.8
>>>> |SPARC Solaris 20560 9446 2.8.1
>>>> |MIPS Ultrix 19552 5088 2.4.5
>>>> |MIPS Irix6.2 25124 8652 2.95
>>>> |Alpha DU 24464 9568 2.95.1
>>>> |Alpha Linux 22624 11968 egcs-1.0.3
>>>> |HPPA HP/UX 14952 8048 2.95.2
>>>> |PowerPC Linux 19168 10204 2.95.2
>>>>
>>>> Note that for main-fast.o MIPS Ultrix has the smalles text (i.e.,
>>>> code) size. So the instruction set obviously does not prevent dense
>>>> code.
>>>
>>>I don't think this follows at all. You'd have to get some much
>>>clearer information to determine such a thing. In order to determine
>>>the effect of ISA on code size you have to eliminate the compiler as
>>>one of the variables, and that is very hard to do.
>>
>> If code size is as important as you claim,
>
>Which claim was that?
|I suppose you could argue that the instruction count doesn't matter as
|long as you have superscalar execution and register renaming, but code
|density suffers along with the icache hit rate.
That was the only support you made for your claim:
|I don't like the load and store instructions, which seem to be missing
|some addressing modes you need to generate decent code
> I don't remember saying how important it was.
According to your claims so important that code with only the
reg+constant addressing mode is not deemed decent by you.
>> Every time they design a new MIPS processor (and they released some in
>> 2014), they have the opportunity to add new new addressing modes.
>
>Maybe, but there's a lot of inertia in an ISA like the MIPS. There's
>tooling, documentation, implementations, and so on. It's not like a
>clean-sheet design.
For a clean-sheet design, there is even more tooling, documentation,
implementation and "and so on" to do. Anyway, if the change is what
"you need to generate decent code", then one will overcome the
inertia.
>The full Architectural Reference Manual isn't public (and probably
>never will be)
In that case that architecture has zero interest to me.
>You really are making an awful lot of fuss because I said that indexed
>addressing would be a nice thing for an ISA to have.
You did not say so, but it's nice to know what addressing mode you
are missing.
Makes me wonder if RISC-V has something like the Alpha s4add and s8add
instructions for index computations.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-24 12:57 -0600 |
| Message-ID | <I7-dnWbs1-oe4u7JnZ2dnUU7-QGdnZ2d@supernews.com> |
| In reply to | #34606 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Here is some data from an old posting:
>>>>>
>>>>> |Here's some data on code size of Gforth-0.5.0 on various systems
>>>>> |("text" size reported by size; for HP/UX text size-$LIT$ size):
>>>>> |
>>>>> | engine-fast.o main-fast.o gcc version
>>>>> |386 Linux libc5 21184 6523 2.95.1
>>>>> |386 Linux libc6 21441 8764 2.7.2.3
>>>>> |386 Linux libc6.1 16744 9214 2.95.2 --enable-force-reg
>>>>> |SPARC SunOS4 18976 7640 2.5.8
>>>>> |SPARC Solaris 20560 9446 2.8.1
>>>>> |MIPS Ultrix 19552 5088 2.4.5
>>>>> |MIPS Irix6.2 25124 8652 2.95
>>>>> |Alpha DU 24464 9568 2.95.1
>>>>> |Alpha Linux 22624 11968 egcs-1.0.3
>>>>> |HPPA HP/UX 14952 8048 2.95.2
>>>>> |PowerPC Linux 19168 10204 2.95.2
>>>>>
>>>>> Note that for main-fast.o MIPS Ultrix has the smalles text (i.e.,
>>>>> code) size. So the instruction set obviously does not prevent dense
>>>>> code.
>>>>
>>>>I don't think this follows at all. You'd have to get some much
>>>>clearer information to determine such a thing. In order to determine
>>>>the effect of ISA on code size you have to eliminate the compiler as
>>>>one of the variables, and that is very hard to do.
>>>
>>> If code size is as important as you claim,
>>
>>Which claim was that?
>
> |I suppose you could argue that the instruction count doesn't matter as
> |long as you have superscalar execution and register renaming, but code
> |density suffers along with the icache hit rate.
>
> That was the only support you made for your claim:
>
> |I don't like the load and store instructions, which seem to be
> |missing some addressing modes you need to generate decent code
That sounds reasonable. Generating decent code for array addressing
is not easy without indexed addressing, for example. Sure, you can do
something like
add rtmp, r1, r2, shl #3
ldr r0, [rtmp]
but it needs a scratch register and costs an instruction. This can to
some extent be worked around by loop optimizations if you happen to
have a loop that nicely optimizes.
>> I don't remember saying how important it was.
>
> According to your claims so important that code with only the
> reg+constant addressing mode is not deemed decent by you.
Perhaps "decent" was to strong a word, but I'm not sure it was.
Historically, RISC was based on the premise that compilers were so
good that the semantic gap between high level languages and machines
didn't matter, and that the CPU could be so blazingly fast that it
didn't matter if you had to execute more instructions. (And nobody
has to read or write assembly code any more because compilers are
perfect.) I don't entirely believe that: optimizers can work around
ISA deficiencies and often do a good job of it, but it's never going
to be ideal. It's easier now make more transistors available, and IMO
using them to map well onto the languages which people actually write
is an excellent idea.
> For a clean-sheet design, there is even more tooling, documentation,
> implementation and "and so on" to do.
Well, yes, so you have to do it anyway.
> Anyway, if the change is what "you need to generate decent code",
> then one will overcome the inertia.
Not at all: we still have the qwerty keyboard. And x86.
>>The full Architectural Reference Manual isn't public (and probably
>>never will be)
>
> In that case that architecture has zero interest to me.
The rest of us will talk about it amongst ourselves, then.
>>You really are making an awful lot of fuss because I said that indexed
>>addressing would be a nice thing for an ISA to have.
>
> You did not say so, but it's nice to know what addressing mode you
> are missing.
Hmmm, so I didn't. x86 is even better in that it has
base + (shifted) index + offset, which is great for Java's arrays,
which are a descriptor followed by the data.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-25 16:18 +0000 |
| Message-ID | <2014Nov25.171821@mips.complang.tuwien.ac.at> |
| In reply to | #34609 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>That sounds reasonable. Generating decent code for array addressing
>is not easy without indexed addressing, for example. Sure, you can do
>something like
>
> add rtmp, r1, r2, shl #3
> ldr r0, [rtmp]
>
>but it needs a scratch register and costs an instruction. This can to
>some extent be worked around by loop optimizations if you happen to
>have a loop that nicely optimizes.
In a language like Forth and C, you actually don't need such loop
optimizations, because the programmer can write the stuff directly.
Yes, in some cases the indexed addressing mode saves an instruction
(not a register; you could have used r0 for rtmp). The question is:
how often?
>Historically, RISC was based on the premise that compilers were so
>good that the semantic gap between high level languages and machines
>didn't matter, and that the CPU could be so blazingly fast that it
>didn't matter if you had to execute more instructions. (And nobody
>has to read or write assembly code any more because compilers are
>perfect.) I don't entirely believe that: optimizers can work around
>ISA deficiencies and often do a good job of it, but it's never going
>to be ideal. It's easier now make more transistors available, and IMO
>using them to map well onto the languages which people actually write
>is an excellent idea.
Thinking again about the goals of the RISC-V, it seems to me that they
did not go for the "more transistors available". It is intended to be
used not just as a standalone CPU, but also as a microcontroller in a
SoC (like, say, the 8051, b16, or ARM), and there it's still good to
minimize the number of transistors. They not only left your favourite
addressing mode away, but many features that, e.g., the Alpha has had
at its inception in 1992.
>> Anyway, if the change is what "you need to generate decent code",
>> then one will overcome the inertia.
>
>Not at all: we still have the qwerty keyboard. And x86.
"x86" is a very good case in point. It grows new instruction set
extensions with every designed chip. A relatively recent Intel chip
gives me the following feature flags:
|fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
|pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
|rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
|tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor
|ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic
|popcnt aes xsave avx lahf_lm ida arat tpr_shadow vnmi flexpriority ept
|vpid
Simularly, Alpha added BWX, MVI, FIX, and CIX during its relatively
short life. But one thing they did not add was more addressing modes.
>>>You really are making an awful lot of fuss because I said that indexed
>>>addressing would be a nice thing for an ISA to have.
>>
>> You did not say so, but it's nice to know what addressing mode you
>> are missing.
>
>Hmmm, so I didn't. x86 is even better in that it has
>base + (shifted) index + offset, which is great for Java's arrays,
>which are a descriptor followed by the data.
Hmm, if you need that, Alpha needs two instructions, and ARM needs two
instructions, too; and I think many AMD64 implementations need an
additional cycle for address computation (but I have not read the
optimization manuals recently, they may have changed that).
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-25 14:40 -0500 |
| Message-ID | <m52m06$2f8$1@dont-email.me> |
| In reply to | #34635 |
On 11/25/2014 11:18 AM, Anton Ertl wrote: > > Thinking again about the goals of the RISC-V, it seems to me that they > did not go for the "more transistors available". It is intended to be > used not just as a standalone CPU, but also as a microcontroller in a > SoC (like, say, the 8051, b16, or ARM), and there it's still good to > minimize the number of transistors. They not only left your favourite > addressing mode away, but many features that, e.g., the Alpha has had > at its inception in 1992. Interesting that you use the 8051, b16, ARM and the lowRISC all in the same target app. The 8051 and b16 are intended for very different apps than the ARM and lowRISC and have a much different footprint inside a device. They would be very hard to interchange. Best not to muddy the waters with that level of confusion. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-26 00:48 +0100 |
| Message-ID | <m534fo$rd2$1@dont-email.me> |
| In reply to | #34641 |
rickman wrote: > Interesting that you use the 8051, b16, ARM and the lowRISC all in the > same target app. The 8051 and b16 are intended for very different apps > than the ARM and lowRISC and have a much different footprint inside a > device. They would be very hard to interchange. ARM has Cortex M0 as competition to 8051 and b16 (in fact, Dialog never liked my b16, and they always wanted Cortex M0, though of course, the Cortex M0 is considerably larger than the b16, and probably also blows the power budget). -- 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 | 2014-11-25 19:10 -0500 |
| Message-ID | <m535qt$uuj$1@dont-email.me> |
| In reply to | #34644 |
On 11/25/2014 6:48 PM, Bernd Paysan wrote: > rickman wrote: >> Interesting that you use the 8051, b16, ARM and the lowRISC all in the >> same target app. The 8051 and b16 are intended for very different apps >> than the ARM and lowRISC and have a much different footprint inside a >> device. They would be very hard to interchange. > > ARM has Cortex M0 as competition to 8051 and b16 (in fact, Dialog never > liked my b16, and they always wanted Cortex M0, though of course, the Cortex > M0 is considerably larger than the b16, and probably also blows the power > budget). Bingo, hence not competitive. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-26 02:09 +0100 |
| Message-ID | <m53976$930$1@dont-email.me> |
| In reply to | #34645 |
rickman wrote: > On 11/25/2014 6:48 PM, Bernd Paysan wrote: >> rickman wrote: >>> Interesting that you use the 8051, b16, ARM and the lowRISC all in the >>> same target app. The 8051 and b16 are intended for very different apps >>> than the ARM and lowRISC and have a much different footprint inside a >>> device. They would be very hard to interchange. >> >> ARM has Cortex M0 as competition to 8051 and b16 (in fact, Dialog never >> liked my b16, and they always wanted Cortex M0, though of course, the >> Cortex M0 is considerably larger than the b16, and probably also blows >> the power budget). > > Bingo, hence not competitive. It is competitive with some of the "high-speed" 8051. Read "high-speed" as in "snail racing" ;-). From an area point of view, ROM based 12-CPI 8051s are competitive with the b16, but if you have a limited power budget or a more agressive performance target, you better quickly forget about the 8051. A "fast" "1-CPI" 8051 can be 100MHz in 0.25µ if you go for area-optimized synthesis. Of course, many instructions still take more than one cycle; the 1-CPI only goes for the simple instructions that take 12 cycles on the original 8051. I've never done any serious synthesis of the b16 for being speed-optimized, because it already was 250MHz area-optimized at 0.25µ (that's what the 8051 gets when you do speed-optimized synthesis; you get around 500MHz if you do that with the b16). And this "fast" 8051 is an order of magnitude larger on die than the b16. So what I want to say: 8051 and Cortex M0 do compete with each other, and the Cortex M0 is doing sufficiently well - if you need the speed for a "fast" 8051, better go for a Cortex M0. Or if you want to have the size of a slow 8051, and the speed of a Cortex M0, 16 bit is enough for you, code footprint matters, but being able to compile C code doesn't, just take the b16. The tradeoffs are certainly different. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-26 11:22 +0000 |
| Message-ID | <2014Nov26.122237@mips.complang.tuwien.ac.at> |
| In reply to | #34641 |
rickman <gnuarm@gmail.com> writes:
>On 11/25/2014 11:18 AM, Anton Ertl wrote:
>>
>> Thinking again about the goals of the RISC-V, it seems to me that they
>> did not go for the "more transistors available". It is intended to be
>> used not just as a standalone CPU, but also as a microcontroller in a
>> SoC (like, say, the 8051, b16, or ARM), and there it's still good to
>> minimize the number of transistors. They not only left your favourite
>> addressing mode away, but many features that, e.g., the Alpha has had
>> at its inception in 1992.
>
>Interesting that you use the 8051, b16, ARM and the lowRISC all in the
>same target app. The 8051 and b16 are intended for very different apps
>than the ARM and lowRISC and have a much different footprint inside a
>device. They would be very hard to interchange.
Sure, if the b16 is sufficient, you will not use a RISC-V. But why
not? Because more transistors/more area still costs more. And that's
the point I wanted to make. RISC-V has fewer features than ARM, so
there is the potential for needing fewer transistors and less area
than ARM.
And that seems to be a good competetive position. There is lots of
strong competition in larger cores: ARM, MIPS, PowerPC, IA32/AMD64.
There seems to be less competition for smaller cores.
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-26 16:11 -0500 |
| Message-ID | <m55fm8$rqn$1@dont-email.me> |
| In reply to | #34653 |
On 11/26/2014 6:22 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 11/25/2014 11:18 AM, Anton Ertl wrote: >>> >>> Thinking again about the goals of the RISC-V, it seems to me that they >>> did not go for the "more transistors available". It is intended to be >>> used not just as a standalone CPU, but also as a microcontroller in a >>> SoC (like, say, the 8051, b16, or ARM), and there it's still good to >>> minimize the number of transistors. They not only left your favourite >>> addressing mode away, but many features that, e.g., the Alpha has had >>> at its inception in 1992. >> >> Interesting that you use the 8051, b16, ARM and the lowRISC all in the >> same target app. The 8051 and b16 are intended for very different apps >> than the ARM and lowRISC and have a much different footprint inside a >> device. They would be very hard to interchange. > > Sure, if the b16 is sufficient, you will not use a RISC-V. But why > not? Because more transistors/more area still costs more. And that's > the point I wanted to make. RISC-V has fewer features than ARM, so > there is the potential for needing fewer transistors and less area > than ARM. > > And that seems to be a good competetive position. There is lots of > strong competition in larger cores: ARM, MIPS, PowerPC, IA32/AMD64. > There seems to be less competition for smaller cores. I can't say how many transistors it takes to implement any of these processors. But I am pretty sure the lowRISC processor will be much more in the ballpark of the ARM, etc. than the b16. Those are very separate markets with very different requirements. That is all I'm saying. One problem with discussing the size of the ARM processor is that it has very different sizes depending on the model processor you use. As Bernd points out the CM0 is a very small processor indeed. The ARM used in the Xilinx Zynq is a very different animal. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-25 16:57 -0800 |
| Message-ID | <7xvbm2aidv.fsf@ruckus.brouhaha.com> |
| In reply to | #34635 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > It is intended to be used not just as a standalone CPU, but also as a > microcontroller in a SoC (like, say, the 8051, b16, or ARM), and there > it's still good to minimize the number of transistors. Certainly there are very large SoC's around, like the multicore ARM A-series processors in smart phones. The 64-bit RiscV may have SoC applications in mind, but I don't think it's intended to compete in the same space as the 8051.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-26 03:51 -0600 |
| Message-ID | <VKmdnbLbTqcjP-jJnZ2dnUVZ8oidnZ2d@supernews.com> |
| In reply to | #34635 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>That sounds reasonable. Generating decent code for array addressing >>is not easy without indexed addressing, for example. Sure, you can do >>something like >> >> add rtmp, r1, r2, shl #3 >> ldr r0, [rtmp] >> >>but it needs a scratch register and costs an instruction. This can to >>some extent be worked around by loop optimizations if you happen to >>have a loop that nicely optimizes. > > In a language like Forth and C, you actually don't need such loop > optimizations, because the programmer can write the stuff directly. Well, yes, and you can write everything in assembly code if you like. But abstraction is useful. > Yes, in some cases the indexed addressing mode saves an instruction > (not a register; you could have used r0 for rtmp). Maybe, maybe not. It all depends on whether you want that address again. > The question is: how often? Indeed. But from the point of view of someone who has to write compilers, I'd rather have a simple mapping from a high-level language. (All other things being equal, of course, and they rarely are.) > Thinking again about the goals of the RISC-V, it seems to me that they > did not go for the "more transistors available". It is intended to be > used not just as a standalone CPU, but also as a microcontroller in a > SoC (like, say, the 8051, b16, or ARM), and there it's still good to > minimize the number of transistors. They not only left your favourite > addressing mode I have a favourite addressing mode? Gosh. Who knew? > away, but many features that, e.g., the Alpha has had at its > inception in 1992. Indeed, and I wholeheartedly accept that point. However, it's not at all inconsistent for me to say "that's a shame" even while accepting the tradeoff. >>Hmmm, so I didn't. x86 is even better in that it has >>base + (shifted) index + offset, which is great for Java's arrays, >>which are a descriptor followed by the data. > > Hmm, if you need that, Alpha needs two instructions, and ARM needs two > instructions, too; and I think many AMD64 implementations need an > additional cycle for address computation (but I have not read the > optimization manuals recently, they may have changed that). That's right. x86 is unique among the processors I program in this regard, and such a mode would not have been a good fit for ARM. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-27 16:10 +0000 |
| Message-ID | <2014Nov27.171001@mips.complang.tuwien.ac.at> |
| In reply to | #34651 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>That sounds reasonable. Generating decent code for array addressing
>>>is not easy without indexed addressing, for example. Sure, you can do
>>>something like
>>>
>>> add rtmp, r1, r2, shl #3
>>> ldr r0, [rtmp]
>>>
>>>but it needs a scratch register and costs an instruction. This can to
>>>some extent be worked around by loop optimizations if you happen to
>>>have a loop that nicely optimizes.
>>
>> In a language like Forth and C, you actually don't need such loop
>> optimizations, because the programmer can write the stuff directly.
>
>Well, yes, and you can write everything in assembly code if you like.
>But abstraction is useful.
How does that combine with the principles of Chuck Moore that you hold
up so often? For my part, I don't consider array syntax a useful
abstraction compared to expressing the same thing with pointers or
addresses, certainly when I am interested in optimization.
>
>> Yes, in some cases the indexed addressing mode saves an instruction
>> (not a register; you could have used r0 for rtmp).
>
>Maybe, maybe not. It all depends on whether you want that address
>again.
Well, if I want that address again, it saves the computation of the
address the second and following times, which saves energy (whether it
makes up for the energy cost of the extra instruction is questionable,
though). And you need only one instruction the second and following
times.
>Indeed. But from the point of view of someone who has to write
>compilers, I'd rather have a simple mapping from a high-level
>language. (All other things being equal, of course, and they rarely
>are.)
And Alpha, MIPS, and RISC-V provide that. And it seems to me that
this is even more the case if you consider loop optimizations of array
accesses: The compiler does not have to make a decision whether to
strength-reduce the loop-variable-indexed array accesses and eliminate
the loop variable, or not; these optimizations are always profitable.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-27 10:39 -0600 |
| Message-ID | <r9-dnYBHwPM2zurJnZ2dnUU7-SudnZ2d@supernews.com> |
| In reply to | #34670 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>That sounds reasonable. Generating decent code for array addressing >>>>is not easy without indexed addressing, for example. Sure, you can do >>>>something like >>>> >>>> add rtmp, r1, r2, shl #3 >>>> ldr r0, [rtmp] >>>> >>>>but it needs a scratch register and costs an instruction. This can to >>>>some extent be worked around by loop optimizations if you happen to >>>>have a loop that nicely optimizes. >>> >>> In a language like Forth and C, you actually don't need such loop >>> optimizations, because the programmer can write the stuff directly. >> >>Well, yes, and you can write everything in assembly code if you like. >>But abstraction is useful. > > How does that combine with the principles of Chuck Moore that you hold > up so often? I don't know. This question seems like a non sequitur. > For my part, I don't consider array syntax a useful abstraction > compared to expressing the same thing with pointers or addresses, > certainly when I am interested in optimization. Okay, so that's true for you. I like arrays, and have used them in Forth and every other langauge I have ever used. I have nothing against abstraction at all, as long as it's the right abstraction: simple and useful. >>Indeed. But from the point of view of someone who has to write >>compilers, I'd rather have a simple mapping from a high-level >>language. (All other things being equal, of course, and they rarely >>are.) > > And Alpha, MIPS, and RISC-V provide that. And it seems to me that > this is even more the case if you consider loop optimizations of > array accesses: The compiler does not have to make a decision > whether to strength-reduce the loop-variable-indexed array accesses > and eliminate the loop variable, or not; these optimizations are > always profitable. This is one of the most ridulous arguments that I have ever heard. Don't provide facilities that might be useful, because your customer might have to make the decision to use them or not. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-28 15:27 +0000 |
| Message-ID | <2014Nov28.162750@mips.complang.tuwien.ac.at> |
| In reply to | #34671 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Indeed. But from the point of view of someone who has to write
>>>compilers, I'd rather have a simple mapping from a high-level
>>>language. (All other things being equal, of course, and they rarely
>>>are.)
>>
>> And Alpha, MIPS, and RISC-V provide that. And it seems to me that
>> this is even more the case if you consider loop optimizations of
>> array accesses: The compiler does not have to make a decision
>> whether to strength-reduce the loop-variable-indexed array accesses
>> and eliminate the loop variable, or not; these optimizations are
>> always profitable.
>
>This is one of the most ridulous arguments that I have ever heard.
>Don't provide facilities that might be useful, because your customer
>might have to make the decision to use them or not.
You obviously are not an Apple customer.
Anyway, this is not about decisions by the customer, but about writing
compilers. If the compiler has to make a complicated analysis or try
out a lot of variants in order to produce good code, the compiler will
be bigger, has more potential for bugs, and makes a lot of work for
the compiler writer. Sure, the compiler writer can decide to always
strength-reduce and eliminate the loop variable, and use the reg+const
addressing mode, but then, is the additional cost of the indexed
addressing hardware really justified? The MIPS, Alpha, RISC-V,
PowerPC and IIRC SPARC architects decided that it isn't (SPARC and
PowerPC have reg+reg, though).
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-28 10:26 -0600 |
| Message-ID | <n-ednakRyKasP-XJnZ2dnUVZ8l6dnZ2d@supernews.com> |
| In reply to | #34676 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Indeed. But from the point of view of someone who has to write >>>>compilers, I'd rather have a simple mapping from a high-level >>>>language. (All other things being equal, of course, and they rarely >>>>are.) >>> >>> And Alpha, MIPS, and RISC-V provide that. And it seems to me that >>> this is even more the case if you consider loop optimizations of >>> array accesses: The compiler does not have to make a decision >>> whether to strength-reduce the loop-variable-indexed array accesses >>> and eliminate the loop variable, or not; these optimizations are >>> always profitable. >> >>This is one of the most ridulous arguments that I have ever heard. >>Don't provide facilities that might be useful, because your customer >>might have to make the decision to use them or not. > > You obviously are not an Apple customer. Obviously. > Anyway, this is not about decisions by the customer, but about > writing compilers. If the compiler has to make a complicated > analysis or try out a lot of variants in order to produce good code, > the compiler will be bigger, has more potential for bugs, and makes > a lot of work for the compiler writer. That doesn't make the argument any less ridiculous: it's no more than a restatement of it. This instruction is a pattern which corresponds directly to one of the most-used constructs in a high-level programming language, and a compiler can directly generate it with very little effort. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-29 01:03 +0100 |
| Message-ID | <m5b2fl$ke4$1@dont-email.me> |
| In reply to | #34678 |
Andrew Haley wrote: > That doesn't make the argument any less ridiculous: it's no more than > a restatement of it. This instruction is a pattern which corresponds > directly to one of the most-used constructs in a high-level > programming language, and a compiler can directly generate it with > very little effort. There's also the point that the base+offset addressing mode requires an adder, so if you already have an adder in the memory accessing path, you can as well do a reg+reg(+offset) add, and of course, you can also scale one of the inputs by a small shift with little effort. The only thing that makes sense is to drop the adder completely. This can reduce the access time to memory, because you can fetch directly, without adder (though sum-addressed caches can be directly addressed by a sum, too, but this comes at the cost that you now need a customized SRAM compiler, whereas the straight-forward SRAM doesn't require any modificatons). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-29 15:27 +0000 |
| Message-ID | <2014Nov29.162719@mips.complang.tuwien.ac.at> |
| In reply to | #34681 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Andrew Haley wrote:
>There's also the point that the base+offset addressing mode requires an
>adder, so if you already have an adder in the memory accessing path, you can
>as well do a reg+reg(+offset) add, and of course, you can also scale one of
>the inputs by a small shift with little effort.
reg+reg requires an additional register read port for the store
instruction, pretty expensive in particular in a superscalar
implementation. Alternatively, support it only for loads, and have a
different address computation path for loads and stores, also not for
free. Shifting by 0-3 bits, as in Intel indexed addressing modes
introduces additional latency in the address computation; if the cost
was insignificant, PowerPC and SPARC would have it. Reg+reg+const
requires more than a simple adder.
- 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]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web