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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-29 19:04 +0100 |
| Message-ID | <m5d1q7$qi7$1@dont-email.me> |
| In reply to | #34685 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Andrew Haley wrote: >>There's also the point that the base+offset addressing mode requires an >>adder, so if you already have an adder in the memory accessing path, you >>can as well do a reg+reg(+offset) add, and of course, you can also scale >>one of the inputs by a small shift with little effort. > > reg+reg requires an additional register read port for the store > instruction, pretty expensive in particular in a superscalar > implementation. Actually, the data port and the address port(s) of a store instruction aren't really concurrent. You can read the data port one cycle later. Same with load instructions and addressing modes that update the address register: this also is separated by at least one cycle. > Alternatively, support it only for loads, and have a > different address computation path for loads and stores, also not for > free. Shifting by 0-3 bits, as in Intel indexed addressing modes > introduces additional latency in the address computation; if the cost > was insignificant, PowerPC and SPARC would have it. Reg+reg+const > requires more than a simple adder. The cost of a 0-3 bit shift is a 4:1 multiplexer, which is with pre-decoding of the actual selector (into one-hot) is a single non-inverted gate delay (typical 1.5 NAND gate delays). Reg+reg+const requires a carry-save adder to reduce 3 to 2 sums. Cost is a single full adder delay, that's also in the same ballpark (1.5-2 NAND gate delays). The actual tradeoffs are quite different from the early RISC days, where gate delays dominated overall delays, and the transistor budget severely limited how much you could put on a chip; today, it's wire RC delays which dominate. So logic is now nearly for free, as long as you manage to keep things close together. -- 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-30 15:48 +0000 |
| Message-ID | <2014Nov30.164829@mips.complang.tuwien.ac.at> |
| In reply to | #34692 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Andrew Haley wrote:
>>>There's also the point that the base+offset addressing mode requires an
>>>adder, so if you already have an adder in the memory accessing path, you
>>>can as well do a reg+reg(+offset) add, and of course, you can also scale
>>>one of the inputs by a small shift with little effort.
>>
>> reg+reg requires an additional register read port for the store
>> instruction, pretty expensive in particular in a superscalar
>> implementation.
>
>Actually, the data port and the address port(s) of a store instruction
>aren't really concurrent. You can read the data port one cycle later.
But then the next instruction cannot access its source registers and
has to wait for a cycle. So you have turned the store into a
two-cycle instruction. Is the slowdown from that compensated by the
benefits of reg+reg?
>Same
>with load instructions and addressing modes that update the address
>register: this also is separated by at least one cycle.
Again, either one more write port, or the with-update instruction
takes two cycles. Here it is probably easier to make the not-updating
version take only one cycle, so having a with-update version costs
only a little complexity and may pay for that by saving on code space.
>The actual tradeoffs are quite different from the early RISC days, where
>gate delays dominated overall delays, and the transistor budget severely
>limited how much you could put on a chip; today, it's wire RC delays which
>dominate. So logic is now nearly for free, as long as you manage to keep
>things close together.
Well, keeping the complexity of, e.g., addressing modes small should
help keeping things close together. All those MUXes you write about
cost area, no?
In any case, the only recent from-scratch architecture that I am aware
of is RISC-V. It deviates from classic RISC principles by having
variable-width instructions (so it is obviously not an orthodox RISC),
but it does not add an indexed addressing mode (which would not be
against classic RISC principles). Apparently the RISC-V architects
don't see the value of an indexed addressing mode as sufficient to add
it despite the different tradeoffs.
64-bit ARM has indexed addressing because 32-bit ARM has it. I would
not make sense to pay for indexed addressing hardware and then not be
able to use it in 64-bit mode.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-30 17:36 +0100 |
| Message-ID | <m5fh1u$q1g$1@dont-email.me> |
| In reply to | #34714 |
Anton Ertl wrote: > But then the next instruction cannot access its source registers and > has to wait for a cycle. So you have turned the store into a > two-cycle instruction. Is the slowdown from that compensated by the > benefits of reg+reg? No, the two-cycle instruction is just how the order of things happen. If you hide that, you have to add other things. E.g. a latch to keep the last stored value and a bypass logic if the next load accesses the same memory location (which actually happens more often than you would think it does). >>Same >>with load instructions and addressing modes that update the address >>register: this also is separated by at least one cycle. > > Again, either one more write port, or the with-update instruction > takes two cycles. Here it is probably easier to make the not-updating > version take only one cycle, so having a with-update version costs > only a little complexity and may pay for that by saving on code space. Well, you save the most if there is a "single register without offset and anything" address mode. This would take one cycle, all others would take two cycles and require additional ports. Or you could break it down to an "compute address" instruction and a load/store instruction which just takes one address. That's how this usually works after the decoding stage. >>The actual tradeoffs are quite different from the early RISC days, where >>gate delays dominated overall delays, and the transistor budget severely >>limited how much you could put on a chip; today, it's wire RC delays which >>dominate. So logic is now nearly for free, as long as you manage to keep >>things close together. > > Well, keeping the complexity of, e.g., addressing modes small should > help keeping things close together. All those MUXes you write about > cost area, no? Way less than the adder (with carry-lookahead logic), which can be shared with the rest of the ALU. And the actual area in memory accesses is in the cache SRAM, not in the address ALU. > In any case, the only recent from-scratch architecture that I am aware > of is RISC-V. It deviates from classic RISC principles by having > variable-width instructions (so it is obviously not an orthodox RISC), > but it does not add an indexed addressing mode (which would not be > against classic RISC principles). Apparently the RISC-V architects > don't see the value of an indexed addressing mode as sufficient to add > it despite the different tradeoffs. > > 64-bit ARM has indexed addressing because 32-bit ARM has it. I would > not make sense to pay for indexed addressing hardware and then not be > able to use it in 64-bit mode. Oh, that is non-sequitur. They have the rotation hardware for logic instructions, they have the decoder for that, they have the spare bits in the instruction word, and yet they don't use rotating inputs for add and subtract (you still have three other shifts, which use the same hardware barrel shifter, and that hardware is capable of rotating and shifting quite well). Even though there are popular crypto cores out which use exactly that sequence: rotated inputs into the adder. Suppose ARM64 had just the single address register load/store I was suggesting; and it would have an "generate address" operation with shift+constant+reg+reg, which would just use the normal ALU (I didn't look up, but I suppose they have the equivalent of lea). That would not work that good on ARM32, due to the higher register pressure. But this lea gives you everything, including updated addresses, and it is more natural with a simplictic implementation (where you really want the fast path of having the ultra-simple addressing mode). -- 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-12-03 14:25 +0000 |
| Message-ID | <2014Dec3.152540@mips.complang.tuwien.ac.at> |
| In reply to | #34717 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> But then the next instruction cannot access its source registers and
>> has to wait for a cycle. So you have turned the store into a
>> two-cycle instruction. Is the slowdown from that compensated by the
>> benefits of reg+reg?
>
>No, the two-cycle instruction is just how the order of things happen. If
>you hide that, you have to add other things. E.g. a latch to keep the last
>stored value
Yes; so have the option of making store a two-cycle instruction
without latch, or a one-cycle instruction with latch. But if your
store takes three registers, the latter option needs one additional
read port in the registers. In a cost-benefit analysis, a (cheap)
latch to make about 10% of the dynamic instructions one cycle faster
is a good tradeoff for all but the most minimal implementations. An
(expensive) additional register port to allow an addressing mode that
probably saves less cycles is more questionable.
Or you could make the store two-cycle to allow the additional
addressing mode without a third read port. The two-cycle store would
cost some performance, the additional addressing mode would save some
(probably less), and you save the latch; the additional addressing
mode seems only a good tradeoff to me if this is the only kind of
implementation you want to support.
> and a bypass logic if the next load accesses the same memory
>location (which actually happens more often than you would think it does).
One may have a store-to-load forwarding path (but even K7 and Pentium
III did not have that, so it seems an option for very big designs),
but I don't see that this becomes any less necessary if you read the
store value from the register file one cycle later.
>> Again, either one more write port, or the with-update instruction
>> takes two cycles. Here it is probably easier to make the not-updating
>> version take only one cycle, so having a with-update version costs
>> only a little complexity and may pay for that by saving on code space.
>
>Well, you save the most if there is a "single register without offset and
>anything" address mode. This would take one cycle, all others would take
>two cycles and require additional ports.
reg+const does not take additional ports, and with sum-addressed
memory, not more cycles, either. My guess is that reg+const is in so
many architectures because of 1) sum-addressed memory, 2) const!=0
happens frequently, and 3) it's a good use of space in a 32-bit
fixed-width instruction.
>> 64-bit ARM has indexed addressing because 32-bit ARM has it. I would
>> not make sense to pay for indexed addressing hardware and then not be
>> able to use it in 64-bit mode.
>
>Oh, that is non-sequitur.
So is your claim that it does make sense to pay for indexed addressing
hardware and not be able to use it in 64-bit mode? Why?
>They have the rotation hardware for logic
>instructions, they have the decoder for that, they have the spare bits in
>the instruction word, and yet they don't use rotating inputs for add and
>subtract (you still have three other shifts, which use the same hardware
>barrel shifter, and that hardware is capable of rotating and shifting quite
>well).
>
>Even though there are popular crypto cores out which use exactly that
>sequence: rotated inputs into the adder.
You would have to ask the architects why they did not include that. I
can only guess: Maybe they were not aware of such crypto cores, or
they expected cryptography to happen in dedicated hardware.
>Suppose ARM64 had just the single address register load/store I was
>suggesting; and it would have an "generate address" operation with
>shift+constant+reg+reg, which would just use the normal ALU (I didn't look
>up, but I suppose they have the equivalent of lea). That would not work
>that good on ARM32, due to the higher register pressure. But this lea gives
>you everything, including updated addresses, and it is more natural with a
>simplictic implementation (where you really want the fast path of having the
>ultra-simple addressing mode).
Sounds great. So what do you think why have the ARM64 architects not
done this? And the RISC-V ones neither? Alpha is pretty close with
its s4add s8add instructions and its reg+const addressing mode.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2014-12-04 20:04 -0800 |
| Message-ID | <73b56568-d6c1-4c7b-9cea-c2454a6951be@googlegroups.com> |
| In reply to | #34765 |
On Wednesday, December 3, 2014 9:47:30 AM UTC-7, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >Anton Ertl wrote: > >> But then the next instruction cannot access its source registers and > >> has to wait for a cycle. So you have turned the store into a > >> two-cycle instruction. Is the slowdown from that compensated by the > >> benefits of reg+reg? > > > >No, the two-cycle instruction is just how the order of things happen. If > >you hide that, you have to add other things. E.g. a latch to keep the last > >stored value > > Yes; so have the option of making store a two-cycle instruction > without latch, or a one-cycle instruction with latch. The MiniForth did store in one clock-cycle 20 years ago (it could do up to 5 instructions concurrently, and one of them could be a memory access) --- all of this complication that you guys are describing disappears with a Harvard Architecture.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-12-04 08:37 -0600 |
| Message-ID | <OZOdnUarkeEA7B3JnZ2dnUVZ8tqdnZ2d@supernews.com> |
| In reply to | #34717 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Even though there are popular crypto cores out which use exactly that > sequence: rotated inputs into the adder. Which ones? Serpent? > ARM64 had just the single address register load/store I was > suggesting; and it would have an "generate address" operation with > shift+constant+reg+reg, which would just use the normal ALU (I > didn't look up, but I suppose they have the equivalent of lea). They have the equivalent: an add instruction has all of the modes you need to do anything that load/store instructions can generate. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-12-04 21:39 +0100 |
| Message-ID | <m5qgol$2s2$1@dont-email.me> |
| In reply to | #34775 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Even though there are popular crypto cores out which use exactly that >> sequence: rotated inputs into the adder. > > Which ones? Serpent? ChaCha does the rotated inputs into the adder, Threefish rotates inputs into an XOR. Both were SHA-3 finalists when ARM64 was designed; ChaCha is pretty popular with people who don't like NIST crypto (however, there are now way more of those than there used to be before June 2013 ;-). Add+Rotate+Xor is very well analyzed and understood, and therefore many people nowadays prefer these primitives over S-boxes, where it is well understood that data- dependent accesses to tables are a security problem. Keccak uses almost the same primitives, but AND instead of ADD for non- linearity. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-12-05 03:31 -0600 |
| Message-ID | <ddydncMhdsnr5hzJnZ2dnUVZ8kCdnZ2d@supernews.com> |
| In reply to | #34780 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Even though there are popular crypto cores out which use exactly that >>> sequence: rotated inputs into the adder. >> >> Which ones? Serpent? > > ChaCha does the rotated inputs into the adder, Threefish rotates > inputs into an XOR. Both were SHA-3 finalists when ARM64 was > designed; ChaCha is pretty popular with people who don't like NIST > crypto (however, there are now way more of those than there used to > be before June 2013 ;-). Add+Rotate+Xor is very well analyzed and > understood, and therefore many people nowadays prefer these > primitives over S-boxes, where it is well understood that data- > dependent accesses to tables are a security problem. Mmm, that matches what I was thinking, which is why I asked: rotated inputs into ADD aren't even all that common in crypto, and aren't much used elsewhere. Some hash functions, maybe. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-12-05 18:33 +0100 |
| Message-ID | <m5sq9m$cdu$1@dont-email.me> |
| In reply to | #34788 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Andrew Haley wrote: >> >>> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>>> Even though there are popular crypto cores out which use exactly that >>>> sequence: rotated inputs into the adder. >>> >>> Which ones? Serpent? >> >> ChaCha does the rotated inputs into the adder, Threefish rotates >> inputs into an XOR. Both were SHA-3 finalists when ARM64 was >> designed; ChaCha is pretty popular with people who don't like NIST >> crypto (however, there are now way more of those than there used to >> be before June 2013 ;-). Add+Rotate+Xor is very well analyzed and >> understood, and therefore many people nowadays prefer these >> primitives over S-boxes, where it is well understood that data- >> dependent accesses to tables are a security problem. > > Mmm, that matches what I was thinking, which is why I asked: rotated > inputs into ADD aren't even all that common in crypto, and aren't much > used elsewhere. Some hash functions, maybe. No, ChaCha and Threefish are general crypto primitives. That's the way you build modern crypto cores: You don't do something that is only useful for a single purpose; evaluate it under the more restrictive constraints as general primitive, and then depoly it for different use-cases. ChaCha is a stream cipher (i.e. you use key+counter and the one-way permutation to generate a stream of randomness), Threefish is a block cipher (keyed tweak of a permutation of a block of data, two-ways). BTW: Threefish encode gives the rotated result of an ADD into an XOR, Threefish decode, as it's going backwards, gives the rotated result of an XOR into a SUB. So to implement Threefish encode+decode efficiently, you want both rotate into logic as rotate into arithmetic. You probably don't want rotate into SUB as badly, because in the decode phase, you store the rotated result in one register, and the rotated+subtracted result in another register, so you'd have to rotate twice. In the encode part, you have to rotate only once. The only NIST competition in the last years was SHA-3, so all the modern approaches with their multi-purpose primitives ended up as finalists there. That's because they all work pretty well as hash, but that's not their only purpose. The NIST actually is following the advice of these teams to propose the winner (Keccak) not only for hashes, but also for encryption/decryption, and Keccak IMHO is the "best" winner here: It supports AEAD out of the box. The other two cores, ChaCha and Threefish, need a separate authentication algorithm. ChaCha and Threefish are state-of-the-art encrpytion with a much higher security level than AES (though Threefish had to be improved during the SHA-3 competition). I've a nice and short threefish.c here: https://fossil.net2o.de/net2o/finfo?name=threefish/threefish.c Try aarch64-linux-android-gcc-4.9 -O3 -S threefish.c on it and look on the result: [...] eor x26, x26, x5, ror 22 eor x4, x24, x4, ror 25 ror x27, x27, 47 eor x5, x27, x23 eor x22, x28, x22, ror 28 add x27, x26, x25 add x28, x4, x28 ror x4, x4, 55 eor x26, x27, x26, ror 15 add x24, x22, x24 [...] Sometimes, GCC 4.9 does combine the rotates and eors, sometimes not. The ror on x27 could have been merged with the following eor, because x27 is obviously dead (overwritten by the add two lines down the code). There's no earlier GCC to try on Aarch64. I use the one supplied with the most recent Android NDK. Of course, the decode simply doesn't combine anything: [...] eor x9, x6, x9 eor x8, x7, x8 eor x1, x4, x1 eor x3, x3, x5 ror x9, x9, 39 ror x8, x8, 36 ror x1, x1, 49 ror x3, x3, 17 sub x6, x6, x9 sub x7, x7, x8 sub x4, x4, x1 sub x5, x5, x3 [...] -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-12-05 14:56 -0600 |
| Message-ID | <POydnUJcjqlvhh_JnZ2dnUVZ7vSdnZ2d@supernews.com> |
| In reply to | #34795 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > > Try > > aarch64-linux-android-gcc-4.9 -O3 -S threefish.c > > on it and look on the result: > > [...] > eor x26, x26, x5, ror 22 > eor x4, x24, x4, ror 25 > ror x27, x27, 47 > eor x5, x27, x23 > eor x22, x28, x22, ror 28 > add x27, x26, x25 > add x28, x4, x28 > ror x4, x4, 55 > eor x26, x27, x26, ror 15 > add x24, x22, x24 > [...] > > Sometimes, GCC 4.9 does combine the rotates and eors, sometimes not. The > ror on x27 could have been merged with the following eor, because x27 is > obviously dead (overwritten by the add two lines down the code). Hmm, interesting, thanks. I could try our Java port to see what it does. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-11-29 13:07 +0000 |
| Message-ID | <5479c527$0$6900$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #34678 |
In article <n-ednakRyKasP-XJnZ2dnUVZ8l6dnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: <SNIP> > >That doesn't make the argument any less ridiculous: it's no more than >a restatement of it. This instruction is a pattern which corresponds >directly to one of the most-used constructs in a high-level >programming language, and a compiler can directly generate it with >very little effort. Is this still about not providing sophisticated, such as indirect addressing modes on riscy processor like alpha? One of the arguments I heard was that the compiler writers could easily replace the one-to-one instructions with a macro. In doing so the compilation hardly becomes more complicated. On the other site is the benefit of a shorter pipeline (stalls are less troublesome) and less complicated logic, less port delays, hence faster. The bottom line was more processing power for the buck. I think comparing Dec Alpha and Intel bores this out. The clock speeds on the Dec Alpha were way ahead of Intel's at the time. > >Andrew. 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-29 16:00 +0000 |
| Message-ID | <2014Nov29.170059@mips.complang.tuwien.ac.at> |
| In reply to | #34678 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Anyway, this is not about decisions by the customer, but about
>> writing compilers. If the compiler has to make a complicated
>> analysis or try out a lot of variants in order to produce good code,
>> the compiler will be bigger, has more potential for bugs, and makes
>> a lot of work for the compiler writer.
>
>That doesn't make the argument any less ridiculous:
Since the argument never was ridiculous, it's not possible to make it
less ridiculous.
>This instruction is a pattern which corresponds
>directly to one of the most-used constructs in a high-level
>programming language, and a compiler can directly generate it with
>very little effort.
Oh, the semantic gap argument. I though that had died with the VAX.
In that case, the ARMv8 should be pretty bad in your view, and a
64-bit version of the VAX should be the architecture of choice. After
all, it can express something like
a[i] = b[i]+c[i]
directly in one instruction, while ARMv8 needs four.
- 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-29 11:21 -0600 |
| Message-ID | <h_Cdneq8yM40nefJnZ2dnUVZ8lmdnZ2d@supernews.com> |
| In reply to | #34687 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>This instruction is a pattern which corresponds directly to one of >>the most-used constructs in a high-level programming language, and a >>compiler can directly generate it with very little effort. > > Oh, the semantic gap argument. I though that had died with the VAX. No, it didn't. They ultra-minimal RISC didn't win the war, after all: x86 and ARM did. > In that case, the ARMv8 should be pretty bad in your view, and a > 64-bit version of the VAX should be the architecture of choice. Reductio ad absurdum is not a valid argument in the case of careful measured decisions about computer design. It's a matter of well-judged tradeoffs, not extreme positions. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-11-30 15:26 +0000 |
| Message-ID | <2014Nov30.162624@mips.complang.tuwien.ac.at> |
| In reply to | #34691 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>This instruction is a pattern which corresponds directly to one of
>>>the most-used constructs in a high-level programming language, and a
>>>compiler can directly generate it with very little effort.
>>
>> Oh, the semantic gap argument. I though that had died with the VAX.
>
>No, it didn't. They ultra-minimal RISC didn't win the war, after all:
>x86 and ARM did.
Not because the compiler can directly generate code for array accesses
with little effort (most compilers don't do this). VAX is dead, the
68k is not very popular anymore, and its successor Coldfire removed
instructions and addressing modes (but it still has a "Address
Register Indirect with Scaled Index and 8-Bit Displacement Mode",
ideal for Java). PowerPC, SPARC and the rather minimal MIPS are still
around and especially PowerPC and MIPS ship in millions of embedded
systems. I would not be surprised if I had more PowerPC and MIPSes in
my home than AMD64s and ARMs.
>> In that case, the ARMv8 should be pretty bad in your view, and a
>> 64-bit version of the VAX should be the architecture of choice.
>
>Reductio ad absurdum is not a valid argument in the case of careful
>measured decisions about computer design.
But it helps in debunking nonsense arguments like the compiler
argument you were making.
- 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-30 12:49 -0600 |
| Message-ID | <jp-dnRKZ-7sr--bJnZ2dnUU7-S2dnZ2d@supernews.com> |
| In reply to | #34713 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> >>>>This instruction is a pattern which corresponds directly to one of >>>>the most-used constructs in a high-level programming language, and a >>>>compiler can directly generate it with very little effort. >>> >>> Oh, the semantic gap argument. I though that had died with the VAX. >> >>No, it didn't. They ultra-minimal RISC didn't win the war, after all: >>x86 and ARM did. > > Not because the compiler can directly generate code for array accesses > with little effort (most compilers don't do this). Well, hold on: your argument was that there was no need for this addressing mode because Processors X and Y didn't have it. But it's a silly argument anyway, because Processors X and Y might have been quite successful (or indeed unsuccessful) for other reasons. >>> In that case, the ARMv8 should be pretty bad in your view, and a >>> 64-bit version of the VAX should be the architecture of choice. >> >>Reductio ad absurdum is not a valid argument in the case of careful >>measured decisions about computer design. > > But it helps in debunking nonsense arguments like the compiler > argument you were making. An invalid argument does nothing. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-11-24 18:34 +0100 |
| Message-ID | <m4vq5t$drg$1@dont-email.me> |
| In reply to | #34604 |
Andrew Haley wrote: > The full Architectural Reference Manual isn't public (and probably > never will be) but there's plenty of information available on the net. It has been leaked, at least a version marked as "beta" (A.a). It says "non-confidential" on the bottom, but when you click through the ARM site, it says you can't redistribute it. http://115.28.165.193/down/arm/arch/ARMv8-A_Architecture_Reference_Manual_%28Issue_A.a%29.pdf This IP address is in Zhejiang, China... The current reference manual (A.d, fourth beta release) is available for registered ARM customers. To register, all they want to know is your e-mail address, your name, the company you work for, and that's it. It's not the most liberal way to access such a document, but it is available, and you don't sign away your firstborn son. 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. I recommend adding that clause to the GPL as a restriction to the "right to study". -- 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 16:04 +0000 |
| Message-ID | <2014Nov25.170444@mips.complang.tuwien.ac.at> |
| In reply to | #34608 |
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.
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. 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.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-25 14:48 -0500 |
| Message-ID | <m52mfi$4gl$1@dont-email.me> |
| In reply to | #34634 |
On 11/25/2014 11:04 AM, 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. It doesn't matter how the document is marked, if they are making it available to the public the only restriction is copyright and patent, neither of which prevent you from distributing the information. I'm not sure what that means, "You are not allowed to use the information in the document to determine whether ARM violates patents". How can you be given access to information but be restricted in how you use it? If ARM is violating patents, I don't think they can claim you improperly determined that... >> 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 a "clean room" anything is required to pursue a patent infringement case. Clean room is intended to get around copyright issues when you design a product. As long as you don't violate trade secrets you are free to use any info available to you. > 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. 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. I doubt very seriously if lowRISC has a chance of dethroning ARM. If nothing else the sheer money involved makes ARM able to produce new, improved designs much faster than lowRISC is likely to ever be able to do. BTW, how is lowRISC funded again? If it is open source there won't be a revenue stream, will there? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-11-26 00:49 +0000 |
| Message-ID | <54752383$0$6869$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #34642 |
In article <m52mfi$4gl$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 11/25/2014 11:04 AM, Anton Ertl wrote: >issues when you design a product. As long as you don't violate trade >secrets you are free to use any info available to you. You can't violate trade secrets. This is how it works: As an inventor you can protect your invention by making it public (patenting it, from Latin Pateo I disclose). In exchange you get some protection by law, for a limited period of time. The alternative is that you can try to keep it secret. Such trade secrets are liable to reverse engineering. If the secret is thus discovered you can do nothing about it, the cat is out of the bag. A secret can also leak out by someone violating a Non Disclosrue Agreement. Is that what you meant? > >-- > >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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-11-25 21:07 -0500 |
| Message-ID | <m53cls$iik$1@dont-email.me> |
| In reply to | #34647 |
On 11/25/2014 7:49 PM, Albert van der Horst wrote: > In article <m52mfi$4gl$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 11/25/2014 11:04 AM, Anton Ertl wrote: >> issues when you design a product. As long as you don't violate trade >> secrets you are free to use any info available to you. > > You can't violate trade secrets. > > This is how it works: > > As an inventor you can protect your invention > by making it public (patenting it, from Latin Pateo I disclose). > In exchange you get some protection by law, for a limited period of time. > > The alternative is that you can try to keep it secret. Such trade secrets > are liable to reverse engineering. If the secret is thus discovered you can > do nothing about it, the cat is out of the bag. > A secret can also leak out by someone violating a Non Disclosrue Agreement. > Is that what you meant? Yes, if you are given information and notified that it is a trade secret and told you can not divulge it, then then you can not violate that agreement. The case mentioned here doesn't sound like a trade secret as they allow you to share the info if not the document. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web