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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-12-13 22:58 -0800 |
| Message-ID | <7x1to2wwd6.fsf@ruckus.brouhaha.com> |
| In reply to | #34902 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >> downloaded a pile of journal articles to his laptop computer> > He wanted to publish all of them. I don't think that is known. He wrote a blog post years earlier expressing a philosophical viewpoint that such info should be free, but that's a lot different than saying he intended to publish a particular bunch of articles. I think he did release some downloaded articles that were out of copyright, like some about 19th century science experiments. I haven't heard about him releasing any of the copyrighted ones. > IMHO, Swartz was prosecuted that way, because he already had freed the > (actually public, but very expensive to access) documents from PACER Yes, it does look like that. But it also seemed like plain opportunism by the prosecutor.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-12-04 03:38 -0800 |
| Message-ID | <cd3cf50a-7cc0-48f5-ac3a-5a5b3b73cf85@googlegroups.com> |
| In reply to | #34718 |
On Sunday, 30 November 2014 16:40:41 UTC, Bernd Paysan wrote: > The FSF > requies me to jump through a hoop that takes weeks and requires a lot of > patience, and about 99% of that is not necessary. And the FSF has a very > dedicated mission about freedom and stuff like that, to which this > buerocracy is contrary. ARM does not have this sort of mission. That's is because it's essentially a communist collective, organsised and run like some sort of Duma!
[toc] | [prev] | [next] | [standalone]
| From | Horse Shit <puke.aguilar@hughfailure.com> |
|---|---|
| Date | 2014-12-04 13:29 +0000 |
| Message-ID | <m5pnkf$um4$1@speranza.aioe.org> |
| In reply to | #34772 |
On 2014-12-04, Mark Wills <markwills1970@gmail.com> wrote: > On Sunday, 30 November 2014 16:40:41 UTC, Bernd Paysan wrote: >> The FSF >> requies me to jump through a hoop that takes weeks and requires a lot of >> patience, and about 99% of that is not necessary. And the FSF has a very >> dedicated mission about freedom Hahah. Your ass it does. Since when does jamming your worldview up other peoples asses equal freedom? Just call it forcible open source and we can agree not to digress into ad hominem attacks ;-) > and stuff like that Hahah again. Freedom and stuff like that. How apt for someone who has no idea what freedom actually means. > to which this buerocracy is contrary. No, and that is the point. See below. > ARM does not have this sort of mission. Because they have to make money, which they do by making their services easy to get for people who want to pay for them. > That's is because it's essentially a communist collective, organsised and > run like some sort of Duma! This. The FSF is about fucking you and all your boyfriends. It's their way or no way, and you have to like it. They are not about freedom. They are about forcing their world view all over you. These kinds of communists aren't about streamlining anything or making life simple. They have to build their pyramid scheme lined with fanboy dummies and layers and layers of shit, just like the apps they write. It's all about making themselves indispensable and all-powerful. Not because anybody really needs them for anything but because they can get lemmings like Burnt Peasant to believe he does. Puke Aguilar, gay/lesbian rights activist and diplomat -- Will change car air fresheners for sex or donuts
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2014-11-28 05:36 -0800 |
| Message-ID | <75c668da-38bb-443e-8d02-5ca5d6d5490b@googlegroups.com> |
| In reply to | #34667 |
On Thursday, November 27, 2014 3:20:28 PM UTC, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > > >> > >>Google wants everybody to use Android, because that way, they can get their > >>ad-based revenue. That means you have to figure out how to make revenue > >>from everybody using your core. I don't have an idea how to do that, but > >>there are certainly other ways to generate revenue. > > > > I think the same could work for RISC-V. Google could find it > > worthwhile to support it on the software side in order to enable > > cheaper (i.e., more widespread) Android devices. And the hardware > > manufacturer could then design a RISC-V-based phone, because by not > > having to pay the ARM tax they can make cheaper phones and make more > > profits at first or have a bigger market later. > > I doubt it. ARM cores shipped in 2013: 10 billion. ARM revenue in > 2013: UKP 730 million. The ARM tax is not very high. > > Andrew. Andrew as you doubt it you must have the sources - how much was it then?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-28 10:37 -0600 |
| Message-ID | <Y9SdncS62fImOeXJnZ2dnUVZ8hmdnZ2d@supernews.com> |
| In reply to | #34675 |
JUERGEN <epldfpga@aol.com> wrote: > On Thursday, November 27, 2014 3:20:28 PM UTC, Andrew Haley wrote: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> > >> >> >> >>Google wants everybody to use Android, because that way, they can get their >> >>ad-based revenue. That means you have to figure out how to make revenue >> >>from everybody using your core. I don't have an idea how to do that, but >> >>there are certainly other ways to generate revenue. >> > >> > I think the same could work for RISC-V. Google could find it >> > worthwhile to support it on the software side in order to enable >> > cheaper (i.e., more widespread) Android devices. And the hardware >> > manufacturer could then design a RISC-V-based phone, because by not >> > having to pay the ARM tax they can make cheaper phones and make more >> > profits at first or have a bigger market later. >> >> I doubt it. ARM cores shipped in 2013: 10 billion. ARM revenue in >> 2013: UKP 730 million. The ARM tax is not very high. > > Andrew as you doubt it you must have the sources - how much was it > then? I don't understand what you're trying to ask me. You have the numbers for ARM; what more do you want? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-26 01:14 +0100 |
| Message-ID | <m5363n$fn$1@dont-email.me> |
| In reply to | #34634 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>As the document is not marked as "confidential", you are free to extract >>information and distribute that information - as long as you don't violate >>copyright (no verbatim copies beyond the fair use citation limit). There >>is only one restriction: You are not allowed to use the information in the >>document to determine whether ARM violates patents. >> >>I'm perfectly fine with this restriction; this is a sort of "patentleft" - >>use copyright to prevent people from patent lawsuits. > > Given that ARM reportedly aggressively wields patents as a club, I > don't think it's fine if they do this. > > Also, I very much doubt that this can be a successful way to avoid > patent lawsuits. If ARM violates some architecture patent, it > violates it even with that clause. And if somebody wants to go after > ARM (or one of its licencees) for that violation, that clause won't > help; at worst the attacker has to use clean room design on the > manual. I don't think the clause would held up in court... but it's a nice idea ;-). I hope all ARM competitors copy that clause, to fence off ARM patent attacks... > In any case, ARM are below industry standard in their access to > documentation, and we should reward them for this by not supporting > their architecture. I've seen this sort of "you must give us an e-mail address before we let you access the documents" quite frequently; it's not perfect, but it's not *that* awful (all you need is a throw-away e-mail address). It is not under NDA (that would be a no-go), and even Intel copyrights their manuals - and if you compare ARM64 to Itanic, Itanic certainly was much worse; it was under a heavy NDA. Of course, only a copylefted manual is fully acceptable. > OTOH, the RISC-V stuff is much more along the > lines of the open source hardware that you propagated a few months > ago. I hope they win out over ARM, but that will take at least a > decade. There clearly is a dedicated niche for open cores, and especially in the Cortex M0 range, they do compete with ARM. I do promote it where possible. I'm not sure if this RISC-V stuff is going to be competitive in the 64 bit world, but I strongly suggest that they should look at ARM64, be inspired by what's useful, and improve what can be improved. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-23 20:57 -0800 |
| Message-ID | <7xwq6lp55v.fsf@ruckus.brouhaha.com> |
| In reply to | #34576 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > one difference from MIPS is that the MIPS ADD/ADDI > instruction (trap on overflow) is not present A pity. See: http://blog.regehr.org/archives/1154
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-24 03:59 -0600 |
| Message-ID | <CdGdnTGsBuIYnO7JnZ2dnUU7-TednZ2d@supernews.com> |
| In reply to | #34593 |
Paul Rubin <no.email@nospam.invalid> wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> one difference from MIPS is that the MIPS ADD/ADDI >> instruction (trap on overflow) is not present > > A pity. See: http://blog.regehr.org/archives/1154 "My belief is that hardware traps could change this inequation in a favorable way." But such traps are not cheap, much less free: you'd have to have precise traps for addition, and this is going to cost on an out-of-order architecture. If you want to push a high level language feature this is the wrong way to go about it. Bah. Everybody has their favourite feature they want in a processor. I certainly have mine. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-24 02:14 -0800 |
| Message-ID | <7xy4r0dhx6.fsf@ruckus.brouhaha.com> |
| In reply to | #34595 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > But such traps are not cheap, much less free: you'd have to have > precise traps for addition, and this is going to cost on an > out-of-order architecture. 1. Does that penalty still happen when the trap doesn't occur? It's trapping an error condition after all, so it should be rare. When the trap doesn't happen, I don't see how it's worse than setting condition codes after arithmetic operations, which the x86 already does. 2. I don't see why it has to be a precise trap. It's enough to crash the program because there is a bug. What happens now with floating point traps? They were imprecise on some of the old machines, and people dealt with it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-24 06:09 -0600 |
| Message-ID | <p_idnXHp_ZBzgu7JnZ2dnUU7-U2dnZ2d@supernews.com> |
| In reply to | #34596 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> But such traps are not cheap, much less free: you'd have to have >> precise traps for addition, and this is going to cost on an >> out-of-order architecture. > > 1. Does that penalty still happen when the trap doesn't occur? I think it can be done in parallel with the addition, at some cost in size. But the OOO logic would have to be more complex, of course. > It's trapping an error condition after all, so it should be rare. > When the trap doesn't happen, I don't see how it's worse than > setting condition codes after arithmetic operations, which the x86 > already does. But it's already a lot of work to cope with a single condition code register in an OOO processor while keeping things straight; this is yet more work. > 2. I don't see why it has to be a precise trap. It's enough to crash > the program because there is a bug. Err, no. You have to trap in a reasonable way and continue. See Ariane 5, passim. > What happens now with floating point traps? They were imprecise on > some of the old machines, and people dealt with it. And it sucked. There's no reasonable way to handle such an imprecise trap in a high-level language. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-24 11:04 -0800 |
| Message-ID | <7xk32ka08d.fsf@ruckus.brouhaha.com> |
| In reply to | #34599 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> 2. I don't see why it has to be a precise trap. It's enough to crash >> the program because there is a bug. > Err, no. You have to trap in a reasonable way and continue. See > Ariane 5, passim. Meh, forcing a context switch and handing some carcass off to another process would be better than what we do now, which is tolerate overflow errors silently. We know from Erlang that you can write reliable systems that way. >> What happens now with floating point traps? They were imprecise on >> some of the old machines, and people dealt with it. > > And it sucked. There's no reasonable way to handle such an imprecise > trap in a high-level language. So what happens now if you divide by zero?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-11-24 11:49 -1000 |
| Message-ID | <rcKdnZ8yGLRIOu7JnZ2dnUU7-eudnZ2d@supernews.com> |
| In reply to | #34610 |
On 11/24/14 9:04 AM, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> 2. I don't see why it has to be a precise trap. It's enough to crash >>> the program because there is a bug. >> Err, no. You have to trap in a reasonable way and continue. See >> Ariane 5, passim. > > Meh, forcing a context switch and handing some carcass off to another > process would be better than what we do now, which is tolerate overflow > errors silently. We know from Erlang that you can write reliable > systems that way. > >>> What happens now with floating point traps? They were imprecise on >>> some of the old machines, and people dealt with it. >> >> And it sucked. There's no reasonable way to handle such an imprecise >> trap in a high-level language. > > So what happens now if you divide by zero? If your application is dividing numbers that might be zero you check at the point where the bad numbers enter the system and handle the situation appropriately. If the potentially bad numbers are coming in from user input, for example, the place to check is at the user interface, ensuring that users enter only valid values. Error checking is always most effective at the point where data enters the system, not buried deep in (e.g.) divide routines where it slows the system down without being able to respond intelligently. 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-24 13:57 -0800 |
| Message-ID | <7xegssi7mq.fsf@ruckus.brouhaha.com> |
| In reply to | #34611 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> So what happens now if you divide by zero? > If your application is dividing numbers that might be zero you check > at the point where the bad numbers enter the system Thanks, but this question was about how x86 hardware arithmetic trap works if the cpu encounters a divide by zero, or (come to think of it) various floating point conditions that are supposed to raise signals. The implied followup question is why the hardware can't trap regular integer overflow the same way.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-11-24 12:28 -1000 |
| Message-ID | <PZydnTJDT6-DLO7JnZ2dnUU7-fOdnZ2d@supernews.com> |
| In reply to | #34612 |
On 11/24/14 11:57 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> So what happens now if you divide by zero? >> If your application is dividing numbers that might be zero you check >> at the point where the bad numbers enter the system > > Thanks, but this question was about how x86 hardware arithmetic trap > works if the cpu encounters a divide by zero, or (come to think of it) > various floating point conditions that are supposed to raise signals. > The implied followup question is why the hardware can't trap regular > integer overflow the same way. Yes, I know. My point is that I would prefer it not to trap, because there's nothing really useful you can do at that point. Better to design your application so that's not relevant. 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-24 14:50 -0800 |
| Message-ID | <7xbnnwxlf1.fsf@ruckus.brouhaha.com> |
| In reply to | #34614 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Yes, I know. My point is that I would prefer it not to trap, because > there's nothing really useful you can do at that point. Better to > design your application so that's not relevant. In the real world we find that integer overflow is a perennial source of bugs in programs, and that trapping overflow in software is expensive enough that people usually don't compile code that way. Regehr argues that the right solution is for cpus to include hardware traps for integer overflow. Andrew and some others say that this would impact performance or otherwise add significant cost. I'm trying to understand the reason for that, since cpus already include multiple arithmetic traps such as zero-divide and various FPU signalling conditions. Outside of the embedded, real-time or performance critical niches, I start to think that most programs should use bignums as their default integer type. This happens in Lisp, Python, and Erlang, and half-assedly in Haskell. Not sure about Ruby or Clojure or the other trendy languages of the week.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-11-24 13:22 -1000 |
| Message-ID | <06udnVt3WPowIO7JnZ2dnUU7-WudnZ2d@supernews.com> |
| In reply to | #34615 |
On 11/24/14 12:50 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Yes, I know. My point is that I would prefer it not to trap, because >> there's nothing really useful you can do at that point. Better to >> design your application so that's not relevant. > > In the real world we find that integer overflow is a perennial source of > bugs in programs, and that trapping overflow in software is expensive > enough that people usually don't compile code that way. Regehr argues > that the right solution is for cpus to include hardware traps for > integer overflow. Andrew and some others say that this would impact > performance or otherwise add significant cost. I'm trying to understand > the reason for that, since cpus already include multiple arithmetic > traps such as zero-divide and various FPU signalling conditions. I guess I don't care if it's there in the hardware, I just wouldn't enable that feature. It's doing software checks low down in the divide routines that destroy performance, and they're no more helpful there than in the hardware. Consider: suppose you have several thousand instances of division scattered through your code, which is an embedded device with no operator. A trap occurs. Exactly what response would be useful? In most cases, all you can do is reset the whole application, which might be either extremely annoying or catastrophic, depending on what it's doing. A properly-designed application would check data as it enters the system against reasonable values, and if the check fails take appropriate action depending on the particular situation (retry, ring bell, light lamp, ... ). If all the appropriate checks are in place, there will be no overflows or divide checks. > Outside of the embedded, real-time or performance critical niches, I > start to think that most programs should use bignums as their default > integer type. This happens in Lisp, Python, and Erlang, and > half-assedly in Haskell. Not sure about Ruby or Clojure or the other > trendy languages of the week. That is certainly costly in performance, and the same program design issues apply, except instead of halting the device you issue an error message to a human who hasn't a clue what to do. However, if the message says the value you just typed has to be within these limits, the user knows exactly what to do. 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-24 16:15 -0800 |
| Message-ID | <7xfvd8m8yn.fsf@ruckus.brouhaha.com> |
| In reply to | #34616 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Consider: suppose you have several thousand instances of division > scattered through your code, which is an embedded device with no > operator. A trap occurs. Exactly what response would be useful? I realize we're somewhat coming from different worlds but I'd say in a critical embedded system, you have to go to great lengths during software development to make sure these errors never occur. In principle every system should be developed like that, but in practice the costs are intolerable. In a desktop application like a compiler, generating wrong code is intolerable but crashing is merely annoying. If some phase of the SwiftForth optimizer has an overflow bug on a particular weird input, it's much better to crash the compiler (so the user finds a workaround, or opens a support incident and gets a patch, or even switches to another compiler) than to quietly generate incorrect code. So here, a hardware overflow trap can be a valuable safety check.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-11-24 14:38 -1000 |
| Message-ID | <s56dnSgCkO8HUu7JnZ2dnUU7-S-dnZ2d@supernews.com> |
| In reply to | #34617 |
On 11/24/14 2:15 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Consider: suppose you have several thousand instances of division >> scattered through your code, which is an embedded device with no >> operator. A trap occurs. Exactly what response would be useful? > > I realize we're somewhat coming from different worlds but I'd say in a > critical embedded system, you have to go to great lengths during > software development to make sure these errors never occur. In > principle every system should be developed like that, but in practice > the costs are intolerable. Not so intolerable. Every input is associated with some kind of device for which a driver is being written, and one of the things the driver has to do is ensure the input is valid or generate some kind of alarm. > In a desktop application like a compiler, generating wrong code is > intolerable but crashing is merely annoying. If some phase of the > SwiftForth optimizer has an overflow bug on a particular weird input, > it's much better to crash the compiler (so the user finds a workaround, > or opens a support incident and gets a patch, or even switches to > another compiler) than to quietly generate incorrect code. So here, a > hardware overflow trap can be a valuable safety check. Sure, finding errors during debugging is important, and I agree that in general crashes are useful in that stage. They get your attention nicely :-) Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-25 01:52 +0100 |
| Message-ID | <m50js6$jrv$1@dont-email.me> |
| In reply to | #34615 |
Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Yes, I know. My point is that I would prefer it not to trap, because >> there's nothing really useful you can do at that point. Better to >> design your application so that's not relevant. > > In the real world we find that integer overflow is a perennial source of > bugs in programs, and that trapping overflow in software is expensive > enough that people usually don't compile code that way. Regehr argues > that the right solution is for cpus to include hardware traps for > integer overflow. Andrew and some others say that this would impact > performance or otherwise add significant cost. I'm trying to understand > the reason for that, since cpus already include multiple arithmetic > traps such as zero-divide and various FPU signalling conditions. The question is probably how many of these possible traps your CPU can handle simultaneously, so how that impacts the instruction scheduler - and how much information you need to keep on trapable instructions to roll them back. I think if you do it right with an OOO execution unit, every instruction can possibly trap with a uniform way of dealing with that. Traps on current CPUs are pretty expensive in numbers of cycles wasted, but only if they actually happen. Of course, each instruction which can trap needs more informations attached, so it consumes more resources on the chip. If you have "fire&forget" types of instructions, where you are always sure that they will complete, you can spare the resources on those paths through the execution unit. This allows to make the integer unit considerably smaller (just ALU and a rather simple reservation station) - you do the register renaming, but you don't have to remember how to roll back if there's an exception. From the look of it, the ARMv8 designer have made some effort to reduce the number of traps, e.g. even division by zero doesn't trap. If you want to catch that error, ARM recommends that you put a conditional branch after executing the division, which will be hidden in the long time the division instruction takes (the conditional branch is usually not taken). IMHO, it's way easier to have a trap on overflow on an in-order VLIW machine. There, if one operation traps, the entire instruction word is aborted, i.e. all results don't get written. That is the case with any exception, so you can have all instruction slots trap with very little additional costs (just the or tree to figure out that there is a trap event). There probably still are costs with that, e.g. wire delay slowdown because you now have more sources of the trap, or additional shadow registers in the bypass logic. In general, it is wise to assume that every additional feature comes at a cost, so the TRANSTAAFL rule applies. For the instruction set designer, it's wiser to implement simple instructions with the least amount of possible side-effects, and construct more complex operations out of sequences of instructions. Another point is a typical chicken&egg problem: as instruction set designer, you think about stuff that popular current programming languages support. For example, if you want to generate trap-on-overflow, the number of types you need for a given word size goes from two to three: You want signed, unsigned, and mod 2^n. The latter is e.g. important for cryptocores which use add, rotate and xor; these additions are meant to work on mod 2^n, not on signed or unsigned, so an overflow just can't happen. This also means that you won't get support for overflow traps into these mainstream languages soon, because that will break way too many code. You can try using gcc with -ftrapv, and watch your programs crash at places, where wraparound was intended. Sidenode: ARMv8 has four options on logical operations with shift: shift left, shift right, arithmetic shift right, and rotate right. But it doesn't have the rotate right operation on add and sub. However, if you look at somewhat popular crypto cores like ChaCha, this uses add+rotated input. That sort of thing IMHO is crazy: obviously, they have the rotating logic there. They just don't use it on additions. ChaCha could be modified to rotate the inputs on xors instead, but that would be an incompatible algorithm. Here, chicken and egg are arguable different: ChaCha has rotated inputs to the adder, the similar construct Threefish has rotated inputs on the xor, and both were cores of promising SHA-3 candidates when ARMv8 was developed. This sort of stuff is something you really should look at when you are an ISA designer. -- 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-25 11:43 +0000 |
| Message-ID | <2014Nov25.124322@mips.complang.tuwien.ac.at> |
| In reply to | #34619 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>The question is probably how many of these possible traps your CPU can
>handle simultaneously, so how that impacts the instruction scheduler - and
>how much information you need to keep on trapable instructions to roll them
>back.
>
>I think if you do it right with an OOO execution unit, every instruction can
>possibly trap with a uniform way of dealing with that. Traps on current
>CPUs are pretty expensive in numbers of cycles wasted, but only if they
>actually happen. Of course, each instruction which can trap needs more
>informations attached, so it consumes more resources on the chip. If you
>have "fire&forget" types of instructions, where you are always sure that
>they will complete, you can spare the resources on those paths through the
>execution unit. This allows to make the integer unit considerably smaller
>(just ALU and a rather simple reservation station) - you do the register
>renaming, but you don't have to remember how to roll back if there's an
>exception.
In a typical OoO core, there are no fire&forget instructions, and
there is no rolling back. Operations are executed out-of-order, and
when they are complete, they are committed (retired) in-order. If an
instruction does a mispredicted control flow (i.e., a branch
mispredicts or a trapping instruction traps), all later instructions
are not commited, and the CPU starts working on the new control flow.
For instructions that cannot trap, you don't need to remember an
alternative control flow, but it's not clear that this is really a
significant savings. The K7/K8 could deal with three load-operate or
RMW instructions per cycle in the decode/dispatch/retire parts of the
CPU, even though it had only two load/store units, so apparently the
cost of potential exceptions was not high on that design.
>IMHO, it's way easier to have a trap on overflow on an in-order VLIW
>machine. There, if one operation traps, the entire instruction word is
>aborted, i.e. all results don't get written.
Might work for trap-on-overflow for add and subtract, where you know
about the overflow in one cycle. In general it seems that in-order
CPUs have a harder time implementing precise exceptions than OoO CPUs.
- 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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web