Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16222 > unrolled thread
| Started by | gavino_himself <visploveslisp@gmail.com> |
|---|---|
| First post | 2012-10-12 13:36 -0700 |
| Last post | 2012-10-18 23:38 -0700 |
| Articles | 20 on this page of 158 — 25 participants |
Back to article view | Back to comp.lang.forth
mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-12 13:36 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-12 22:49 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-13 00:06 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-13 22:34 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-13 16:46 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 00:24 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-14 19:09 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Mark Wills <forthfreak@gmail.com> - 2012-10-15 01:46 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 04:25 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Mark Wills <forthfreak@gmail.com> - 2012-10-15 05:35 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 16:43 -0400
The "memory wall" (was: mr paysan ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-15 09:28 +0000
Re: The "memory wall" (was: mr paysan ...) Mark Wills <forthfreak@gmail.com> - 2012-10-15 03:02 -0700
Re: The "memory wall" (was: mr paysan ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-15 12:50 +0000
Re: The "memory wall" (was: mr paysan ...) Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-15 14:47 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:10 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-18 21:53 -1000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 01:00 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-18 22:18 -1000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-19 09:11 +0000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? visualforth@rocketmail.com - 2012-10-15 03:17 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 16:52 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? visualforth@rocketmail.com - 2012-10-16 02:20 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:13 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:07 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-13 20:53 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-15 15:41 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Mark Wills <forthfreak@gmail.com> - 2012-10-15 07:01 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 09:31 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-15 19:51 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 17:47 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Syd Rumpo <usenet@nononono.co.uk> - 2012-10-16 11:10 +0100
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-16 15:55 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Syd Rumpo <usenet@nononono.co.uk> - 2012-10-16 21:31 +0100
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-16 17:06 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-16 20:56 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-16 23:44 -0500
Transputers, was Re: mr paysan .. gavinoshit albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-17 10:01 +0000
Re: Transputers, was Re: mr paysan .. gavinoshit Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-17 21:11 -0500
Re: Transputers, was Re: mr paysan .. gavinoshit Mark Wills <forthfreak@gmail.com> - 2012-10-18 01:08 -0700
Re: Transputers, was Re: mr paysan .. gavinoshit Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-18 11:42 -0500
Re: Transputers, was Re: mr paysan .. gavinoshit rickman <gnuarm@gmail.com> - 2012-10-18 15:26 -0400
Re: Transputers, was Re: mr paysan .. gavinoshit albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-18 09:25 +0000
Re: Transputers, was Re: mr paysan .. gavinoshit Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-18 11:46 -0500
Re: Transputers, was Re: mr paysan .. gavinoshit rickman <gnuarm@gmail.com> - 2012-10-18 15:28 -0400
Re: Transputers, was Re: mr paysan .. gavinoshit Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-18 12:44 -0700
Re: Transputers, was Re: mr paysan .. gavinoshit Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-18 18:49 -0500
Re: Transputers, was Re: mr paysan .. gavinoshit rickman <gnuarm@gmail.com> - 2012-10-18 20:16 -0400
Re: Transputers, was Re: mr paysan .. gavinoshit Paul Rubin <no.email@nospam.invalid> - 2012-10-18 17:28 -0700
Re: Transputers, was Re: mr paysan .. gavinoshit Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-19 03:00 +0200
Re: Transputers, was Re: mr paysan .. gavinoshit rickman <gnuarm@gmail.com> - 2012-10-19 18:00 -0400
Re: Transputers, was Re: mr paysan .. gavinoshit albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-19 11:35 +0000
Re: Transputers, was Re: mr paysan .. gavinoshit Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-19 10:33 -0500
Re: Transputers, was Re: mr paysan .. gavinoshit Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-18 18:35 +0200
Re: Transputers, was Re: mr paysan .. gavinoshit Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-18 12:06 -0500
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-17 13:23 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-17 11:58 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-17 15:22 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 21:53 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-17 16:00 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 23:10 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-17 17:28 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-18 00:11 +0200
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-18 15:41 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 17:27 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 15:28 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 19:07 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 19:09 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-16 01:21 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 22:26 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 22:35 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-16 01:50 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 22:54 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-16 16:00 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-17 06:40 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-17 13:32 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-17 21:10 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-18 15:45 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-19 19:45 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-16 15:58 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-17 06:32 -0400
"Too much data" (was: mr paysan where is your chip? ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-16 11:46 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) Josh Grams <josh@qualdan.com> - 2012-10-16 16:09 +0000
Re: "Too much data" rickman <gnuarm@gmail.com> - 2012-10-16 16:04 -0400
Re: "Too much data" Elizabeth D Rather <erather@forth.com> - 2012-10-16 11:37 -1000
Re: "Too much data" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-17 14:00 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) humptydumpty <ouatubi@gmail.com> - 2012-10-16 13:25 -0700
Re: "Too much data" (was: mr paysan where is your chip? ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-17 14:08 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) humptydumpty <ouatubi@gmail.com> - 2012-10-18 01:31 -0700
Re: "Too much data" (was: mr paysan where is your chip? ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-18 16:42 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) Ouatu Bogdan <ouatubi@gmail.com> - 2012-10-18 18:41 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) humptydumpty <ouatubi@gmail.com> - 2012-10-18 12:20 -0700
Re: "Too much data" Paul Rubin <no.email@nospam.invalid> - 2012-10-16 21:10 -0700
Re: "Too much data" humptydumpty <ouatubi@gmail.com> - 2012-10-17 05:01 -0700
Re: "Too much data" (was: mr paysan where is your chip? ...) humptydumpty <ouatubi@gmail.com> - 2012-10-16 23:55 -0700
Re: "Too much data" (was: mr paysan where is your chip? ...) humptydumpty <ouatubi@gmail.com> - 2012-10-17 00:06 -0700
Re: "Too much data" (was: mr paysan where is your chip? ...) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-17 10:25 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-17 14:21 +0000
Re: "Too much data" (was: mr paysan where is your chip? ...) Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 17:54 +0200
Re: "Too much data" (was: mr paysan where is your chip? ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-17 15:58 +0000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-16 01:27 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-15 08:02 -1000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? visualforth@rocketmail.com - 2012-10-15 11:39 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Bill Marcum <bill@nowhere.invalid> - 2012-10-21 03:31 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 17:15 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-16 10:00 +0000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:27 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? rickman <gnuarm@gmail.com> - 2012-10-15 17:10 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:30 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-16 01:38 -0400
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? Paul Rubin <no.email@nospam.invalid> - 2012-10-15 22:48 -0700
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-15 21:18 -1000
Re: mr paysan where is your chip? "Ed" <invalid@nospam.com> - 2012-10-16 21:31 +1000
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-16 16:56 +0200
Re: mr paysan where is your chip? visualforth@rocketmail.com - 2012-10-16 11:26 -0700
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-17 12:30 -0700
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 22:35 +0200
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-17 18:15 -0700
Re: mr paysan where is your chip? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-18 16:45 +0000
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-19 00:31 +0200
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-18 22:34 -0700
Re: mr paysan where is your chip? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 01:01 -0700
Re: mr paysan where is your chip? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 01:06 -0700
Re: mr paysan where is your chip? Mark Wills <forthfreak@gmail.com> - 2012-10-19 02:16 -0700
Re: mr paysan where is your chip? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-19 19:51 -0400
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-19 18:25 -0700
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-20 16:49 +0200
Re: mr paysan where is your chip? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-20 22:49 -0400
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-19 22:02 +0200
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-20 17:07 -0700
Re: mr paysan where is your chip? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 14:48 -1000
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-21 02:56 +0200
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-20 22:30 -0700
Trains [Was: mr paysan where is your chip?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 04:46 -0500
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-18 19:28 +0200
Re: mr paysan where is your chip? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:33 -0700
Re: mr paysan where is your chip? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 01:00 -0700
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-19 11:45 -0700
Re: mr paysan where is your chip? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-18 18:26 +0000
Re: mr paysan where is your chip? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-18 08:45 -1000
Re: mr paysan where is your chip? gavino_himself <visploveslisp@gmail.com> - 2012-10-19 00:43 -0700
Re: mr paysan where is your chip? "Ed" <invalid@nospam.com> - 2012-10-22 13:07 +1000
Re: mr paysan where is your chip? Paul Rubin <no.email@nospam.invalid> - 2012-10-21 19:24 -0700
Re: mr paysan where is your chip? Doug Hoffman <glidedog@gmail.com> - 2012-10-22 05:15 -0400
Re: mr paysan where is your chip? Anonymous <nobody@remailer.paranoici.org> - 2012-10-22 14:33 +0000
Re: mr paysan where is your chip? Spam@ControlQ.com - 2012-10-22 12:06 -0400
Re: mr paysan where is your chip? Anonymous <nobody@remailer.paranoici.org> - 2012-10-23 10:44 +0000
Re: mr paysan where is your chip? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 09:29 -0500
Re: mr paysan where is your chip? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 16:30 +0200
Re: mr paysan where is your chip? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-16 08:52 -1000
Re: mr paysan where is your chip? "Ed" <invalid@nospam.com> - 2012-10-17 18:25 +1000
Re: mr paysan where is your chip? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-17 08:33 -1000
Re: mr paysan where is your chip? Frank Thomason <Frank@Thomason.com> - 2012-10-17 15:31 -0400
Re: mr paysan where is your chip? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-18 12:37 -0700
Re: mr paysan where is your chip? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-18 15:57 -1000
Re: mr paysan where is your chip? rickman <gnuarm@gmail.com> - 2012-10-16 16:09 -0400
Re: mr paysan where is your chip? vandys@vsta.org - 2012-10-16 20:27 +0000
Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? gavino_himself <visploveslisp@gmail.com> - 2012-10-18 23:38 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-10-15 03:17 -0700 |
| Message-ID | <aefbfe69-b5f5-441d-b370-502201088c68@googlegroups.com> |
| In reply to | #16249 |
On Saturday, October 13, 2012 10:46:55 PM UTC+2, rickman wrote:> > > >> I remember looking at that some years ago, but I don't recall the > >> significance. What was the advantage of four stacks? What were the > >> "other" two stacks for? > If you don't already know what advantages you get of stacks, please look at "Design of digital computers" by Hans W. Gschwind, Edward J. McCluskey, Springer Verlag, Wien 1967. There you find the explanations why stack computers are the future. It's not only because stack operations are high speed zero address operations. We are all tolerant - as long as the other behaves as expected!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-15 16:52 -0400 |
| Message-ID | <k5ht2e$akg$1@dont-email.me> |
| In reply to | #16286 |
On 10/15/2012 6:17 AM, visualforth@rocketmail.com wrote: > On Saturday, October 13, 2012 10:46:55 PM UTC+2, rickman wrote:> >> >>>> I remember looking at that some years ago, but I don't recall the >>>> significance. What was the advantage of four stacks? What were the >>>> "other" two stacks for? >> > > If you don't already know what advantages you get of stacks, please look at "Design of digital computers" by Hans W. Gschwind, Edward J. McCluskey, Springer Verlag, Wien 1967. There you find the explanations why stack computers are the future. It's not only because stack operations are high speed zero address operations. Wait a minute... you are citing a 35+ year old book for its forecast of the future... what? Today is yesterday's tomorrow! Am I here yet? Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-10-16 02:20 -0700 |
| Message-ID | <a0ef62a2-6273-4717-8895-dafbaa100cc8@googlegroups.com> |
| In reply to | #16308 |
On Monday, October 15, 2012 10:52:32 PM UTC+2, rickman wrote: > On 10/15/2012 6:17 AM, visualforth.com wrote: > > > If you don't already know what advantages you get of stacks, please look at "Design of digital computers" by Hans W. Gschwind, Edward J. McCluskey, Springer Verlag, Wien 1967. There you find the explanations why stack computers are the future. It's not only because stack operations are high speed zero address operations. > > Wait a minute... you are citing a 35+ year old book for its forecast of > the future... what? > > Today is yesterday's tomorrow! Am I here yet? > > Rick Yes, I have the audacity to quote an ancient truth. The Apple is falling since Newton's time, but Chuck Moore is still alive! Dirk Bruehl http://4e4th.com We are all tolerant - as long as the other behaves as expected!
[toc] | [prev] | [next] | [standalone]
| From | gavino_himself <visploveslisp@gmail.com> |
|---|---|
| Date | 2012-10-19 00:13 -0700 |
| Message-ID | <3c30f508-722c-4d01-a5ff-59ffa3ed727e@googlegroups.com> |
| In reply to | #16286 |
On Monday, October 15, 2012 3:17:19 AM UTC-7, visua...@rocketmail.com wrote: > On Saturday, October 13, 2012 10:46:55 PM UTC+2, rickman wrote:> > > > > > > >> I remember looking at that some years ago, but I don't recall the > > > >> significance. What was the advantage of four stacks? What were the > > > >> "other" two stacks for? > > > > > > > If you don't already know what advantages you get of stacks, please look at "Design of digital computers" by Hans W. Gschwind, Edward J. McCluskey, Springer Verlag, Wien 1967. There you find the explanations why stack computers are the future. It's not only because stack operations are high speed zero address operations. > > > > We are all tolerant - as long as the other behaves as expected! do any schools use forth?
[toc] | [prev] | [next] | [standalone]
| From | gavino_himself <visploveslisp@gmail.com> |
|---|---|
| Date | 2012-10-19 00:07 -0700 |
| Message-ID | <0c421a55-0010-4425-97a4-27902f63e226@googlegroups.com> |
| In reply to | #16249 |
On Saturday, October 13, 2012 1:46:55 PM UTC-7, rickman wrote: > On 10/13/2012 4:34 PM, Bernd Paysan wrote: > > > rickman wrote: > > >> I remember looking at that some years ago, but I don't recall the > > >> significance. What was the advantage of four stacks? What were the > > >> "other" two stacks for? > > > > > > This essentially was a VLIW CPU which used a stack architecture to make > > > the instruction word less big. You shouldn't think of the four stacks > > > as similar to the four stacks Gforth has (data, return, float, locals > > > stack), all four are general purpose stacks, and are used for > > > parallelizing instructions. > > > > > >> More importantly, what were it's successes and what were it's > > >> failures? > > > > > > From a personal point of view the architecture's success was that I > > > could write synthesizable Verilog within the time frame of a diploma > > > thesis (which is only half a year), and the failure was that it was too > > > big for the tools our university had back then to make a prototype. > > > > > >> Or in other terms, what was good and what wasn't as good about the > > >> architecture? > > > > > > One thing that definitely wasn't good is the ease to target a C compiler > > > at it (or even a Forth compiler). Back then, people were quite > > > optimistic to improve C compilers towards wider issue machines, i.e. > > > VLIWs, which was also the reason why Intel decided to replace x86 by > > > IA64. They were all wrong. C compilers had just reached the point of > > > unmaintainability, i.e. the point where further progress is almost > > > impossible or at least requires to start over from scratch. Looking at > > > llvm's output convinces me that starting over from scratch just results > > > in faster generation of the same rubbish code and in neater error > > > messages. > > > > > > What it did achieve was a quite high instruction per cycle count while > > > still being quite small. However, as I said in the discussion about > > > GA144 here, what actually matters most in computation performance today > > > is not the CPU, it's the memory. And that's why the CPU architecture > > > isn't important anymore. > > > > > > > Thanks for your explanation. I'm not clear how four stacks with one ALU > > (I'm assuming here since you haven't mentioned more) gives a big > > advantage. But that is what it is and if you aren't working in that > > direction I guess it is not likely to pay off benefits. > > > > I don't agree with your CPU vs. memory generalization. Yes, the GA144 > > is limited by its memory architecture, but that is a limitation, not a > > disqualification. As I have said before, the GA144 is not a processor > > to be compared to the IA64 or the high end ARMs. It can't do the job > > they can do and they can't do the jobs the GA144 can do. It's that > > simple, they are apples and oranges... or should be to everyone other > > than Gavino. > > > > Rick cpu is cpu to me, and when you can surf the web and use interactive websites you win, so when forth can I will be interested in throwing away linux or bsd to use faster better forth
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-13 20:53 -0400 |
| Message-ID | <k5d278$oqk$1@speranza.aioe.org> |
| In reply to | #16247 |
"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message news:51932083.Wq75TzlriR@sunwukong.fritz.box... > rickman wrote: ... > > I remember looking at that some years ago, but I don't recall the > > significance. What was the advantage of four stacks? What were the > > "other" two stacks for? > > This essentially was a VLIW CPU which used a stack architecture to make > the instruction word less big. You shouldn't think of the four stacks > as similar to the four stacks Gforth has (data, return, float, locals > stack), all four are general purpose stacks, and are used for > parallelizing instructions. > Since both Chuck Moore's and Philip Koopman's numerous forrays into stack-based, Forth microprocessors were known failures by the end of the 1980's or early 1990's, what made you believe your stack-based design would be a success? > > More importantly, what were it's successes and what were it's > > failures? > > From a personal point of view the architecture's success was that I > could write synthesizable Verilog within the time frame of a diploma > thesis (which is only half a year), and the failure was that it was too > big for the tools our university had back then to make a prototype. > > > Or in other terms, what was good and what wasn't as good about the > > architecture? > > One thing that definitely wasn't good is the ease to target a C compiler > at it (or even a Forth compiler). Back then, people were quite > optimistic to improve C compilers towards wider issue machines, i.e. > VLIWs, which was also the reason why Intel decided to replace x86 by > IA64. They were all wrong. ... > C compilers had just reached the point of > unmaintainability, i.e. the point where further progress is almost > impossible or at least requires to start over from scratch. Now, that's an interesting an claim. I'm sure the list of reasons would be interesting, to me, or, at least, amusing. They're not suitable for c.l.f., but that goes for this entire thread on obscure, irrelevant, obsolete, microprocessor design. > Looking at > llvm's output convinces me that starting over from scratch just results > in faster generation of the same rubbish code and in neater error > messages. > > What it did achieve was a quite high instruction per cycle count while > still being quite small. However, as I said in the discussion about > GA144 here, what actually matters most in computation performance today > is not the CPU, it's the memory. And that's why the CPU architecture > isn't important anymore. > ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-15 15:41 +0200 |
| Message-ID | <5582590.oV2Wc04zOP@sunwukong.fritz.box> |
| In reply to | #16257 |
Rod Pemberton wrote: > Since both Chuck Moore's and Philip Koopman's numerous forrays into > stack-based, Forth microprocessors were known failures Commercial failures: yes, sort-of (RTX made profits, especially with the radiation-harded RTX2000). Technical failures: not really. I understand that your simple troll-mind can only provoke, and not gain knowledge. > by the end of > the 1980's or early 1990's, what made you believe your stack-based > design would be a success? Come on: This was a cool diploma thesis. The motivation to make a cool diploma thesis is not to get rich quickly, but to explore things nobody else has tried before, i.e. combining things that looked promising from a technical point of view (VLIW+stacks). That's how you make progress (to be precise: I don't mean you personally with "you". Idiot's can't make progress, so maybe you can figure out why "you personally" is ruled out). Even if it is not a commercial success, I have learned a lot, and got a degree. Learning a lot is the main point of writing a diploma thesis, so it was a tremendous success. The b16, on the other hand, was an almost-instant commercial success for the company I worked for. Idiots like gavino want to buy it as Firefox browser PC (Firefox already has enough Forth in it to qualify as a Forth success story), but the b16's intent is deeply embedded controlling stuff inside a chip. I don't know how much progress the company made where I last used the b16 at, but the plan was to eventually have it in every iPod and iOS device as battery monitor. While I was there, the managers were scared by the CPU (and me, and the customer, and everything, the climate of fear was horrible), and constantly considered ARM Cortex M0s (though it was way too large and expensive); after I left and some other guys were forced to take over, the reluctance declined considerably. Stack processors are alien and unknown, and that's the main reason for rejecting to use them. >> C compilers had just reached the point of >> unmaintainability, i.e. the point where further progress is almost >> impossible or at least requires to start over from scratch. > > Now, that's an interesting an claim. I'm sure the list of reasons > would be interesting, to me, or, at least, amusing. Why should I go down to your level of discussion? You will definitely beat me with your experince of being an idiot, being subtle offensive, and misunderstand everything I write. I should rather keep you in my killfile. You could instead look at the history of GCC development, which at that time struggled under Kenner, was forked to EGCS, and the maintainers of EGCS struggled for years to get things into GCC which had been state of the art, like SSA-trees. And it's not just GCC: llvm has exactly the same problems; the code llvm now generates for Gforth remind me on the 3.x series of GCC, and while GCC 4.x generates better code than llvm, it has not fully recovered. They now try to change language (move to C++) in GCC, but llvm is already written in C++; it doesn't really help. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-10-15 07:01 -0700 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <1cc2931a-f2f9-44a4-b7ed-2a271604f12c@o8g2000yqh.googlegroups.com> |
| In reply to | #16294 |
Bernd: > Commercial failures: yes, sort-of (RTX made profits, especially with the > radiation-harded RTX2000). Technical failures: not really. I'm inclined to agree. The figures shown in the Koopman book that I have show stack based processors (at that time, based on the technology and production processes of that time) to be faster at just about everything (IIRC) than 'conventional' processors. For some reason, they just didn't get any traction. Maybe it just about where the investment/R&D dollars are, not the technology per-se. I guess they were just 'too different'. Perhaps it's considered too difficult to write code that operates on a stack (where access to data is constrained by the order in which it is on the stack) as opposed to code that accesses data via registers (essentially random access). Personally, I don't find it particularly difficult, and I'm sure I'd take to writing 'Forth assembly' like a duck to water. I think the world missed a good opportunity. There was a chance to explore an avenue of processor design where processors could have perhaps been an order of magnitude less complex, with the payoffs in performance and power consumption that that brings. Instead, we seemed to go down the "the more complex the better" route.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-15 09:31 -0700 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <7xtxtvofxl.fsf@ruckus.brouhaha.com> |
| In reply to | #16295 |
Mark Wills <forthfreak@gmail.com> writes: > Perhaps it's considered too difficult to write code that operates on a > stack (where access to data is constrained by the order in which it is > on the stack) as opposed to code that accesses data via registers > (essentially random access). Stack processors including Chuck's have added registers to deal with the insufficiency of pure stacks for implementing useful code. Without the registers you end up having to use memory to hold temporary or other very frequently accessed values. In the F18's case, a memory access burns several instruction slots (because the memory address is in the program stream) plus the access itself is several times slower than a stack or register operation. Koopman's book at least for some sections assumed instructions to get at deeper levels of the stack than the top element, but in that case it's not really a pure stack machine. > Personally, I don't find it particularly difficult, and I'm sure I'd > take to writing 'Forth assembly' like a duck to water. The usefulness of local variables in practical Forth shows that there's occasionally too much live data to do everything on the stack. In interpreted Forths where the stack itself is also in memory, or in compiled Forths where stack and local accesses end up using registers, this works out ok. In stack hardware where locals and memory are 10x(?) slower than stack accesses, overall program performance probably suffers. > I think the world missed a good opportunity. There was a chance to > explore an avenue of processor design where processors could have > perhaps been an order of magnitude less complex, with the payoffs in > performance and power consumption that that brings. Instead, we seemed > to go down the "the more complex the better" route. "order of magnitude" sounds pretty dubious even for very simple processors. Chuck's F18 has around 7000 transistors (I guess that doesn't count the memory arrays) and I think this is comparable to the classic 8-bit micros that were sort of similar in capability. I could accept that the F18's performance is X percent better for some moderate X, but I don't believe 10 times better.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-15 19:51 +0200 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <1491587.ihVW1S9S1V@sunwukong.fritz.box> |
| In reply to | #16298 |
Paul Rubin wrote: > Mark Wills <forthfreak@gmail.com> writes: >> Perhaps it's considered too difficult to write code that operates on >> a stack (where access to data is constrained by the order in which it >> is on the stack) as opposed to code that accesses data via registers >> (essentially random access). > > Stack processors including Chuck's have added registers to deal with > the insufficiency of pure stacks for implementing useful code. Chuck has an A and B register, which are hard-coded in the instructions that use them (i.e. they are not general purpose registers); they are used as pointers into memory. The Transputer (which had a very shallow stack) had its workspace, a pointer into the fast on-chip SRAM which could be used with small indices (the pointer could point anywhere, but it usually pointed into the small SRAM). The workspace has been used for local variables, and moving the pointer made call/returns quick. Such a workspace pointer plus a suitable way of caching the memory underneath it could also work quite well for OOP - you keep your current object close to the CPU, and access its members quickly. You probably need two of them in that case - one for the locals, one for the current object. > Without > the registers you end up having to use memory to hold temporary or > other very frequently accessed values. Yes. AFAIK about 1/3 of all operations are memory accesses, and that's not just the programs I write; this equation holds true even when you have enough registers for your locals. > In the F18's case, a memory access > burns several instruction slots (because the memory address is in the > program stream) plus the access itself is several times slower than a > stack or register operation. Which is more related to Chuck's inexperience in designing memories. The small memory I used for the TSMC 180nm process had an access time of <2ns (worst case, IIRC). My recommendation is to have a small and fast SRAM memory for these values, and a larger memory for the program - the program access is sequential, and prefetching can hide most of the latency. > Koopman's book at least for some sections assumed instructions to get > at deeper levels of the stack than the top element, but in that case > it's not really a pure stack machine. And it makes the stack slow, as well. The stack is ultra-fast, *because* you directly can only access TOS and NOS, and nothing else. >> Personally, I don't find it particularly difficult, and I'm sure I'd >> take to writing 'Forth assembly' like a duck to water. > > The usefulness of local variables in practical Forth shows that > there's > occasionally too much live data to do everything on the stack. In > interpreted Forths where the stack itself is also in memory, or in > compiled Forths where stack and local accesses end up using registers, > this works out ok. In stack hardware where locals and memory are > 10x(?) slower than stack accesses, overall program performance > probably suffers. There's no need to make your memory access *that* slow. Single-cycle for a small SRAM is easily doable. You need something like the Transputer's workspace to be fast: a pointer register, and a bunch of instructions that fetch and store words at small offsets relative to this register. In Gforth's VM, we have something similar: The local stack is a register, and a few primitives are dedicated to access the first few locals directly. We have decided for four integer locals and two floating point locals (only fetchs, no stores, as the preferred programming model with Gforth locals is to assign once, and that's done with a >l, a move to the local stack). >> I think the world missed a good opportunity. There was a chance to >> explore an avenue of processor design where processors could have >> perhaps been an order of magnitude less complex, with the payoffs in >> performance and power consumption that that brings. Instead, we >> seemed to go down the "the more complex the better" route. > > "order of magnitude" sounds pretty dubious even for very simple > processors. Chuck's F18 has around 7000 transistors (I guess that > doesn't count the memory arrays) 64 words by 16 bits by 6 transistors for an SRAM cell would be already 6k transistors, so it must be without memory arrays, but probably including stacks. > and I think this is comparable to the > classic 8-bit micros that were sort of similar in capability. I could > accept that the F18's performance is X percent better for some > moderate X, but I don't believe 10 times better. The classic 8-bit micros are really slow, especially since you needed 16 bit operations (which are then two 8 bit operations or more) quite often. They also all needed several cycles or phases for one instruction - typically 4 phases minimum. Going to a 1 cycle 16 bit design gives an order of magnitude. The early Forth processors like the Novix or RTX often crammed more than a single Forth instruction into one instruction word, so they were faster per clock as the F18. 8 bit processors, especially the very popular 8051 have seen modern single- or two-cycle implementations, but they are a lot larger than 7k transistors. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-15 17:47 -0400 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <k5i09i$uor$1@dont-email.me> |
| In reply to | #16300 |
On 10/15/2012 1:51 PM, Bernd Paysan wrote: > Paul Rubin wrote: > >> In the F18's case, a memory access >> burns several instruction slots (because the memory address is in the >> program stream) plus the access itself is several times slower than a >> stack or register operation. > > Which is more related to Chuck's inexperience in designing memories. > The small memory I used for the TSMC 180nm process had an access time of > <2ns (worst case, IIRC). My recommendation is to have a small and fast > SRAM memory for these values, and a larger memory for the program - the > program access is sequential, and prefetching can hide most of the > latency. Chuck's chip does prefetching of the opcodes. How can you prefetch an operand when the address register just changed in the instruction preceding the memory access? >> Koopman's book at least for some sections assumed instructions to get >> at deeper levels of the stack than the top element, but in that case >> it's not really a pure stack machine. > > And it makes the stack slow, as well. The stack is ultra-fast, > *because* you directly can only access TOS and NOS, and nothing else. I think technically you can only access TOS in a true stack. Typically the TOS and often the NOS are implemented in registers with a stack behind them, that is how Chuck does it in the F18A. > 64 words by 16 bits by 6 transistors for an SRAM cell would be already > 6k transistors, so it must be without memory arrays, but probably > including stacks. This makes me wonder if there is too much emphasis on keeping the CPU small and a larger RAM would not be hard at all with little impact on the CPU speed. There is small and there is tiny. I believe most processors end up with half the die or more as RAM/cache. That's not all bad. Actually I'd like to see blocks of RAM like they have in FPGAs. But that would break the regularity of the design which I'm sure is not desired much by the developers (I say that instead of Chuck because I'm led to believe there are other designers involved, but who knows at what level). >> and I think this is comparable to the >> classic 8-bit micros that were sort of similar in capability. I could >> accept that the F18's performance is X percent better for some >> moderate X, but I don't believe 10 times better. > > The classic 8-bit micros are really slow, especially since you needed 16 > bit operations (which are then two 8 bit operations or more) quite > often. They also all needed several cycles or phases for one > instruction - typically 4 phases minimum. Going to a 1 cycle 16 bit > design gives an order of magnitude. The early Forth processors like the > Novix or RTX often crammed more than a single Forth instruction into one > instruction word, so they were faster per clock as the F18. > > 8 bit processors, especially the very popular 8051 have seen modern > single- or two-cycle implementations, but they are a lot larger than 7k > transistors. 8051 is a poor example. Other 8 bit processors have much better designs and are far from large. But they typically aren't done in current process technology because they need low power, higher I/O voltages and don't need to run any faster than the Flash. With today's technology I don't see the point of keeping a design to 7 k transistors when that lets you put some 50-60 times the number of processors on the same size die as the GA144. So maybe you need 20 times more processors and more on chip memory... or maybe no more processors and more on chip memory? I get tired of thinking about the GA144 sometimes. A manager once told me (back when I was very young) that I had raw talent (with a BIG emphasis on RAW). That is the GA144, a chip with lots of RAW potential. Who knows if it will ever be developed? Rick
[toc] | [prev] | [next] | [standalone]
| From | Syd Rumpo <usenet@nononono.co.uk> |
|---|---|
| Date | 2012-10-16 11:10 +0100 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <k5jbr0$krh$1@dont-email.me> |
| In reply to | #16312 |
On 15/10/2012 22:47, rickman wrote: > On 10/15/2012 1:51 PM, Bernd Paysan wrote: >> Paul Rubin wrote: <snip> >>> Koopman's book at least for some sections assumed instructions to get >>> at deeper levels of the stack than the top element, but in that case >>> it's not really a pure stack machine. >> >> And it makes the stack slow, as well. The stack is ultra-fast, >> *because* you directly can only access TOS and NOS, and nothing else. > > I think technically you can only access TOS in a true stack. Typically > the TOS and often the NOS are implemented in registers with a stack > behind them, that is how Chuck does it in the F18A. The PSC1000 allowed access to IIRC the top 15 return stack elements. That means you can push locals on to it and then use r7@ r7! etc as appropriate. There was a multiple rdrop instruction for tidying up afterwards. In practice, with real code, I found this a very useful idea. <snipped ad lib> > I get tired of thinking about the GA144 sometimes. Yes. It's frustrating to have something available with such great potential, yet not be able to think of an application which couldn't be done better in some other way. Maybe (heresy!) it's a dud. The RTX2000s were great, the PSC1000 was great too, technically. Several FPGA stack machines look to be very useful, but maybe the GA144 is just backed too far into a niche. Cheers -- Syd
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-16 15:55 -0400 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <k5ke41$5pj$1@dont-email.me> |
| In reply to | #16340 |
On 10/16/2012 6:10 AM, Syd Rumpo wrote: > On 15/10/2012 22:47, rickman wrote: >> On 10/15/2012 1:51 PM, Bernd Paysan wrote: >>> Paul Rubin wrote: > > <snip> > >>>> Koopman's book at least for some sections assumed instructions to get >>>> at deeper levels of the stack than the top element, but in that case >>>> it's not really a pure stack machine. >>> >>> And it makes the stack slow, as well. The stack is ultra-fast, >>> *because* you directly can only access TOS and NOS, and nothing else. >> >> I think technically you can only access TOS in a true stack. Typically >> the TOS and often the NOS are implemented in registers with a stack >> behind them, that is how Chuck does it in the F18A. > > The PSC1000 allowed access to IIRC the top 15 return stack elements. > That means you can push locals on to it and then use r7@ r7! etc as > appropriate. There was a multiple rdrop instruction for tidying up > afterwards. > > In practice, with real code, I found this a very useful idea. > > <snipped ad lib> > >> I get tired of thinking about the GA144 sometimes. > > Yes. It's frustrating to have something available with such great > potential, yet not be able to think of an application which couldn't be > done better in some other way. I don't agree with this. I have said many times that I think it can make a very good digital receiver (SDR) because of being so like an FPGA but at much lower power levels. > Maybe (heresy!) it's a dud. The RTX2000s were great, the PSC1000 was > great too, technically. Several FPGA stack machines look to be very > useful, but maybe the GA144 is just backed too far into a niche. Certainly there are any number of aspects that were not optimized for real world designs that we all have right now. I'm told this design is intended for the "Internet of Things". But in reality I think it was not "intended" for anything. It is just what happened in Chuck's head and now he is looking for how best to use it. Read his blog posts and you will see that even now he seems to have no idea how to do any number of tasks with the chip. It is all about exploring the solution space of this device. Read "The Map is not the Territory". Someone here said that about him. He is not really a product designer, he is a researcher who isn't trying to design useful stuff, rather he designs stuff and then looks for uses. Rick
[toc] | [prev] | [next] | [standalone]
| From | Syd Rumpo <usenet@nononono.co.uk> |
|---|---|
| Date | 2012-10-16 21:31 +0100 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <k5kg75$jd3$1@dont-email.me> |
| In reply to | #16354 |
On 16/10/2012 20:55, rickman wrote: > On 10/16/2012 6:10 AM, Syd Rumpo wrote: >> On 15/10/2012 22:47, rickman wrote: <snipn> >>> I get tired of thinking about the GA144 sometimes. >> >> Yes. It's frustrating to have something available with such great >> potential, yet not be able to think of an application which couldn't be >> done better in some other way. > > I don't agree with this. I have said many times that I think it can > make a very good digital receiver (SDR) because of being so like an FPGA > but at much lower power levels. Yes, I've looked at it from the FPGA standpoint, but it just doesn't have the routing flexibility and multiplies are slower than you might expect. Maybe that's fixable in the future. How far have you looked at SDR on GA144? <snipped> > Someone here said that about him. He is not really a product designer, > he is a researcher who isn't trying to design useful stuff, rather he > designs stuff and then looks for uses. Agreed, and it's an enviable place to be. That doesn't help me though, and it doesn't make GA144 viable. I wish it were otherwise. Cheers -- Syd
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-16 17:06 -0400 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <k5ki8m$13c$1@dont-email.me> |
| In reply to | #16361 |
On 10/16/2012 4:31 PM, Syd Rumpo wrote: > On 16/10/2012 20:55, rickman wrote: >> On 10/16/2012 6:10 AM, Syd Rumpo wrote: >>> On 15/10/2012 22:47, rickman wrote: > > <snipn> > >>>> I get tired of thinking about the GA144 sometimes. >>> >>> Yes. It's frustrating to have something available with such great >>> potential, yet not be able to think of an application which couldn't be >>> done better in some other way. >> >> I don't agree with this. I have said many times that I think it can >> make a very good digital receiver (SDR) because of being so like an FPGA >> but at much lower power levels. > > Yes, I've looked at it from the FPGA standpoint, but it just doesn't > have the routing flexibility and multiplies are slower than you might > expect. Maybe that's fixable in the future. How far have you looked at > SDR on GA144? I haven't gone too far with it. I was actually looking at an oscilloscope design as a way to get familiar with the device and found that Green Arrays would not provide the timing information I wanted to analyze an SDRAM interface using a clock. I wanted to paper calculate the timing from the clock input to the GA144 to signal outputs the same way I would in an FPGA. This requires knowing timing relative to the stop/start mechanism of the CPU, both on I/O and inter-processor. They would not provide that info, partly because they haven't measured it and it would be a PITA to characterize it the same way they do the rest of the timing but they also said they felt this would provide too much insight into their proprietary design. I was free, however, to buy an eval board and characterize their chips for myself. Honest, that's what they said. >> Someone here said that about him. He is not really a product designer, >> he is a researcher who isn't trying to design useful stuff, rather he >> designs stuff and then looks for uses. > > Agreed, and it's an enviable place to be. That doesn't help me though, > and it doesn't make GA144 viable. I wish it were otherwise. I may go back to the oscilloscope design. I don't think I can get an SDRAM interface to run any faster than 50 MHz vs. the 133 MHz the chip is designed for and I'm not certain that will work. Meanwhile I believe Chuck claims near 50 ns operation of the static RAM on the eval boards. That would be good as that is random access timing. But Chuck's timing is typically done with nop cycles which result in timing variations which have to be allowed for with timing margin. His work seems to be more of the lab type stuff rather than production orientations and he is happy if it only works with his monitor or only on cool days sort of stuff. Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-16 20:56 -0700 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <7xr4ox7nup.fsf@ruckus.brouhaha.com> |
| In reply to | #16300 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Chuck has an A and B register, which are hard-coded in the instructions > that use them (i.e. they are not general purpose registers); they are > used as pointers into memory. Register A is relatively general purpose and it is quite useful for holding temporary values. Register B is more specialized. > The Transputer (which had a very shallow stack) had its workspace, a > pointer into the fast on-chip SRAM which could be used with small That sounds sort of like SPARC register windows? I have the impression those were considered a good idea at one time but became a bottleneck later, for reasons I don't understand. >> In stack hardware where locals and memory are 10x(?) slower than >> stack accesses, overall program performance probably suffers. > There's no need to make your memory access *that* slow. Single-cycle > for a small SRAM is easily doable. It's not just the memory access itself; there's also the extra instruction cycles, and the extra memory accesses needed to get the address, plus the additional fetch to get the next word full of instructions. Maybe with faster memory it can be less than 10x but it's still a lot. > The classic 8-bit micros are really slow, especially since you needed 16 > bit operations (which are then two 8 bit operations or more) quite > often. They also all needed several cycles or phases for one > instruction - typically 4 phases minimum. Going to a 1 cycle 16 bit > design gives an order of magnitude. The F18 has several phases I'm pretty sure. And an 18-bit addition on the F18 takes two cycles (you have to insert a no-op for the ripple carry to settle, or something like that). And some 8-bitters had some 16-bit operations, though maybe not the classic ones.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-16 23:44 -0500 |
| Subject | Re: mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd? |
| Message-ID | <l-idnbOtB7U8quPNnZ2dnUVZ8t-dnZ2d@supernews.com> |
| In reply to | #16371 |
Paul Rubin <no.email@nospam.invalid> wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >> The Transputer (which had a very shallow stack) had its workspace, a >> pointer into the fast on-chip SRAM which could be used with small > > That sounds sort of like SPARC register windows? No, the workspace pointer just pointed to the local frame. Local variables were at small offsets from the workspace pointer. This made for very fast context switches: it just had to save the program counter in your workspace, swap the workspace pointer, and restore the program counter. This was done with a simple round robin; there was no other context to save and restore. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-10-17 10:01 +0000 |
| Subject | Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <507e8204$0$3150$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #16373 |
In article <l-idnbOtB7U8quPNnZ2dnUVZ8t-dnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>
>>> The Transputer (which had a very shallow stack) had its workspace, a
>>> pointer into the fast on-chip SRAM which could be used with small
>>
>> That sounds sort of like SPARC register windows?
>
>No, the workspace pointer just pointed to the local frame. Local
>variables were at small offsets from the workspace pointer. This made
>for very fast context switches: it just had to save the program
>counter in your workspace, swap the workspace pointer, and restore the
>program counter. This was done with a simple round robin; there was
>no other context to save and restore.
And may I add to this, the lowest 16 in the workspace were really registers.
A register to register move r4-r5 would be two bytes
ldl 4
stl 5
Comparable in speed and code density with the 30386 of the time.
But look what happens if you need 17 registers! Nothing much.
The ldl 4 will take one more byte.
What happens if you run out of registers on the 80386?
head scratching and a total redesign.
I have done my twin prime counting attempt totally in transputer
(Forth macro) assembly. Smooth.
>
>Andrew.
Groetjes Albert
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-17 21:11 -0500 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <AJydnU63XsXO-OLNnZ2dnUVZ7sSdnZ2d@supernews.com> |
| In reply to | #16379 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <l-idnbOtB7U8quPNnZ2dnUVZ8t-dnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> >>No, the workspace pointer just pointed to the local frame. Local >>variables were at small offsets from the workspace pointer. This made >>for very fast context switches: it just had to save the program >>counter in your workspace, swap the workspace pointer, and restore the >>program counter. This was done with a simple round robin; there was >>no other context to save and restore. > > And may I add to this, the lowest 16 in the workspace were really registers. Gosh, are you sure? This would make for horrendous context switch times. I don't remember this. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-10-18 01:08 -0700 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <ce7ce1b4-b117-436e-813d-91dec41b4458@k6g2000vbr.googlegroups.com> |
| In reply to | #16419 |
On Oct 18, 3:11 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > > > In article <l-idnbOtB7U8quPNnZ2dnUVZ8t-dn...@supernews.com>, > > Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > > >>No, the workspace pointer just pointed to the local frame. Local > >>variables were at small offsets from the workspace pointer. This made > >>for very fast context switches: it just had to save the program > >>counter in your workspace, swap the workspace pointer, and restore the > >>program counter. This was done with a simple round robin; there was > >>no other context to save and restore. > > > And may I add to this, the lowest 16 in the workspace were really registers. > > Gosh, are you sure? This would make for horrendous context switch > times. I don't remember this. > > Andrew. TMS9900 and derivatives have worked like this since 1976. It's a brilliant system, though it didn't catch on. It means you can have as many registers as you want, effectively. Subroutines can have their own set of registers, with no need to push/pop data/from a stack before/after subroutine calls. Love it.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web