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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-18 11:42 -0500 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <HtOdncKKIJIfrB3NnZ2dnUVZ8q6dnZ2d@supernews.com> |
| In reply to | #16424 |
Mark Wills <forthfreak@gmail.com> wrote: > 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. > > 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. But they're not registers, they're RAM, aren't they? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-18 15:26 -0400 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <k5pl5s$9mn$1@dont-email.me> |
| In reply to | #16433 |
On 10/18/2012 12:42 PM, Andrew Haley wrote: > Mark Wills<forthfreak@gmail.com> wrote: >> 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. >> >> 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. > > But they're not registers, they're RAM, aren't they? > > Andrew. You are missing the point. The workspace pointer points to *any* 16 locations in RAM. So to change context you just update the pointer. The TMS9900 used this for the 16 registers. When this was initially done on their minicomputers the CPU didn't operate faster than external RAM (which is all there was), so there was no performance penalty. But that had already changed by the time they made the microprocessor chip. It was only a few more years until it became popular to include memory on chip and the MCU was born. Again, a few years later and even on chip memory was not fast enough to keep up with the processor, at least for Flash! Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-10-18 09:25 +0000 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <507fcaf8$0$3117$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #16419 |
In article <AJydnU63XsXO-OLNnZ2dnUVZ7sSdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >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. The context switch time is very short. The workspace pointer points to a registerset in on-chip RAM. That is what I try to explain. Allthough they are mapped regularly in the memory space, they are for all intents and purposes registers. > >Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-18 11:46 -0500 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <HtOdnf2KIJL4rx3NnZ2dnUVZ8q6dnZ2d@supernews.com> |
| In reply to | #16428 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <AJydnU63XsXO-OLNnZ2dnUVZ7sSdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>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. > > The context switch time is very short. The workspace pointer points > to a registerset in on-chip RAM. That is what I try to explain. > Allthough they are mapped regularly in the memory space, they are for > all intents and purposes registers. Of course, you can point the workspace at the Transputer's internal memory, but that's not registers, it's still RAM. I's wrong to say they were "really registers": they were just offsets from a pointer, just like most processors can use indexed addressing to access locals. Andrew
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-18 15:28 -0400 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <k5pl9m$9mn$2@dont-email.me> |
| In reply to | #16435 |
On 10/18/2012 12:46 PM, Andrew Haley wrote: > Albert van der Horst<albert@spenarnc.xs4all.nl> wrote: >> In article<AJydnU63XsXO-OLNnZ2dnUVZ7sSdnZ2d@supernews.com>, >> Andrew Haley<andrew29@littlepinkcloud.invalid> wrote: >>> 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. >> >> The context switch time is very short. The workspace pointer points >> to a registerset in on-chip RAM. That is what I try to explain. >> Allthough they are mapped regularly in the memory space, they are for >> all intents and purposes registers. > > Of course, you can point the workspace at the Transputer's internal > memory, but that's not registers, it's still RAM. I's wrong to say > they were "really registers": they were just offsets from a pointer, > just like most processors can use indexed addressing to access locals. But they were addressed as registers, IIRC. At least in the TMS9900 they were. MOV R1, R11. No need to specify the address in memory. Don't get hung up on the internal RAM not being "registers". What is the register file other than a small RAM? Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-10-18 12:44 -0700 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <a2628431-5ccd-445c-8559-7a3bda72915d@o30g2000vbu.googlegroups.com> |
| In reply to | #16453 |
On Oct 18, 8:28 pm, rickman <gnu...@gmail.com> wrote: > On 10/18/2012 12:46 PM, Andrew Haley wrote: > > > > > > > > > > > Albert van der Horst<alb...@spenarnc.xs4all.nl> wrote: > >> In article<AJydnU63XsXO-OLNnZ2dnUVZ7sSdn...@supernews.com>, > >> 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. > > >> The context switch time is very short. The workspace pointer points > >> to a registerset in on-chip RAM. That is what I try to explain. > >> Allthough they are mapped regularly in the memory space, they are for > >> all intents and purposes registers. > > > Of course, you can point the workspace at the Transputer's internal > > memory, but that's not registers, it's still RAM. I's wrong to say > > they were "really registers": they were just offsets from a pointer, > > just like most processors can use indexed addressing to access locals. > > But they were addressed as registers, IIRC. At least in the TMS9900 > they were. MOV R1, R11. No need to specify the address in memory. > > Don't get hung up on the internal RAM not being "registers". What is > the register file other than a small RAM? > > Rick That's correct. When you understand that your registers are really just pointing to RAM you can take advantage of it... For example, you can load your registers with op-codes and "Branch" to (say) R0, which sounds weird, but internally, you're just branching to the base address of the workspace pointer. Then your 'code in registers' can modify itself by the very fact that it's in a registers! It's the future, you know! ;-)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-18 18:49 -0500 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <opudnaz2_PIXCB3NnZ2dnUVZ8sednZ2d@supernews.com> |
| In reply to | #16453 |
rickman <gnuarm@gmail.com> wrote: > On 10/18/2012 12:46 PM, Andrew Haley wrote: >> Albert van der Horst<albert@spenarnc.xs4all.nl> wrote: >>> In article<AJydnU63XsXO-OLNnZ2dnUVZ7sSdnZ2d@supernews.com>, >>> Andrew Haley<andrew29@littlepinkcloud.invalid> wrote: >>>> 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. >>> >>> The context switch time is very short. The workspace pointer points >>> to a registerset in on-chip RAM. That is what I try to explain. >>> Allthough they are mapped regularly in the memory space, they are for >>> all intents and purposes registers. >> >> Of course, you can point the workspace at the Transputer's internal >> memory, but that's not registers, it's still RAM. I's wrong to say >> they were "really registers": they were just offsets from a pointer, >> just like most processors can use indexed addressing to access locals. > > But they were addressed as registers, IIRC. At least in the TMS9900 > they were. MOV R1, R11. No need to specify the address in memory. Yabbut, registers are a physical thing in silicon. In the 9900 you have general-purpose memory that can be addressed as though it were registers, sure. > Don't get hung up on the internal RAM not being "registers". What is > the register file other than a small RAM? I see your point, but a register array is a separate thing from the RAM, usually placed closer to the ALU with a fast data path to it. Sure, it made sense to do things the 9900 way when the speeds of an ALU and memory were similar, but main memory isn't registers no matter how you address it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-18 20:16 -0400 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <k5q65a$ikd$1@dont-email.me> |
| In reply to | #16465 |
On 10/18/2012 7:49 PM, Andrew Haley wrote: > rickman<gnuarm@gmail.com> wrote: >> >> But they were addressed as registers, IIRC. At least in the TMS9900 >> they were. MOV R1, R11. No need to specify the address in memory. > > Yabbut, registers are a physical thing in silicon. In the 9900 you > have general-purpose memory that can be addressed as though it were > registers, sure. > >> Don't get hung up on the internal RAM not being "registers". What is >> the register file other than a small RAM? > > I see your point, but a register array is a separate thing from the > RAM, usually placed closer to the ALU with a fast data path to it. > Sure, it made sense to do things the 9900 way when the speeds of an > ALU and memory were similar, but main memory isn't registers no matter > how you address it. > > Andrew. I still don't get your concern. Once you put the RAM on chip and it is accessed in a single cycle, what is the difference with other on chip registers? Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-18 17:28 -0700 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <7xipa7tie3.fsf@ruckus.brouhaha.com> |
| In reply to | #16468 |
rickman <gnuarm@gmail.com> writes: > I still don't get your concern. Once you put the RAM on chip and it > is accessed in a single cycle, what is the difference with other on > chip registers? The amount of stuff between the ALU and memory (specifically, that address arithmetic rather than a simple demultiplexer used for registers) might slow down the cycle (decrease obtainable clock frequency), perhaps.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-19 03:00 +0200 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <2518045.FbL8GnYMY6@sunwukong.fritz.box> |
| In reply to | #16469 |
Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I still don't get your concern. Once you put the RAM on chip and it >> is accessed in a single cycle, what is the difference with other on >> chip registers? > > The amount of stuff between the ALU and memory (specifically, that > address arithmetic rather than a simple demultiplexer used for > registers) might slow down the cycle (decrease obtainable clock > frequency), perhaps. Register files usually are multiported. E.g. when you have a RISC processor with opcode Ra,Rb,Rc style instructions, you need to read two registers per cycle and write one - a total of three ports (same for two-address instructions where you read-modify-write one of them, like x86 opcode Ra,Rb, which really is Ra operation Rb -> Ra). RAM is usually single-ported; sometimes you have dual-ported RAMs, though (but then, a dual-ported RAM has two r/w ports, a register file has two read ports and one write port). Does this matter? Yes, in terms of how you place the transistors around the SRAM cell that stores the information. It's probably too much details for rickman. Register files usually take more space per bit, but less general overhead - a small RAM block often is dominated by sense amplifiers, not by the actual memory; the register files also have a faster access time. I don't quite remember how Inmos implemented the register cache - though we had a visit of one of the few T9000 designers at TU Munich, and he explained quite a lot of internals in detail. They had both solutions for sliding the register window on calls and returns as switching between tasks. -- 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-19 18:00 -0400 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <k5sii6$j47$1@dont-email.me> |
| In reply to | #16470 |
On 10/18/2012 9:00 PM, Bernd Paysan wrote: > Paul Rubin wrote: > >> rickman<gnuarm@gmail.com> writes: >>> I still don't get your concern. Once you put the RAM on chip and it >>> is accessed in a single cycle, what is the difference with other on >>> chip registers? >> >> The amount of stuff between the ALU and memory (specifically, that >> address arithmetic rather than a simple demultiplexer used for >> registers) might slow down the cycle (decrease obtainable clock >> frequency), perhaps. > > Register files usually are multiported. E.g. when you have a RISC > processor with opcode Ra,Rb,Rc style instructions, you need to read two > registers per cycle and write one - a total of three ports (same for > two-address instructions where you read-modify-write one of them, like > x86 opcode Ra,Rb, which really is Ra operation Rb -> Ra). RAM is > usually single-ported; sometimes you have dual-ported RAMs, though (but > then, a dual-ported RAM has two r/w ports, a register file has two read > ports and one write port). > > Does this matter? Yes, in terms of how you place the transistors around > the SRAM cell that stores the information. It's probably too much > details for rickman. Register files usually take more space per bit, > but less general overhead - a small RAM block often is dominated by > sense amplifiers, not by the actual memory; the register files also have > a faster access time. > Talk to TI. They have been producing DSPs with multi-ported, on chip memory for decades. Seems that is the only useful way to do DSP. Oh, and these processors weren't limited to the few dozen MHz that many ARM devices with on chip memory are. They run at 100's of MHz. And these are the small, low power DSPs that are in nearly every cell phone made. Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-10-19 11:35 +0000 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <50813b19$0$3524$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #16465 |
In article <opudnaz2_PIXCB3NnZ2dnUVZ8sednZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >rickman <gnuarm@gmail.com> wrote: > >> Don't get hung up on the internal RAM not being "registers". What is >> the register file other than a small RAM? > >I see your point, but a register array is a separate thing from the >RAM, usually placed closer to the ALU with a fast data path to it. >Sure, it made sense to do things the 9900 way when the speeds of an >ALU and memory were similar, but main memory isn't registers no matter >how you address it. Dogmatic. I take the view of a transputer assembler programmer. > >Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-19 10:33 -0500 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <ZeWdnQ0C6dZQ7xzNnZ2dnUVZ8hKdnZ2d@supernews.com> |
| In reply to | #16490 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <opudnaz2_PIXCB3NnZ2dnUVZ8sednZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>rickman <gnuarm@gmail.com> wrote: >> >>> Don't get hung up on the internal RAM not being "registers". What is >>> the register file other than a small RAM? >> >>I see your point, but a register array is a separate thing from the >>RAM, usually placed closer to the ALU with a fast data path to it. >>Sure, it made sense to do things the 9900 way when the speeds of an >>ALU and memory were similar, but main memory isn't registers no matter >>how you address it. > > Dogmatic. I take the view of a transputer assembler programmer. So do I, and I can't see the difference between a load of local N on a Transputer and a load of Offset N from the frame pointer on, say, an ARM. It's the same action, physically and logically. Also, calling RAM "registers" obscures a distinction between the T9, which really did have a register cache for the workspace and the T8, which didn't. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-18 18:35 +0200 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <3439534.QfBpbz8j35@sunwukong.fritz.box> |
| In reply to | #16419 |
Andrew Haley wrote: >> 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. Later transputers like the T9000 (the never-ending prototype, which killed Inmos) and the ST20 used a "workspace cache", which was mostly a register file. So when you switched context, there was a bit of a slowdown to warm up that cache. -- 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 | 2012-10-18 12:06 -0500 |
| Subject | Re: Transputers, was Re: mr paysan .. gavinoshit |
| Message-ID | <HtOdnfyKIJKbqh3NnZ2dnUVZ8q6dnZ2d@supernews.com> |
| In reply to | #16431 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >>> 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. > > Later transputers like the T9000 (the never-ending prototype, which > killed Inmos) and the ST20 used a "workspace cache", which was mostly a > register file. So when you switched context, there was a bit of a > slowdown to warm up that cache. Thanks, that's what I was thinking of. So, the T8 series (which I used) didn't have workspace in registers, but T9 did. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-17 13:23 -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 | <k5mpi3$v2a$1@dont-email.me> |
| In reply to | #16371 |
On 10/16/2012 11:56 PM, Paul Rubin wrote: > 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. Neither A or B are "general" registers. The only difference is register B can only be written while A can be read or written. Each can be the address for memory accesses. There are no other operations supported. So they aren't even "relatively" general. >> 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. No, register windows are accessed as registers. The Transputer on chip RAM is just that RAM that is on chip to be faster. It is addressed like RAM, not registers. But there isn't much reason to compare a Transputer to a SPARC. I don't think there were many SPARCs used as embedded processors while nearly all Transputers were such. The SPARC architecture was intended for desktop use. >>> 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. In the GA144 with on chip RAM a memory access using register addressing there is a 3x difference in speed compared to stack operations. But that is just to load/store the memory word you still need to do the operation from the stack. If the address is immediate, a fetch from program space is needed taking another 3x plus the additional time for the disrupted instruction prefetch. So conservatively say it is then 7x slower than the operation with data on the stack. But the data has to get to the stack somehow. The question is whether the data started on the stack or not. >> 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. No, there are no "phases" for the F18A, it is an async processor. There is no clock even. There are just instruction timings. The carry propagation for an add take the same time as two "basic" opcode cycles, but that is from the time the operands on the stack are stable. If there is another instruction that doesn't disturb the stack just before the + then the carry has had time to propagate. The + instruction always executes in the same time, you just have to provide time for the carry to propagate. Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-17 11:58 -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 | <7xr4oxdixz.fsf@ruckus.brouhaha.com> |
| In reply to | #16395 |
rickman <gnuarm@gmail.com> writes: > Neither A or B are "general" registers. The only difference is > register B can only be written while A can be read or written. Each > can be the address for memory accesses. There are no other operations > supported. So they aren't even "relatively" general. A is general relative to B in the sense that you can store temporary values in A and read them back. Obviously it's a stack processor and there's no "add register to register" or anything like that. > No, register windows are accessed as registers. The Transputer on > chip RAM is just that RAM that is on chip to be faster. That sounds like a good simple method, though these days larger cpu's have caches for what I guess is the same purpose. > If the address is immediate ... conservatively say it is then 7x > slower than the operation with data on the stack. Right, this is the case of reading or storing a variable. Of course to address through A or B, you have to first load the register, which (depending) might or might not count. > No, there are no "phases" for the F18A, it is an async processor. > There is no clock even. I thought I saw in some other posts that the GA is async only in the sense that the different cpu nodes are clocked independently of each other. But each node has its own clock (ring oscillator) that puts out several pulses (phases) for each instruction executed, and the different steps happening inside an instruction are synchronized by those pulses.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-17 15:22 -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 | <k5n0h4$esk$1@dont-email.me> |
| In reply to | #16401 |
On 10/17/2012 2:58 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> Neither A or B are "general" registers. The only difference is >> register B can only be written while A can be read or written. Each >> can be the address for memory accesses. There are no other operations >> supported. So they aren't even "relatively" general. > > A is general relative to B in the sense that you can store temporary > values in A and read them back. Obviously it's a stack processor and > there's no "add register to register" or anything like that. Yes, but that is the point. It is a special purpose register for addressing memory. If you have general purpose registers that would be very outside the idea of a stack machine. >> No, register windows are accessed as registers. The Transputer on >> chip RAM is just that RAM that is on chip to be faster. > > That sounds like a good simple method, though these days larger cpu's > have caches for what I guess is the same purpose. Some others were talking about a "workspace" which I didn't remember. I guess that was pointed to in memory and typically was in the on chip memory. >> If the address is immediate ... conservatively say it is then 7x >> slower than the operation with data on the stack. > > Right, this is the case of reading or storing a variable. Of course to > address through A or B, you have to first load the register, which > (depending) might or might not count. Exactly, if the address is already in the register (such as being calculated as in an array) then the access is the slightly faster number. >> No, there are no "phases" for the F18A, it is an async processor. >> There is no clock even. > > I thought I saw in some other posts that the GA is async only in the > sense that the different cpu nodes are clocked independently of each > other. But each node has its own clock (ring oscillator) that puts out > several pulses (phases) for each instruction executed, and the different > steps happening inside an instruction are synchronized by those pulses. That is the nonesense that some people will post, but the instruction timings vary widely depending on the instruction, prefetch and other aspects and they are not integer multiples indicating that there is a processor self clock that runs machine cycles or anything like that. The F18A nodes are async processors in every sense of the word. Some people just like to speculate about the internal structure. Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-17 21:53 +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 | <2167252.KuYiSqAroK@sunwukong.fritz.box> |
| In reply to | #16402 |
rickman wrote: > That is the nonesense that some people will post, but the instruction > timings vary widely depending on the instruction, prefetch and other > aspects and they are not integer multiples indicating that there is a > processor self clock that runs machine cycles or anything like that. > The F18A nodes are async processors in every sense of the word. Some > people just like to speculate about the internal structure. Which is something Chuck did talk about 11 years ago on EuroForth when he presented the c18, the precesessor of the F18A. And which matches the fact that all basic ALU and stack operations do take exactly the same amount of time. The structure, as far as I understood Chuck, is a ring oscillator, which is stopped when something is "not ready", and there are a few ready signals, from the prefetcher, from memory accesses, from the IOs. These ready signals have their own delay, which is *not* a multiple of some clock (the clock is *stopped* while waiting). The speculative part is that Chuck kept the architecture from the c18, which is not that far- fetched. Nowadays, they don't talk that open about internals anymore. Maybe spoiled by the patent trolls. -- 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-17 16:00 -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 | <k5n2pd$ui8$1@dont-email.me> |
| In reply to | #16405 |
On 10/17/2012 3:53 PM, Bernd Paysan wrote: > rickman wrote: >> That is the nonesense that some people will post, but the instruction >> timings vary widely depending on the instruction, prefetch and other >> aspects and they are not integer multiples indicating that there is a >> processor self clock that runs machine cycles or anything like that. >> The F18A nodes are async processors in every sense of the word. Some >> people just like to speculate about the internal structure. > > Which is something Chuck did talk about 11 years ago on EuroForth when > he presented the c18, the precesessor of the F18A. And which matches > the fact that all basic ALU and stack operations do take exactly the > same amount of time. > > The structure, as far as I understood Chuck, is a ring oscillator, which > is stopped when something is "not ready", and there are a few ready > signals, from the prefetcher, from memory accesses, from the IOs. These > ready signals have their own delay, which is *not* a multiple of some > clock (the clock is *stopped* while waiting). The speculative part is > that Chuck kept the architecture from the c18, which is not that far- > fetched. Yes, you like the ring oscillator name, but in reality this is just a delay line matched to the delay of the ALU. Likewise the other paths all have matched delay lines, all of which, if in use, must indicate ready for the CPU to proceed. You even say this yourself when you say, "These ready signals have their own delay". The point is that these delay lines are all different, their timings all vary with PVT and they are all independent, not a function of any clock. Unless you have the design in your hands, anything else is speculation, but of more importance, doesn't add anything to the understanding of the CPU. 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