Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #5640 > unrolled thread
| Started by | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| First post | 2012-01-31 03:18 -0600 |
| Last post | 2012-02-09 19:11 +0100 |
| Articles | 20 on this page of 395 — 40 participants |
Back to article view | Back to comp.arch
M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-01-31 03:18 -0600
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-01-31 15:49 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-01-31 09:48 -0800
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-01-31 22:20 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-01-31 10:15 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-03 15:49 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-03 12:44 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-01 12:49 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-01 08:02 -0800
Re: M68k add to memory is not a mistake any more sarr.blumson@alum.dartmouth.org - 2012-02-01 16:18 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-01 16:53 +0000
Re: M68k add to memory is not a mistake any more Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-01 12:54 -0700
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-02 21:01 -0600
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-02 16:41 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-02 22:47 +0000
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-03 14:57 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-03 10:21 -0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-03 10:25 -0800
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-03 12:48 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-07 12:02 -0500
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-07 13:07 -0600
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-07 14:58 -0500
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-07 17:25 -0600
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-07 22:42 -0600
Re: M68k add to memory is not a mistake any more Brian Drummond <brian@shapes.demon.co.uk> - 2012-02-08 10:31 +0000
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-08 14:12 -0600
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-08 14:00 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-09 11:45 -0800
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-08 13:25 -0600
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-07 14:21 -0600
Re: M68k add to memory is not a mistake any more Stefan Monnier <monnier@iro.umontreal.ca> - 2012-02-02 16:46 -0500
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-03 16:00 +0000
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-03 16:12 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-03 17:19 +0000
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-03 17:25 +0000
Re: M68k add to memory is not a mistake any more jacko <jackokring@gmail.com> - 2012-02-01 05:31 -0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-01 10:21 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-01 19:16 +0000
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-01 13:34 -0600
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-07 17:08 -0500
Re: M68k add to memory is not a mistake any more Anne & Lynn Wheeler <lynn@garlic.com> - 2012-02-01 14:50 -0500
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-02 02:07 -0600
Re: M68k add to memory is not a mistake any more Piotr Wyderski <peter.pan@neverland.mil> - 2012-02-06 10:50 +0100
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-02 12:30 -0800
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-02 02:03 -0600
Re: M68k add to memory is not a mistake any more nospam@ab-katrinedal.dk (Niels Jørgen Kruse) - 2012-02-02 16:15 +0100
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-02 20:53 -0600
Re: M68k add to memory is not a mistake any more Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-02 11:16 -0700
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-02 23:10 -0600
Re: M68k add to memory is not a mistake any more Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-02 23:54 -0700
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-12 11:42 -0600
Re: M68k add to memory is not a mistake any more Chris Gray <cg@GraySage.com> - 2012-02-02 17:41 -0700
Re: M68k add to memory is not a mistake any more kenney@cix.compulink.co.uk - 2012-02-03 14:23 -0600
Re: M68k add to memory is not a mistake any more Brian Drummond <brian@shapes.demon.co.uk> - 2012-02-04 10:46 +0000
Re: M68k add to memory is not a mistake any more Erik Trulsson <ertr1013@student.uu.se> - 2012-02-06 08:57 +0000
Re: M68k add to memory is not a mistake any more "Marven Lee" <marven10@gmail.com> - 2012-02-06 13:12 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-06 14:07 +0000
Re: M68k add to memory is not a mistake any more Nick Garnett <nickg@calivar.com> - 2012-02-06 14:29 +0000
Re: M68k add to memory is not a mistake any more "Marven Lee" <marven10@gmail.com> - 2012-02-07 12:06 +0000
Re: M68k add to memory is not a mistake any more Nick Garnett <nickg@calivar.com> - 2012-02-07 17:18 +0000
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-02 15:09 -0600
4- and 5-operand instructions (was: M68k) Mark Thorson <nospam@sonic.net> - 2012-02-02 17:29 -0800
Re: 4- and 5-operand instructions Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-03 07:49 +0100
Re: 4- and 5-operand instructions Mark Thorson <nospam@sonic.net> - 2012-02-03 09:36 -0800
Re: 4- and 5-operand instructions Stephen Sprunk <stephen@sprunk.org> - 2012-02-03 23:43 -0600
Re: 4- and 5-operand instructions "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-03 11:02 -0800
Re: 4- and 5-operand instructions Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-04 12:16 -0800
Re: 4- and 5-operand instructions "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-05 13:59 -0800
Re: 4- and 5-operand instructions MitchAlsup <MitchAlsup@aol.com> - 2012-02-05 14:38 -0800
Re: 4- and 5-operand instructions (was: M68k) Quadibloc <jsavard@ecn.ab.ca> - 2012-02-06 12:09 -0800
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-03 07:42 +0100
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-04 00:14 -0600
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-03 22:49 -0800
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-04 10:40 -0600
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-04 20:53 +0100
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-04 13:11 -0800
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-05 12:50 +0100
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-08 13:39 -0800
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-09 11:20 -0800
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-09 22:58 -0800
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-10 09:21 +0100
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-10 04:11 -0600
Re: M68k add to memory is not a mistake any more Eric Northup <digitaleric@gmail.com> - 2012-02-10 11:41 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-10 12:12 -0500
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-10 06:34 -0800
Re: M68k add to memory is not a mistake any more Stefan Monnier <monnier@iro.umontreal.ca> - 2012-02-10 11:01 -0500
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-10 09:46 +0100
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-10 17:20 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-11 18:29 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-11 15:35 -0800
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-12 00:47 +0100
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-04 17:56 -0600
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-05 02:17 -0600
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-05 10:53 -0800
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-05 02:20 -0600
Re: M68k add to memory is not a mistake any more nospam@ab-katrinedal.dk (Niels Jørgen Kruse) - 2012-02-05 11:31 +0100
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-05 09:34 -0600
Re: M68k add to memory is not a mistake any more nospam@ab-katrinedal.dk (Niels Jørgen Kruse) - 2012-02-05 17:06 +0100
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-05 12:06 -0500
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-05 13:04 -0600
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-05 16:43 -0500
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-06 09:57 -0600
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-05 14:10 -0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-05 13:20 -0800
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-06 13:12 +0000
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-06 09:51 -0600
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-06 15:57 +0000
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-06 17:16 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-05 12:54 +0100
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-07 00:05 +0000
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-07 17:26 -0600
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-04 04:02 -0600
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-04 10:14 -0600
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-04 09:12 -0800
Re: M68k add to memory is not a mistake any more Brett Davis <ggtgp@yahoo.com> - 2012-02-05 03:15 -0600
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-06 13:54 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-06 20:39 +0000
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-08 22:57 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-08 23:25 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-09 11:30 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-09 17:33 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-10 11:55 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-10 17:18 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-11 22:19 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-12 09:44 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-12 17:22 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-11 22:23 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-11 14:42 -0800
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-11 23:37 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-11 18:16 -0800
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-12 17:33 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-12 19:16 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-12 12:35 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-12 21:15 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-13 16:32 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-12 08:57 +0000
Re: M68k add to memory is not a mistake any more Anne & Lynn Wheeler <lynn@garlic.com> - 2012-02-09 15:52 -0500
Re: M68k add to memory is not a mistake any more "Marven Lee" <marven10@gmail.com> - 2012-02-14 11:23 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-15 13:09 -0500
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-10 22:52 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-10 17:32 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-11 09:35 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-12 23:13 -0500
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-12 20:32 -0800
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-13 08:19 +0100
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-13 08:41 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-13 08:36 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-14 09:53 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-14 09:38 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-14 18:54 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-15 04:00 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-15 08:53 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-13 09:49 -0500
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-13 12:25 -0500
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-13 15:59 -0800
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-15 16:29 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-15 08:57 -0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-15 10:29 -0800
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-16 22:06 +0000
Re: M68k add to memory is not a mistake any more John Levine <johnl@iecc.com> - 2012-02-16 22:18 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-15 12:47 -0500
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-21 00:00 +0000
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-13 15:17 -0800
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-13 16:37 -0800
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-14 03:17 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-20 23:36 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 08:53 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-21 11:07 +0100
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-21 12:25 -0500
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-21 19:13 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 11:38 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-21 16:54 -0500
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 14:39 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-21 23:23 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-22 09:29 +0100
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-22 02:27 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-22 13:04 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-22 09:14 -0800
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-22 13:19 +0000
Re: M68k add to memory is not a mistake any more Chris Gray <cg@GraySage.com> - 2012-02-22 13:41 -0700
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-22 10:28 -0500
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-22 08:32 -0800
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-23 07:36 +0100
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-22 08:15 -0800
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 16:46 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-23 07:47 +0100
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 19:53 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-22 00:05 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-22 08:23 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-22 08:49 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-22 18:17 +0000
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-23 15:24 -0800
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-24 03:28 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-23 20:09 -0800
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-24 08:53 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 19:27 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 13:07 +0000
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-24 08:44 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 18:04 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-24 21:18 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 21:23 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-24 09:54 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 18:40 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-24 11:15 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 20:49 +0000
Re: M68k add to memory is not a mistake any more George Neuner <gneuner2@comcast.net> - 2012-02-24 17:22 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 22:39 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-25 03:00 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-24 17:44 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-24 23:11 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-24 19:22 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-25 10:14 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-25 07:37 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-25 15:57 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-25 13:39 -0500
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-25 23:26 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-26 10:09 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-26 02:45 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-26 13:05 -0500
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-27 00:53 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-27 15:22 -0500
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-27 09:21 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-27 19:47 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-28 19:16 -0800
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-29 05:07 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-29 10:49 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 10:14 +0000
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-29 08:28 -0800
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-29 08:24 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 16:43 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-29 09:08 -0800
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-29 12:17 -0800
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-27 12:23 -0800
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-28 17:12 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 09:09 +0000
Re: Itanium fixed Brett Davis <ggtgp@yahoo.com> - 2012-02-27 20:33 -0600
Re: M68k add to memory is not a mistake any more Anne & Lynn Wheeler <lynn@garlic.com> - 2012-02-25 11:15 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-25 18:10 +0000
Re: M68k add to memory is not a mistake any more Erik Trulsson <ertr1013@student.uu.se> - 2012-02-27 08:47 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-25 12:37 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-25 21:42 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-26 21:00 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-27 09:48 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-27 12:01 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 06:02 -0800
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-28 02:04 +0000
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-27 20:58 -0600
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 06:00 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-27 14:05 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 09:37 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-27 11:31 -0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 11:46 -0800
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-27 17:46 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-27 19:42 +0000
Re: M68k add to memory is not a mistake any more Bernd Felsche <berfel@innovative.iinet.net.au> - 2012-02-28 08:22 +0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-28 06:39 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-28 08:26 -0800
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-28 08:45 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-28 08:58 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-28 17:24 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-29 00:19 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-29 09:27 +0100
Re: M68k add to memory is not a mistake any more Bernd Felsche <berfel@innovative.iinet.net.au> - 2012-02-29 17:17 +0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 09:03 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-29 10:39 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 13:10 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-29 23:08 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 23:36 +0000
Re: M68k add to memory is not a mistake any more George Neuner <gneuner2@comcast.net> - 2012-03-01 15:32 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-03-01 20:52 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-28 13:15 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-28 22:28 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-28 16:13 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 10:04 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-29 10:26 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 18:28 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-29 11:24 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 19:32 +0000
Re: M68k add to memory is not a mistake any more Bernd Felsche <berfel@innovative.iinet.net.au> - 2012-03-01 03:37 +0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-29 12:14 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 18:02 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-29 13:44 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 19:24 +0000
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-29 16:22 -0500
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-29 22:41 +0000
Re: M68k add to memory is not a mistake any more mrs@kithrup.com (Mike Stump) - 2012-03-05 08:46 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-03-05 09:27 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-03-27 22:13 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-03-27 22:59 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-03-28 11:11 +0100
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-03-28 18:09 +0000
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-03-28 22:29 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-04-02 15:53 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-03 11:06 +0100
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-04-03 15:31 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-04-03 12:31 -0700
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-03 17:51 -0700
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-04 10:23 +0200
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-04-04 13:54 -0700
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-04 15:22 -0700
Re: M68k add to memory is not a mistake any more "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-04 16:11 -0700
Re: M68k add to memory is not a mistake any more jacko <jackokring@gmail.com> - 2012-04-04 19:24 -0700
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-04-05 11:01 -0700
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-04-04 13:07 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-04-04 07:17 -0700
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-04-04 20:38 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-04-06 21:24 +0000
Re: M68k add to memory is not a mistake any more kenney@cix.compulink.co.uk - 2012-04-07 04:21 -0500
Re: M68k add to memory is not a mistake any more Tom Gardner <spamjunk@blueyonder.co.uk> - 2012-04-07 11:28 +0100
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-04-07 08:57 -0700
Re: M68k add to memory is not a mistake any more Morten Reistad <first@last.name> - 2012-04-10 11:13 +0200
Re: M68k add to memory is not a mistake any more Tom Gardner <spamjunk@blueyonder.co.uk> - 2012-04-10 13:55 +0100
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-04-10 16:44 +0000
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-04-10 13:03 -0500
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-04-10 19:11 +0000
Re: M68k add to memory is not a mistake any more Tom Gardner <spamjunk@blueyonder.co.uk> - 2012-04-10 19:09 +0100
Re: M68k add to memory is not a mistake any more anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-08 14:47 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-07 19:20 +0100
Re: M68k add to memory is not a mistake any more Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-04 09:55 -0400
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-04-04 14:33 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-04-04 07:57 -0700
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-04-04 22:46 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-04 10:04 +0100
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-04-03 12:24 -0700
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-04 09:53 +0100
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-03-28 15:50 -0700
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-03-29 11:21 -0700
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-03-30 11:58 -0700
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-03 12:39 +0100
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-03-29 11:43 +0100
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-04-02 16:41 +0000
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-03 11:09 +0100
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-03-29 06:53 -0700
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-03 11:17 +0100
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-04-03 06:15 -0700
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-03 15:03 +0100
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-04-03 07:57 -0700
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-04 12:48 +0100
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-04-03 07:11 -0700
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-04-04 09:59 +0100
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-03-28 12:24 -0700
Re: M68k add to memory is not a mistake any more Andrew Reilly <areilly---@bigpond.net.au> - 2012-02-29 00:26 +0000
Re: M68k add to memory is not a mistake any more "Marven Lee" <marven10@gmail.com> - 2012-03-05 10:46 +0000
Re: M68k add to memory is not a mistake any more Morten Reistad <first@last.name> - 2012-03-01 14:16 +0100
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-27 11:51 +0000
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 06:06 -0800
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-27 08:39 -0800
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 09:33 -0800
Re: M68k add to memory is not a mistake any more Thomas Womack <twomack@chiark.greenend.org.uk> - 2012-02-27 19:20 +0000
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-27 14:36 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-27 15:29 -0500
Re: M68k add to memory is not a mistake any more Quadibloc <jsavard@ecn.ab.ca> - 2012-02-27 15:57 -0800
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-27 20:42 -0500
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-27 21:04 -0600
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-03-27 22:35 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-03-28 09:52 +0200
Re: M68k add to memory is not a mistake any more Rick Jones <rick.jones2@hp.com> - 2012-03-28 23:14 +0000
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-03-29 13:16 +0200
Re: M68k add to memory is not a mistake any more "Marven Lee" <marven10@gmail.com> - 2012-02-23 11:57 +0000
Re: M68k add to memory is not a mistake any more Bernd Felsche <berfel@innovative.iinet.net.au> - 2012-02-24 00:26 +0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 02:51 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 11:14 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 03:36 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 11:39 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 03:55 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 12:34 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 15:02 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 03:48 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 11:57 +0000
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 05:20 -0800
Re: M68k add to memory is not a mistake any more nmm1@cam.ac.uk - 2012-02-21 13:43 +0000
Re: M68k add to memory is not a mistake any more Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-21 10:04 -0800
Re: M68k add to memory is not a mistake any more Michael S <already5chosen@yahoo.com> - 2012-02-21 05:46 -0800
Re: M68k add to memory is not a mistake any more Anne & Lynn Wheeler <lynn@garlic.com> - 2012-02-21 09:57 -0500
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-21 08:54 -0800
Re: M68k add to memory is not a mistake any more Anne & Lynn Wheeler <lynn@garlic.com> - 2012-02-21 14:27 -0500
Re: M68k add to memory is not a mistake any more EricP <ThatWouldBeTelling@thevillage.com> - 2012-02-21 13:15 -0500
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-21 19:36 +0000
Re: M68k add to memory is not a mistake any more timcaffrey@aol.com (Tim McCaffrey) - 2012-02-23 01:49 +0000
Re: M68k add to memory is not a mistake any more ChrisQ <blackhole@devnull.com> - 2012-02-26 17:45 +0000
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-29 22:50 +0000
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-04 10:04 -0800
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-04 09:35 -0800
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-07 14:47 -0600
Re: M68k add to memory is not a mistake any more "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-07 15:24 -0800
Re: M68k add to memory is not a mistake any more MitchAlsup <MitchAlsup@aol.com> - 2012-02-03 12:58 -0800
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-08 11:05 -0600
Re: M68k add to memory is not a mistake any more jgk@panix.com (Joe keane) - 2012-02-07 20:04 +0000
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-08 11:26 -0600
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-09 08:09 +0100
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-09 06:23 -0600
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-09 19:19 +0100
Re: M68k add to memory is not a mistake any more Robert Wessel <robertwessel2@yahoo.com> - 2012-02-09 22:54 -0600
Re: M68k add to memory is not a mistake any more Stephen Sprunk <stephen@sprunk.org> - 2012-02-09 08:14 -0600
Re: M68k add to memory is not a mistake any more Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-09 19:11 +0100
Page 1 of 20 [1] 2 3 … 20 Next page →
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2012-01-31 03:18 -0600 |
| Subject | M68k add to memory is not a mistake any more |
| Message-ID | <ggtgp-8D1AEA.03180231012012@netnews.mchsi.com> |
Linus Torvalds told me that M68k add to memory is no longer a mistake. Upon further reflection this breaks down to a x86 add from memory with a free store instruction added, and you also save a register. This actually kinda sounds smart, provided you are doing a high end core, and have support for add from memory. Not a fan of the idea, makes low end chips harder. Any comments? (The general commentary is we could make the M68k competitive with x86 today, but there would need to be a market for it.) Anyone want to speculate on indirect addressing? Instruction cracking is cheap(?) and you get two instructions for the cost of one. I always hated indirect addressing, but now I know why Moto added all those crazy indirect modes to the 68020.
[toc] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2012-01-31 15:49 +0000 |
| Message-ID | <jg92ie$bmd$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #5640 |
In article <ggtgp-8D1AEA.03180231012012@netnews.mchsi.com>, ggtgp@yahoo.com says... > >Linus Torvalds told me that M68k add to memory is no longer a mistake. >Upon further reflection this breaks down to a x86 add from memory with >a free store instruction added, and you also save a register. > >This actually kinda sounds smart, provided you are doing a high end >core, and have support for add from memory. > >Not a fan of the idea, makes low end chips harder. Any comments? > >(The general commentary is we could make the M68k competitive with x86 >today, but there would need to be a market for it.) > > >Anyone want to speculate on indirect addressing? >Instruction cracking is cheap(?) and you get two instructions for the >cost of one. >I always hated indirect addressing, but now I know why Moto added all >those crazy indirect modes to the 68020. I don't know, but I guessed Moto added those indirect modes for Apple's Macintosh OS. They perform the same function as 286 segments (kind-of). Apple should have re-written the OS to take advantage of the MMU like a real OS. - Tim
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-01-31 09:48 -0800 |
| Message-ID | <3014212d-edec-4964-a619-1a5187497105@o13g2000vbf.googlegroups.com> |
| In reply to | #5641 |
On Jan 31, 5:49 pm, timcaff...@aol.com (Tim McCaffrey) wrote: > In article <ggtgp-8D1AEA.03180231012...@netnews.mchsi.com>, gg...@yahoo.com > says... > > > > > > >Linus Torvalds told me that M68k add to memory is no longer a mistake. > >Upon further reflection this breaks down to a x86 add from memory with > >a free store instruction added, and you also save a register. > > >This actually kinda sounds smart, provided you are doing a high end > >core, and have support for add from memory. > > >Not a fan of the idea, makes low end chips harder. Any comments? > > >(The general commentary is we could make the M68k competitive with x86 > >today, but there would need to be a market for it.) > > >Anyone want to speculate on indirect addressing? > >Instruction cracking is cheap(?) and you get two instructions for the > >cost of one. > >I always hated indirect addressing, but now I know why Moto added all > >those crazy indirect modes to the 68020. > > I don't know, but I guessed Moto added those indirect modes for Apple's > Macintosh OS. They perform the same function as 286 segments (kind-of). > Apple should have re-written the OS to take advantage of the MMU like a real > OS. > > - Tim '020 released in 1984. First Apple Macintosh released in 1984. First '020 Apple Macintosh - 1987? Given the timeline, I don't buy Apple influence.
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2012-01-31 22:20 +0000 |
| Message-ID | <jg9pem$hi7$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #5642 |
In article <3014212d-edec-4964-a619-1a5187497105@o13g2000vbf.googlegroups.com>, already5chosen@yahoo.com says... > >On Jan 31, 5:49=A0pm, timcaff...@aol.com (Tim McCaffrey) wrote: >> In article <ggtgp-8D1AEA.03180231012...@netnews.mchsi.com>, gg...@yahoo.c= >om >> says... >> >> >> >> >> >> >Linus Torvalds told me that M68k add to memory is no longer a mistake. >> >Upon further reflection this breaks down to a x86 add from memory with >> >a free store instruction added, and you also save a register. >> >> >This actually kinda sounds smart, provided you are doing a high end >> >core, and have support for add from memory. >> >> >Not a fan of the idea, makes low end chips harder. Any comments? >> >> >(The general commentary is we could make the M68k competitive with x86 >> >today, but there would need to be a market for it.) >> >> >Anyone want to speculate on indirect addressing? >> >Instruction cracking is cheap(?) and you get two instructions for the >> >cost of one. >> >I always hated indirect addressing, but now I know why Moto added all >> >those crazy indirect modes to the 68020. >> >> I don't know, but I guessed Moto added those indirect modes for Apple's >> Macintosh OS. =A0They perform the same function as 286 segments (kind-of)= >. >> Apple should have re-written the OS to take advantage of the MMU like a r= >eal >> OS. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Tim > >'020 released in 1984. >First Apple Macintosh released in 1984. >First '020 Apple Macintosh - 1987? > >Given the timeline, I don't buy Apple influence. Mac development started in 1979 (1980 for 68000 version). Plenty of time for OS programmers to whine to Moto about lack of indirect addressing. :) - Tim
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2012-01-31 10:15 -0800 |
| Message-ID | <1881785.3698.1328033725087.JavaMail.geo-discussion-forums@yqcg21> |
| In reply to | #5640 |
Even the 68020 guys understand that most of the new addressing modes in the 020 were "not good for the architecture" en-the-large, scaled index being the exception (it was useful and not damaging to the implementations). Indirect addressing: If you don't have enough registers (like 8 with some dedicated), this addressing mode makes sense at the instruction set level. If you do have enough registers (like 32), it does not. At the pipeline level, indirect addressing is a way to multiply the activity at the data cache while not adding much activity to the rest of the pipelines. Since the data cache is already on a critical path (or it would have been made bigger) adding new means to push more accesses through said cache is not going to make it any faster, and might make it smaller (to meet frequency/cycle-time). This is completely different than the 360/x86 scheme where one could organize the pipeline so that inbound memory references (loads) are made to look less expensive by hiding the data cache access before the execute stage of the pipe. Indirect addressing creates a new forwarding path from address-generator through the data cache. And as the latest 360-Z implementation showed, doing the data cache as if it were an function unit (instead of several stages in the pipeline) leads to simpler internal circuitry. So, no, indirect addressing has a lot going against it and little for it. Mitch
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <blackhole@devnull.com> |
|---|---|
| Date | 2012-02-03 15:49 +0000 |
| Message-ID | <jggvlg$8i1$3@speranza.aioe.org> |
| In reply to | #5643 |
On 01/31/12 18:15, MitchAlsup wrote: > > So, no, indirect addressing has a lot going against it and little for it. > > Mitch Although I find it interesting, i'm a user of cpu architectures, not an architect, so features that simplify the hardware design, or make programming at asm level easier, or that reduce code size, are often more important in the real world than the quest for speed. Although code size is less important now and there's less need for asm programming in general, there must be an optimum tradeoff at some point in terms of instruction set complexity and the resulting code size / execution time. That is, you can get more done in a few lines of code with a cisc architecture, than can be done with risc. There's also the issue of programmer productivity, which can be helped a lot by a regular and powerfull instruction set and addressing modes, if you need to program at asm level. Probably going against the grain here, but in the end, it's the code that matters, irrespective of how good the machine is on paper... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2012-02-03 12:44 -0800 |
| Message-ID | <12636359.2379.1328301880577.JavaMail.geo-discussion-forums@yqma6> |
| In reply to | #5678 |
On Friday, February 3, 2012 9:49:07 AM UTC-6, ChrisQ wrote: > On 01/31/12 18:15, MitchAlsup wrote: > > > > > So, no, indirect addressing has a lot going against it and little for it. > > > > Mitch > > Although I find it interesting, i'm a user of cpu architectures, not an architect, so features > that simplify the hardware design, or make programming at asm level easier, or that reduce code > size, are often more important in the real world than the quest for speed. Although code size > is less important now and there's less need for asm programming in general, there must be an > optimum tradeoff at some point in terms of instruction set complexity and the resulting code size > / execution time. That is, you can get more done in a few lines of code with a cisc architecture, > than can be done with risc. There's also the issue of programmer productivity, which can be > helped a lot by a regular and powerfull instruction set and addressing modes, if you need to > program at asm level. Probably going against the grain here, but in the end, it's the code that > matters, irrespective of how good the machine is on paper... The grain you are pulling is right out of Bell and Newell. Where thye advocate strongly on the line towards instruction set expressivity. These guys were attached to the PDP-11 architecture, and I used to listen to them talking about it in the compute science parts of CMU when I was there. The counter argument is the life (and times) of Seymore Cray (and to some extent Bill Wolfe). These guys built faster cycle time machines with somewhat inferrior instruction sets that delivered more to the bottom line (performance) than did the machines from the high expressive camp. The "gone too far" agrument is embodied in the 432. No need to say more. If it were possible to pipeline the crap out of a VAX instruction set, DEC would have done so. The difficulty in doing so did not improve DECs life as a viable company. So, somewhere less than a VAX but greater than an x86 is probably where an optimum would lie. It is a whole lot easier to pipe the crap out of a PDP-11 than a VAX. However, its all moot. There is not enough performance, area, power to be gained by another instruction set to pay for all the costs in getting said new instruction set off the ground and into a healthy market state. Mitch
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <blackhole@devnull.com> |
|---|---|
| Date | 2012-02-01 12:49 +0000 |
| Message-ID | <jgbccb$hf9$1@speranza.aioe.org> |
| In reply to | #5640 |
On 01/31/12 09:18, Brett Davis wrote: > Linus Torvalds told me that M68k add to memory is no longer a mistake. > Upon further reflection this breaks down to a x86 add from memory with > a free store instruction added, and you also save a register. > > This actually kinda sounds smart, provided you are doing a high end > core, and have support for add from memory. > > Not a fan of the idea, makes low end chips harder. Any comments? > > (The general commentary is we could make the M68k competitive with x86 > today, but there would need to be a market for it.) > > > Anyone want to speculate on indirect addressing? > Instruction cracking is cheap(?) and you get two instructions for the > cost of one. > I always hated indirect addressing, but now I know why Moto added all > those crazy indirect modes to the 68020. Maybe bad from an purist architectural point of view, but from a programming pov, it's one of the most valuable addressing modes available. In terms of minimising code space and adding clarity to the code. Probably also very helpfull for the compiler writers as well. By indirect, one assumes register as well as memory indirect addressing modes. At the time of the 68k release, memory was still expensive and code size really did matter for a lot of applications. Wasn't it the Computer Automation minis that had an indirect bit that could be used for 'n' level indirect access ?... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2012-02-01 08:02 -0800 |
| Message-ID | <25010097.1055.1328112139055.JavaMail.geo-discussion-forums@yqlw12> |
| In reply to | #5645 |
On Wednesday, February 1, 2012 6:49:17 AM UTC-6, ChrisQ wrote: > Wasn't it the Computer Automation minis that had an indirect bit that could > be used for 'n' level indirect access ?... PDP-10 did any number of indirection levels limited only by a timeout timer. Mitch
[toc] | [prev] | [next] | [standalone]
| From | sarr.blumson@alum.dartmouth.org |
|---|---|
| Date | 2012-02-01 16:18 +0000 |
| Message-ID | <jgbok9$jqt$1@dont-email.me> |
| In reply to | #5647 |
MitchAlsup <MitchAlsup@aol.com> wrote: : On Wednesday, February 1, 2012 6:49:17 AM UTC-6, ChrisQ wrote: : > Wasn't it the Computer Automation minis that had an indirect bit that could : > be used for 'n' level indirect access ?... : PDP-10 did any number of indirection levels limited only by a timeout timer. PDP-10 did any number of indirection levels not limited by anything; Instructions were restartable after an interrupt except for the byte instructions which had a psw flag indicating if the increment had already been done. So a program with an indirect loop was just like any other program with an infinite loop. -- -------- Sarr Blumson sarr.blumson@alum.dartmouth.org http://www-personal.umich.edu/~sarr/
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <blackhole@devnull.com> |
|---|---|
| Date | 2012-02-01 16:53 +0000 |
| Message-ID | <jgbqmc$n2b$1@speranza.aioe.org> |
| In reply to | #5648 |
On 02/01/12 16:18, sarr.blumson@alum.dartmouth.org wrote: > MitchAlsup<MitchAlsup@aol.com> wrote: > : On Wednesday, February 1, 2012 6:49:17 AM UTC-6, ChrisQ wrote: > :> Wasn't it the Computer Automation minis that had an indirect bit that could > :> be used for 'n' level indirect access ?... > > : PDP-10 did any number of indirection levels limited only by a timeout timer. > > PDP-10 did any number of indirection levels not limited by anything; > Instructions were restartable after an interrupt except for the byte > instructions which had a psw flag indicating if the increment had > already been done. So a program with an indirect loop was just like > any other program with an infinite loop. > I think that Motorola were heavily influenced by dec, both in their 8 bit 6800 series, where they cribbed the 11's instruction mnemonics and ditto 68k. As with the transition from pdp8 to pdp11, Motorola made a complete break from the defined function register style of 6800 to a more general purpose register achitecture. What I never worked out was why Motorola split the 16 registers into 8 x data and 8 x address, rather that a cleaner 16 general purpose set. Perhaps it was a limitation in the process technology of the day, but still think that the 68k was a real achievement. There were also other mini style architecture micros from Zilog and Nat Semi that looked interesting, but never really achieved critical mass. The arm micros i'm looking at these days seem to have a register for every occasion, but also seem bereft of powerfull addressing modes. Everything via registers makes it very laborious and long winded when programming assembler. Just a different mind set I guess... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2012-02-01 12:54 -0700 |
| Message-ID | <1b8vkmmirc.fsf@pfeifferfamily.net> |
| In reply to | #5649 |
ChrisQ <blackhole@devnull.com> writes: > On 02/01/12 16:18, sarr.blumson@alum.dartmouth.org wrote: >> MitchAlsup<MitchAlsup@aol.com> wrote: >> : On Wednesday, February 1, 2012 6:49:17 AM UTC-6, ChrisQ wrote: >> :> Wasn't it the Computer Automation minis that had an indirect bit that could >> :> be used for 'n' level indirect access ?... >> >> : PDP-10 did any number of indirection levels limited only by a timeout timer. >> >> PDP-10 did any number of indirection levels not limited by anything; >> Instructions were restartable after an interrupt except for the byte >> instructions which had a psw flag indicating if the increment had >> already been done. So a program with an indirect loop was just like >> any other program with an infinite loop. >> > > I think that Motorola were heavily influenced by dec, both in their 8 bit > 6800 series, where they cribbed the 11's instruction mnemonics and > ditto 68k. > As with the transition from pdp8 to pdp11, Motorola made a complete break > from the defined function register style of 6800 to a more general purpose > register achitecture. > > What I never worked out was why Motorola split the 16 registers into 8 x > data and 8 x address, rather that a cleaner 16 general purpose set. Perhaps > it was a limitation in the process technology of the day, but still think > that the 68k was a real achievement. It doubled the number of registers without needing an extra bit to address them. Also, when superscalar came in, it let you increase the number of read/write ports more easily (I'd be surprised if this latter advantage was even a gleam in anybody's eye when the decision was made, though). > There were also other mini style > architecture micros from Zilog and Nat Semi that looked interesting, but > never really achieved critical mass. > > The arm micros i'm looking at these days seem to have a register for every > occasion, but also seem bereft of powerfull addressing modes. Everything via > registers makes it very laborious and long winded when programming > assembler. > Just a different mind set I guess... > > Regards, > > Chris
[toc] | [prev] | [next] | [standalone]
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2012-02-02 21:01 -0600 |
| Message-ID | <ggtgp-6262E8.21013602022012@netnews.mchsi.com> |
| In reply to | #5654 |
In article <1b8vkmmirc.fsf@pfeifferfamily.net>, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote: > ChrisQ <blackhole@devnull.com> writes: > > On 02/01/12 16:18, sarr.blumson@alum.dartmouth.org wrote: > >> MitchAlsup<MitchAlsup@aol.com> wrote: > > What I never worked out was why Motorola split the 16 registers into 8 x > > data and 8 x address, rather that a cleaner 16 general purpose set. Perhaps > > it was a limitation in the process technology of the day, but still think > > that the 68k was a real achievement. > > It doubled the number of registers without needing an extra bit to > address them. Also, when superscalar came in, it let you increase the > number of read/write ports more easily (I'd be surprised if this latter > advantage was even a gleam in anybody's eye when the decision was made, > though). That is what I thought would happen, that separate registers would make the high end easier/faster. But I heard that all the high end chips (68040) actually used a unified register set under the hood.
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2012-02-02 16:41 +0000 |
| Message-ID | <jgeeb9$q51$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #5649 |
In article <jgbqmc$n2b$1@speranza.aioe.org>, blackhole@devnull.com says... > >On 02/01/12 16:18, sarr.blumson@alum.dartmouth.org wrote: >> MitchAlsup<MitchAlsup@aol.com> wrote: >> : On Wednesday, February 1, 2012 6:49:17 AM UTC-6, ChrisQ wrote: >> :> Wasn't it the Computer Automation minis that had an indirect bit that could >> :> be used for 'n' level indirect access ?... >> >> : PDP-10 did any number of indirection levels limited only by a timeout timer. >> >> PDP-10 did any number of indirection levels not limited by anything; >> Instructions were restartable after an interrupt except for the byte >> instructions which had a psw flag indicating if the increment had >> already been done. So a program with an indirect loop was just like >> any other program with an infinite loop. >> > >I think that Motorola were heavily influenced by dec, both in their 8 bit >6800 series, where they cribbed the 11's instruction mnemonics and ditto >68k. >As with the transition from pdp8 to pdp11, Motorola made a complete break >from the defined function register style of 6800 to a more general purpose >register achitecture. > >What I never worked out was why Motorola split the 16 registers into 8 x >data and 8 x address, rather that a cleaner 16 general purpose set. Perhaps >it was a limitation in the process technology of the day, but still think >that the 68k was a real achievement. There were also other mini style >architecture micros from Zilog and Nat Semi that looked interesting, but >never really achieved critical mass. > >The arm micros i'm looking at these days seem to have a register for every >occasion, but also seem bereft of powerfull addressing modes. Everything via >registers makes it very laborious and long winded when programming >assembler. >Just a different mind set I guess... > >Regards, > >Chris > I think the 6800 was more influenced by the HP-1000/2000 series. Same registers (A/B, X/Y) and direct page addressing, although the HP was more flexible (it also had indirect addressing). OTOH, some of that stuff was in the PDP-8 was well, which I think they all got from Whirlwind. If you think of the 68000 address registers as an extension of the X register in the 6800 (or X, Y & U in the 6809), and the data registers as an extension of the A/B (& D in 6809) registers in the 6800, I think the ancestory is pretty obvious. Yes, the assembler mnemonics were PDP-11ish, but so were the 8080's. - Tim
[toc] | [prev] | [next] | [standalone]
| From | ChrisQ <blackhole@devnull.com> |
|---|---|
| Date | 2012-02-02 22:47 +0000 |
| Message-ID | <jgf3p9$acp$1@speranza.aioe.org> |
| In reply to | #5662 |
On 02/02/12 16:41, Tim McCaffrey wrote: > > I think the 6800 was more influenced by the HP-1000/2000 series. Same > registers (A/B, X/Y) and direct page addressing, although the HP was more > flexible (it also had indirect addressing). OTOH, some of that stuff was in > the PDP-8 was well, which I think they all got from Whirlwind. > Whenever I see an accumulator and index register machine, I think more of the DG Nova, or pdp8. I still think the 6800 was influenced more by pdp11, due to the mnemonics, but admit the internal architecture doesn't suggest that at all. Some of the more subtle commonalities were in things like condition codes, where for example, the zero flag is set on a load, in common with 68k and pdp11. Saves the laboured tst before a branch requirement. I used an HP1000 on one site, but knew nothing of the architecture. The wiki page suggests that it was "one of many machines inspired by the pdp8". Both belong to the dedicated register for everything style, rather than one having a general purpose register set. Back to indirect addressing, the 6502 had pre and post indexed addressing modes and remember writing a menu driver program that traversed a tree organised list in just a few lines of assembler. Without the indirect modes, or doing the same on a 6800 would involved a lot more code. > > If you think of the 68000 address registers as an extension of the X register > in the 6800 (or X, Y& U in the 6809), and the data registers as an extension > of the A/B (& D in 6809) registers in the 6800, I think the ancestory is > pretty obvious. Yes, the assembler mnemonics were PDP-11ish, but so were the > 8080's. > That's a reasonable way to look at it, though the 68k was microcoded, so it wasn't just a case of gluing on a bit more logic to the 8 bit design. One of the Renesas embedded cpu's looks a bit like a souped up (8 bit) H8 to provide 16 bit functionality and more address space, but it's a far cry from the transition from 6800 to 68k. Thought: Cisc machines make better use of limited memory, whereas risc became predominant because of cheap memory ?... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-02-03 14:57 +0000 |
| Message-ID | <2012Feb3.155713@mips.complang.tuwien.ac.at> |
| In reply to | #5662 |
timcaffrey@aol.com (Tim McCaffrey) writes: >I think the 6800 was more influenced by the HP-1000/2000 series. Same >registers (A/B, X/Y) and direct page addressing, although the HP was more >flexible (it also had indirect addressing). OTOH, some of that stuff was in >the PDP-8 was well, which I think they all got from Whirlwind. > >If you think of the 68000 address registers as an extension of the X register >in the 6800 (or X, Y & U in the 6809), and the data registers as an extension >of the A/B (& D in 6809) registers in the 6800, I think the ancestory is >pretty obvious. Yes, the 68k is more an extended accumulator machine than a general-purpose register machine, even though the address registers were a little less restricted than the index registers of earlier accumulator machines. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-03 10:21 -0800 |
| Message-ID | <bfbc3bac-c0c9-490d-bbd2-6f22886f73ca@q8g2000pbb.googlegroups.com> |
| In reply to | #5649 |
On Feb 1, 9:53 am, ChrisQ <blackh...@devnull.com> wrote: > What I never worked out was why Motorola split the 16 registers into 8 x > data and 8 x address, rather that a cleaner 16 general purpose set. Well, as has already been noted, it saves a bit when specifying a register. In my imaginary architecture, http://www.quadibloc.com/arch/arcint.htm I do the same thing, but with a subtle twist. The eight data registers are also used as index registers, while the eight address registers are used as base registers only. This is because index values usually result from calculations, while base register contents are usually constant values loaded infrequently. Thus, unlike the 68020, I am able to get full base-index addressing in a 32-bit instruction even in the original form of the design without taking special measures to increase code density. The original form continues to exist as Simple Mode, although with some changes: http://www.quadibloc.com/arch/ar010006.htm after I revised the instruction formats significantly once I made a breakthrough that finally achieved what I considered a satisfactory level of code density. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-03 10:25 -0800 |
| Message-ID | <f81adde8-c4f5-4439-8f65-478aa7108183@rk3g2000pbb.googlegroups.com> |
| In reply to | #5649 |
On Feb 1, 9:53 am, ChrisQ <blackh...@devnull.com> wrote: > What I never worked out was why Motorola split the 16 registers into 8 x > data and 8 x address, rather that a cleaner 16 general purpose set. To be more specific in answering your question, both my imaginary design and the 68k use 16 bit displacements when addressing memory. The IBM 360, in order to use a set of 16 general-purpose registers, and provide base-index registers, had to limit itself to 12-bit displacements in order for memory-reference instructions to fit in 32 bits. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2012-02-03 12:48 -0800 |
| Message-ID | <9643775.2308.1328302126316.JavaMail.geo-discussion-forums@yqks7> |
| In reply to | #5649 |
On Wednesday, February 1, 2012 10:53:35 AM UTC-6, ChrisQ wrote: > What I never worked out was why Motorola split the 16 registers into 8 x > data and 8 x address, rather that a cleaner 16 general purpose set. Perhaps > it was a limitation in the process technology of the day, but still think > that the 68k was a real achievement. A) They ran out of instruction bits B) They could gain register file ports at low cost C) Microcode could use both register files independently and simultaneously Mitch
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-02-07 12:02 -0500 |
| Message-ID | <wQcYq.14668$Au5.964@newsfe23.iad> |
| In reply to | #5762 |
MitchAlsup wrote:
> On Wednesday, February 1, 2012 10:53:35 AM UTC-6, ChrisQ wrote:
>> What I never worked out was why Motorola split the 16 registers into 8 x
>> data and 8 x address, rather that a cleaner 16 general purpose set. Perhaps
>> it was a limitation in the process technology of the day, but still think
>> that the 68k was a real achievement.
>
> A) They ran out of instruction bits
> B) They could gain register file ports at low cost
> C) Microcode could use both register files independently and simultaneously
>
> Mitch
Microprogrammed implementation of a single chip microprocessor (1978)
Skip Stritter, Nick Tredennick
http://dl.acm.org/citation.cfm?id=804299
talks mostly about the 68000 microcode (2 level, vertical + horizontal).
However it does touch a little on the internal organization.
X = bus isolator
-------X-------------------X-------\16 addr bus
| | |
Bank 1 Bank 2 Bank 3
16 bits 16 bits 16 bits
8 High Addr Regs 8 Low Addr Regs 8 Low Data Regs
8 High Data Regs Arithmetic Low ALU
Arithmetic High | |
| | |
-------X-------------------X-------\16 data bus
"The register file is divided into three
sections as shown in Fig. I. Two buses connect
all of the words in the register file. The
register file sections are either isolated or
concatermted using the bi-directional bus
switches;. This permits general register transfer
operations across register sections. A
limited arithmetic unit is located in each
segment containing address register words and
a general capability arithmetic and logical
unit is located in the data low word section.
This allows address and data calculations to
occur simultaneously. For example, it is
possible to do a register-to-register word
addition concurrently with a program counter
increment (the program counter is colocated
with the address register words and carry out
from the aritemetic unit low is provided as
carry in to the arithmetic unit high).
Special functional units for bit manipulation,
packing and unpacking data are located in the
data section.
Two factors combined to suggest the desirability
of the configuration shown in Figure I.
The first was a very dense two-port static RAM
cell which conveniently supported a two-bus
structure. The second was the 16-bit data width
which made 16-bit segmentation of the registers
desirable."
Instruction register fields and alu function codes
are routed directly from the instruction register to
the register banks and ALU's, saving on microcode.
It doesn't say why they collocated the
high data and high address regs.
Eric
[toc] | [prev] | [next] | [standalone]
Page 1 of 20 [1] 2 3 … 20 Next page →
Back to top | Article view | comp.arch
csiph-web