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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-25 03:35 -0600 |
| Message-ID | <J4OdnXFbh7j30OnJnZ2dnUU7-QOdnZ2d@supernews.com> |
| In reply to | #34615 |
Paul Rubin <no.email@nospam.invalid> wrote: > > 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. A trap on division by zero isn't that bad because division is already a high-latency operation. In practice, language runtimes sometimes surround a call to divide with code which checks the preconditions because a trap is awkward to handle. In retrospect it would have been much better if division by zero did not trap. In the floating-point case it is rare for traps to be enabled, and many processors don't support floating-point traps at all. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-25 09:37 -0800 |
| Message-ID | <7x61e3uqpn.fsf@ruckus.brouhaha.com> |
| In reply to | #34627 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > A trap on division by zero isn't that bad because division is already > a high-latency operation. As another example as you mentioned, load and store instructions trap, e.g. because of address errors. Are arithmetic traps somehow more difficult? > In the floating-point case it is rare for traps to be enabled, and > many processors don't support floating-point traps at all. Hmm, I thought IEEE 754 required some operations to signal errors.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-26 03:57 -0600 |
| Message-ID | <VKmdna3bTqecOejJnZ2dnUVZ8oidnZ2d@supernews.com> |
| In reply to | #34637 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> A trap on division by zero isn't that bad because division is already >> a high-latency operation. > > As another example as you mentioned, load and store instructions trap, > e.g. because of address errors. Are arithmetic traps somehow more > difficult? No, but trapping on address errors is hard and limits speculation, and a lot of silicon ends up being devoted to it. >> In the floating-point case it is rare for traps to be enabled, and >> many processors don't support floating-point traps at all. > > Hmm, I thought IEEE 754 required some operations to signal errors. It does, but they're using the word "signal" in a rather odd way: one way to "signal" is to set a bit in a condition code register. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-25 11:16 +0000 |
| Message-ID | <2014Nov25.121648@mips.complang.tuwien.ac.at> |
| In reply to | #34615 |
Paul Rubin <no.email@nospam.invalid> writes:
>"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 most common and important occurance of instructions that can cause
exceptions is loads and stores, and that's also the most common
occurence of instructions that do cause exceptions.
Concerning your question, I already gave an answer in
<2014Nov24.132420@mips.complang.tuwien.ac.at>.
>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.
That is often a better idea than trapping on overflow. Implementing
bigints based on trapping instructions is harder and slower than
implementing them based on e.g., the AMD64 instruction JO.
- 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 02:06 -0500 |
| Message-ID | <m519qh$o79$1@dont-email.me> |
| In reply to | #34614 |
On 11/24/2014 5:28 PM, Elizabeth D. Rather wrote: > 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. I think that is an interesting question. I worked with Transputers at one point and they support trapping on overflows. The idea was that if the calculation was going to overflow in a critical use, it is better to stop the app than to continue with erroneous data. Knowing what to do from there is always a trick. But continuing with bad data can be fatal. To say the app should be designed to *never* encounter a failure mode is a bit convenient. That's not always possible for complex calculations. The attempt can be made, but how can you *always* verify that a bad calculation won't happen? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-11-24 21:40 -1000 |
| Message-ID | <asmdnZPsK8kVr-nJnZ2dnUU7-KOdnZ2d@supernews.com> |
| In reply to | #34622 |
On 11/24/14 9:06 PM, rickman wrote: > On 11/24/2014 5:28 PM, Elizabeth D. Rather wrote: >> 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. > > I think that is an interesting question. I worked with Transputers at > one point and they support trapping on overflows. The idea was that if > the calculation was going to overflow in a critical use, it is better to > stop the app than to continue with erroneous data. Knowing what to do > from there is always a trick. But continuing with bad data can be fatal. > > To say the app should be designed to *never* encounter a failure mode is > a bit convenient. That's not always possible for complex calculations. > The attempt can be made, but how can you *always* verify that a bad > calculation won't happen? When you are doing a calculation on data in an application, you should know what the anticipated range of data you're dealing with is. Whether it's temperatures, voltages, dollar amounts, or number of items to be purchased, there is a particular range you are prepared to handle. At the point at which the data enters the system, you can check that it's within the appropriate range, and take action if it isn't. The specs for the application tell you what the range is. Algorithms should be thoroughly tested through the full range of data to be legally submitted to the application, and if you know both that these tests work and that you will never allow data with inappropriate values to enter the system, then you have full control. In other words, the place to manage these issues most effectively is the point at which data is entered, whether from a device or a human user. It's really an application design rule more than anything else. 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 23:57 -0800 |
| Message-ID | <7xvbm3zp9i.fsf@ruckus.brouhaha.com> |
| In reply to | #34623 |
"Elizabeth D. Rather" <erather@forth.com> writes: > When you are doing a calculation on data in an application, you should > know what the anticipated range of data you're dealing with Are you claiming you've never shipped a program with a bug in it? Most of us have. Question then is what you want it to do once the bug is triggered. Maybe in some embedded control applications you want the program to keep running regardless, like you'd want a plane to keep flying even if one of the engines has fallen off, to avoid disaster. In static applications it's often better to crash the program with an error message, creating some inconvenience (but not disaster) so that the problem can be investigated and fixed.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-25 03:37 -0500 |
| Message-ID | <m51f4b$81f$1@dont-email.me> |
| In reply to | #34623 |
On 11/25/2014 2:40 AM, Elizabeth D. Rather wrote: > On 11/24/14 9:06 PM, rickman wrote: >> On 11/24/2014 5:28 PM, Elizabeth D. Rather wrote: >>> 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. >> >> I think that is an interesting question. I worked with Transputers at >> one point and they support trapping on overflows. The idea was that if >> the calculation was going to overflow in a critical use, it is better to >> stop the app than to continue with erroneous data. Knowing what to do >> from there is always a trick. But continuing with bad data can be fatal. >> >> To say the app should be designed to *never* encounter a failure mode is >> a bit convenient. That's not always possible for complex calculations. >> The attempt can be made, but how can you *always* verify that a bad >> calculation won't happen? > > When you are doing a calculation on data in an application, you should > know what the anticipated range of data you're dealing with is. Whether > it's temperatures, voltages, dollar amounts, or number of items to be > purchased, there is a particular range you are prepared to handle. At > the point at which the data enters the system, you can check that it's > within the appropriate range, and take action if it isn't. The specs for > the application tell you what the range is. There is the fallacy. The problem does not have to be an input out of range. Some computations are more complex than that. For example, GPS computations are exceedingly difficult and can at times produce erroneous results. If the error comes from the calculation itself such as a divide by zero or an addition overflow, that can be trapped and the result flagged as invalid rather than being displayed to the user. > Algorithms should be thoroughly tested through the full range of data to > be legally submitted to the application, and if you know both that these > tests work and that you will never allow data with inappropriate values > to enter the system, then you have full control. Have you ever looked at chaos theory? If you are working with well behaved linear equations, maybe you can define the parameters over which they will work without fail. But there are other times when this simply can't be done with precision. > In other words, the place to manage these issues most effectively is the > point at which data is entered, whether from a device or a human user. > > It's really an application design rule more than anything else. It's nice work if you can get it! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-25 03:43 -0600 |
| Message-ID | <J4OdnXBbh7jb0unJnZ2dnUU7-QNi4p2d@supernews.com> |
| In reply to | #34623 |
Elizabeth D. Rather <erather@forth.com> wrote: > On 11/24/14 9:06 PM, rickman wrote: >> >> To say the app should be designed to *never* encounter a failure mode is >> a bit convenient. That's not always possible for complex calculations. >> The attempt can be made, but how can you *always* verify that a bad >> calculation won't happen? > > When you are doing a calculation on data in an application, you > should know what the anticipated range of data you're dealing with > is. Whether it's temperatures, voltages, dollar amounts, or number > of items to be purchased, there is a particular range you are > prepared to handle. At the point at which the data enters the > system, you can check that it's within the appropriate range, and > take action if it isn't. The specs for the application tell you what > the range is. Well, hold on, Elizabeth. We've surely both programmed real-time SCADA Forth applications with user-extensible languages. There's no way to control things like input ranges in that case, and it is very useful to tell the user that an overflow has occurred. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-11-25 15:26 +0000 |
| Message-ID | <54749faf$0$6907$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #34622 |
In article <m519qh$o79$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 11/24/2014 5:28 PM, Elizabeth D. Rather wrote: >> 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. > >I think that is an interesting question. I worked with Transputers at >one point and they support trapping on overflows. The idea was that if >the calculation was going to overflow in a critical use, it is better to >stop the app than to continue with erroneous data. Knowing what to do >from there is always a trick. But continuing with bad data can be fatal. > >To say the app should be designed to *never* encounter a failure mode is >a bit convenient. That's not always possible for complex calculations. > The attempt can be made, but how can you *always* verify that a bad >calculation won't happen? An interesting example I had at Philips matlab. I had an floating underflow which supposedly is impossible. After an investigation I discovered that in this innocent looking polynomial interpolation some-one used the real value of electron charge 10^-19 . Such value raised to the power 5 or 6 can cause underflow. Without traps you'de never know or expect, and the circuit designed thusly fails in mysterious ways. > >Rick Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-25 15:47 +0000 |
| Message-ID | <2014Nov25.164755@mips.complang.tuwien.ac.at> |
| In reply to | #34632 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>An interesting example I had at Philips matlab. I had an floating underflow
>which supposedly is impossible. After an investigation I discovered that
>in this innocent looking polynomial interpolation some-one used the
>real value of electron charge 10^-19 . Such value raised to the power
>5 or 6 can cause underflow. Without traps you'de never know or expect,
>and the circuit designed thusly fails in mysterious ways.
FP values very close to 0 are pretty common in some computations.
IEEE FP has denormal numbers in order to have nicer arithmetic
properties in that area (than just turning every number that cannot be
represented as a normalized number into 0). Dealing with that in
hardware is relatively costly, so hardware manufacturers added an
exception in that case so software could handle these cases (e.g., on
the Alpha). Then the programmer had a choice: Enable denormal
handling, and be slow on some data, or have denormal->0, and be fast,
but (depending on the program) incorrect.
Having the exception come through to the application program as
"underflow" seems wrong to me, though. FP arithmetics loses precision
all the time, denormal->0 is just one variant of 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-11-25 03:30 -0600 |
| Message-ID | <9PudnemVhPaB0enJnZ2dnUU7-WednZ2d@supernews.com> |
| In reply to | #34610 |
Paul Rubin <no.email@nospam.invalid> 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. You can write reliable systems in all sorts of ways. What is it with Erlang all of a sudden? It's beeing hyped every which 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? On x86 you get a precise trap. It varies on other systems. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-25 09:32 -0800 |
| Message-ID | <7xa93fuqwr.fsf@ruckus.brouhaha.com> |
| In reply to | #34626 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > You can write reliable systems in all sorts of ways. What is it with > Erlang all of a sudden? It's beeing hyped every which way. It was just an example of a drastic but practical way an HLL could handle something as ugly as an imprecise trap. I'm not aware of Erlang getting more hype than usual these days. I used it for a while but I think Go is getting more attention now.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-25 11:11 +0000 |
| Message-ID | <2014Nov25.121155@mips.complang.tuwien.ac.at> |
| In reply to | #34610 |
Paul Rubin <no.email@nospam.invalid> writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> 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?
On IA-32 and AMD64, you get a precise exception. On PowerPC, IIRC you
get all-bits-set. Alpha does not have a division instruction.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-24 12:24 +0000 |
| Message-ID | <2014Nov24.132420@mips.complang.tuwien.ac.at> |
| In reply to | #34596 |
Paul Rubin <no.email@nospam.invalid> writes:
>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.
It costs lots extra in an in-order architecture. In an OoO
architecture there is little extra cost (you already have the
mechanism for dealing with branch mispredictions). However, Bernd
Paysan argued (here a few months ago) that having more potential
branches/traps per cycle costs extra.
>1. Does that penalty still happen when the trap doesn't occur?
Apparently so, if we believe the numbers given in the blog posting.
Regehr claims large to huge slowdowns from checking for overflow. If
the numbers are correct (I have my doubts about that), that's not
because there are one-byte (INTO) or two-byte (JO) nops after
additions and subtractions, but because these instructions, even when
they do nothing, cost more than nops.
>2. I don't see why it has to be a precise trap.
For implementing BigInts (which is one of the applications where John
Regehr wants to replace existing solutions with the trapping
instructions), it has to be a precise exception: You do the BigInt
computation in the exception handler, then continue with the original
program. BTW, that's one application that would see a significant
slowdown from switching to Regehr's way.
For debugging, it has to be a precise exception. You want to know
where the exception happened.
>What happens now with floating
>point traps? They were imprecise on some of the old machines, and
>people dealt with it.
Yes, and it was painful. Alpha had the TRAPB (trap barrier)
instruction that gave an upper limit to the amount of imprecision.
The usual way was to either run without exceptions enabled and not use
TRAPB, or to run with exceptions enabled and have a TRAPB after every
FP instruction.
The latter was much slower on the in-order implementations of the
Alphas, because the TRAPB waited until all exception-generating
instructions in the pipeline knew whether they would generate an
exception or not.
On the out-of-order 21264, there was no significant speed difference
between having the TRAPBs or not. My guess is that the FP
instructions generated precise exceptions on this CPU even without
TRAPB, and that TRAPB was a noop there.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-11-25 09:45 -0800 |
| Message-ID | <7x1toruqbu.fsf@ruckus.brouhaha.com> |
| In reply to | #34600 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>2. I don't see why it has to be a precise trap. > For implementing BigInts (which is one of the applications where John > Regehr wants to replace existing solutions with the trapping > instructions), it has to be a precise exception: In the case of expensive or imprecise traps, you'd want to do bigints the traditional way. The arithmetic trap would just be to handle unexpected overflow, like a segmentation fault on an invalid address.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-24 10:17 +0000 |
| Message-ID | <2014Nov24.111759@mips.complang.tuwien.ac.at> |
| In reply to | #34593 |
Paul Rubin <no.email@nospam.invalid> writes:
>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
From the comments:
|Those who do not understand the hardware are doomed to blog about it,
|poorly.
Very appropriate for this blog entry.
Concerning RISC-V, however, I do see a problem. There is no cheap way
to check for a signed overflow as far as I can see. For architectures
with flag registers, one can check the overflow flag. MIPS and Alpha
have instructions that trap on signed overflow (so signed overflow
handling is expensive, but checking is relatively cheap). RISC-V has
neither.
- 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-17 23:20 -0500 |
| Message-ID | <m4ehg0$8og$1@dont-email.me> |
| In reply to | #34459 |
On 11/17/2014 5:26 AM, JUERGEN wrote: > Is anybody here involved in thei project, to make them aware of requirements to run Forth efficiently? > > http://www.lowrisc.org/ > > From the website: > > lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco-system. > > Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. There are more details on our plans in these slides from a recent talk > > lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community. > > To keep track of the project, follow @lowRISC or join our announcements list by entering your email below: I'm curious, why do you think this processor might *not* implement Forth efficiently? In reality Forth is just a language and can be implemented as efficiently as any other language on a given machine. It just requires a well written compiler. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-11-17 23:31 -0800 |
| Message-ID | <354f6fc9-7a56-4e7f-9336-2c3aa0003eb5@googlegroups.com> |
| In reply to | #34473 |
marți, 18 noiembrie 2014, 06:21:34 UTC+2, rickman a scris: > On 11/17/2014 5:26 AM, JUERGEN wrote: > > Is anybody here involved in thei project, to make them aware of requirements to run Forth efficiently? > > > > http://www.lowrisc.org/ > > > > From the website: > > > > lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco-system. > > > > Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. There are more details on our plans in these slides from a recent talk > > > > lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community. > > > > To keep track of the project, follow @lowRISC or join our announcements list by entering your email below: > > I'm curious, why do you think this processor might *not* implement Forth > efficiently? In reality Forth is just a language and can be implemented > as efficiently as any other language on a given machine. It just > requires a well written compiler. > > -- > > Rick Well, forth may be just a language, but it has an explicit stack which will make its life harder on register based architectures. Forth can compete with C compilers on older processors with very few registers (Z80, HC08, etc) where the C is forced to do parameter passing on stack, like the forth. On the new architectures with lots of registers, there is virtually no parameter passing on stack anymore, almost all parameters are passed in registers. This is hard to fit in a forth compiler. All that a forth compiler can do is to optimize the local body of a function to use registers as much as possible, and the resulting code will hardly look like the original source. I don't know if this is good or bad, C uses the same approach, but C at least doesn't claim to be REPL, and when forth looses its REPL, what else it remains? I personally find that for big designs, the C is better mostly because it is just more descriptive and self commenting due to the explicit parameter passing. Everything in C have names, parameters, local variables. In forth parameters are hidden, even some locals are hidden because of the use of stack instead of local variables. This is a big minus for forth, at least regarding big projects. When you read forth sources, you invariably find names that you just don't know (or just forgot) what parameters are they expected on the stack and what results they leave.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-18 02:44 -0500 |
| Message-ID | <m4ete9$68g$1@dont-email.me> |
| In reply to | #34474 |
On 11/18/2014 2:31 AM, Raimond Dragomir wrote: > marți, 18 noiembrie 2014, 06:21:34 UTC+2, rickman a scris: >> On 11/17/2014 5:26 AM, JUERGEN wrote: >>> Is anybody here involved in thei project, to make them aware of requirements to run Forth efficiently? >>> >>> http://www.lowrisc.org/ >>> >>> From the website: >>> >>> lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco-system. >>> >>> Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. There are more details on our plans in these slides from a recent talk >>> >>> lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community. >>> >>> To keep track of the project, follow @lowRISC or join our announcements list by entering your email below: >> >> I'm curious, why do you think this processor might *not* implement Forth >> efficiently? In reality Forth is just a language and can be implemented >> as efficiently as any other language on a given machine. It just >> requires a well written compiler. >> >> -- >> >> Rick > > Well, forth may be just a language, but it has an explicit stack which will make its life harder on register based architectures. Forth can compete with C compilers on older processors with very few registers (Z80, HC08, etc) where the C is forced to do parameter passing on stack, like the forth. On the new architectures with lots of registers, there is virtually no parameter passing on stack anymore, almost all parameters are passed in registers.. This is hard to fit in a forth compiler. All that a forth compiler can do is to optimize the local body of a function to use registers as much as possible, and the resulting code will hardly look like the original source. I don't know if this is good or bad, C uses the same approach, but C at least doesn't claim to be REPL, and when forth looses its REPL, what else it remains? I personally find that for big designs, the C is better mostly because it is just more descriptive and self commenting due to the explicit parameter passing. Ever ything in C have names, parameters, local variables. In forth parameters are hidden, even some locals are hidden because of the use of stack instead of local variables. This is a big minus for forth, at least regarding big projects. When you read forth sources, you invariably find names that you just don't know (or just forgot) what parameters are they expected on the stack and what results they leave. I don't know what REPL is, so I can't comment on that. But otherwise I think you agreed with me that it is hard to make the design of a RISC CPU unsuitable for Forth. As to your preference for C, I can only say that if you don't comment your Forth code well enough, it is likely that your C code is also not commented well enough. In fact, I have seldom seen code that was adequately commented, including my own. I find this when returning to code a month or two later and even more so when returning to code a year or two later. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web