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 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2012-02-10 09:21 +0100 |
| Message-ID | <il0f09-rj8.ln1@ntp6.tmsw.no> |
| In reply to | #5854 |
Stephen Fuld wrote: > What I proposed was sort of between the two cases above. Each > instruction that has the bit set can only go to one particular register, > but that register can be different for each instruction. That is, it > isn't always R2, but it is always the register at the next higher number > than the source register number. How does that fit in in terms of > difficulty? It seems similar to how I believe some architectures (Sparc???) handles full n*x->2n multiplications, i.e. the high half of the result is implied to be the "next" register. Or maybe I just imagined reading that? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-02-10 04:11 -0600 |
| Message-ID | <4sq9j7t9tqtjitb2tld3qrcduasgpog59t@4ax.com> |
| In reply to | #5856 |
On Fri, 10 Feb 2012 09:21:36 +0100, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Stephen Fuld wrote: >> What I proposed was sort of between the two cases above. Each >> instruction that has the bit set can only go to one particular register, >> but that register can be different for each instruction. That is, it >> isn't always R2, but it is always the register at the next higher number >> than the source register number. How does that fit in in terms of >> difficulty? > >It seems similar to how I believe some architectures (Sparc???) handles >full n*x->2n multiplications, i.e. the high half of the result is >implied to be the "next" register. > >Or maybe I just imagined reading that? I don't think SPARC does that, it certainly didn't in the early days, although it's possible it's been added. S/360, and its descendents, OTOH, have always had a number of instructions reference "even-odd register pairs". The result from a full multiply, for example, would be placed in an adjacent pair of registers, with the requirement that the register referenced in the instruction is the even numbered one (so "MR R2,R7" would multiply the contents of R2 and R7, and leave the 64 bit result in R2 and R3). Various other double width instructions use the same scheme.
[toc] | [prev] | [next] | [standalone]
| From | Eric Northup <digitaleric@gmail.com> |
|---|---|
| Date | 2012-02-10 11:41 -0800 |
| Message-ID | <6ab09d7c-675c-4ec0-830a-9903b70b511f@v6g2000pba.googlegroups.com> |
| In reply to | #5859 |
On Feb 10, 2:11 am, Robert Wessel <robertwess...@yahoo.com> wrote: > On Fri, 10 Feb 2012 09:21:36 +0100, Terje Mathisen <"terje.mathisen at > > tmsw.no"> wrote: > >Stephen Fuld wrote: > >> What I proposed was sort of between the two cases above. Each > >> instruction that has the bit set can only go to one particular register, > >> but that register can be different for each instruction. That is, it > >> isn't always R2, but it is always the register at the next higher number > >> than the source register number. How does that fit in in terms of > >> difficulty? > > >It seems similar to how I believe some architectures (Sparc???) handles > >full n*x->2n multiplications, i.e. the high half of the result is > >implied to be the "next" register. > > >Or maybe I just imagined reading that? > > I don't think SPARC does that, it certainly didn't in the early days, > although it's possible it's been added. SPARC v8 (the 32-bit one) has 64-bit load-and store-doubleword instructions LDD and STD which operate on adjacent pairs of 32-bit registers. The most-significant 32 bits come from the even register, and the least significant come from the next higher (odd) register. The pairs always have to start with an even register.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-02-10 12:12 -0500 |
| Message-ID | <yecZq.18801$%17.3222@newsfe06.iad> |
| In reply to | #5856 |
Terje Mathisen wrote: > Stephen Fuld wrote: >> What I proposed was sort of between the two cases above. Each >> instruction that has the bit set can only go to one particular register, >> but that register can be different for each instruction. That is, it >> isn't always R2, but it is always the register at the next higher number >> than the source register number. How does that fit in in terms of >> difficulty? > > It seems similar to how I believe some architectures (Sparc???) handles > full n*x->2n multiplications, i.e. the high half of the result is > implied to be the "next" register. > > Or maybe I just imagined reading that? > > Terje PDP 11: if dest reg is even, store result in reg and reg+1. If dest reg is odd, store just low result. Eric
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-10 06:34 -0800 |
| Message-ID | <4F352B0B.6040108@SPAM.comp-arch.net> |
| In reply to | #5854 |
On 2/9/2012 10:58 PM, Stephen Fuld wrote: > On 2/9/2012 11:20 AM, Andy (Super) Glew wrote: >> On 2/8/2012 1:39 PM, Stephen Fuld wrote: >>> On 2/5/2012 3:50 AM, Terje Mathisen wrote: >>>> Stephen Fuld wrote: >>>>> A potential compromise would be to have a two operand instruction >>>>> format, but with an additional single bit field. Upon decoding, the >>>>> value of this field is added to the register number (from the >>>>> instruction istelf, not the contents of the specified register) to >>>>> give >>>>> the destination register. Thus, if the value of the field is zero, the >>>>> instruction is a traditional two operand instruction. If the bit is >>>>> set, >>>>> then the destination is one register "higher" than the source and you >>>>> have preserved the source register's contents. >>>>> >>>>> I think this would gain much (but probably not all) of the value of >>>>> three operand instructions, but with only a single bit instead of >>>>> however many are needed for a full register specification. >> But as long as each operand can come from or go to a few places, say 2 >> or 4, they say they can usually schedule without too much wasted motion. > > What I proposed was sort of between the two cases above. Each > instruction that has the bit set can only go to one particular register, > but that register can be different for each instruction. That is, it > isn't always R2, but it is always the register at the next higher number > than the source register number. How does that fit in in terms of > difficulty? Assuming that I have clipped the right spot: What you propose - writing to one register higher than the input - causes me to break out in screaming fits, but, based on what my compiler guy friends in the past have said, can *PROBABLY* be handled. However, I can say with rather high probability that there is probably no existing code in any compiler to do exactly this, and it is quite different from existing register allocation. Thus, my bet is that doing this, while not a theoretical problem, would probably cause the project to "slip by a year", or "require cancelling some other planned compiler features". I.e. at the best it is just another tiresome "simple matter of programming". At the worst, there may be a more fundamental problem that the compiler guys have glossed over. But I must admit that, based on what they have said in the past, they may be able to handle this.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2012-02-10 11:01 -0500 |
| Message-ID | <jwvty2y3clb.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #5860 |
> What you propose - writing to one register higher than the input -
> causes me to break out in screaming fits, but, based on what my compiler guy
> friends in the past have said, can *PROBABLY* be handled.
Agreed. At least, for a Chaitin/Briggs style graph coloring register
allocator, it's pretty easy to deal with restrictions "this can only go
to this subset of registers" by simply adding a few constraints to the
input graph, but having the output reg depend on the choice of the input
reg seems a lot less straightforward to express.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2012-02-10 09:46 +0100 |
| Message-ID | <g32f09-nl8.ln1@ntp6.tmsw.no> |
| In reply to | #5851 |
Andy (Super) Glew wrote: > However, I have also learned, in person communication from some of the > best compiler writers in the world, that it is not that hard to deal > with irregular instruction sets. They say things like "it's just another > color to deal with". But that these techniques are not compilers 101, Aha! Mapping register sets into static colors seems like a very good way to handle this. > not typically taught in a school, even at graduate level, unless you are > specializing in exactly this. > > I took a course from Michael Wolfe, the "superoptimizing supcomiler for > supercomputers guy", who said the same thing, although not so forcefully. > > They do emphasize that they dislike totally fixed register bindings, > such as "Instruction FOO can only read from reg r1 and write to reg r2". > > But as long as each operand can come from or go to a few places, say 2 > or 4, they say they can usually schedule without too much wasted motion. Thanks for the input. Mike Wolfe is simply saying that, "Yes, of course we can do the same sort of tracking and long-term scheduling as a human asm programmer." :-) The part of disliking anything totally fixed is borne out by the x86 usage of CL/CX/ECX/RCX for all variable shift counts: I have never seen a compiler that understood that said shift(s) could be so (latency-)critical that all the rest of the register allocations had to be switched around, just so that those particular shift counts would end up naturally in ECX. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-02-10 17:20 +0000 |
| Message-ID | <2012Feb10.182016@mips.complang.tuwien.ac.at> |
| In reply to | #5858 |
Terje Mathisen <"terje.mathisen at tmsw.no"> writes: >Andy (Super) Glew wrote: >> However, I have also learned, in person communication from some of the >> best compiler writers in the world, that it is not that hard to deal >> with irregular instruction sets. They say things like "it's just another >> color to deal with". But that these techniques are not compilers 101, > >Aha! Mapping register sets into static colors seems like a very good way >to handle this. > >> not typically taught in a school, even at graduate level, unless you are >> specializing in exactly this. >> >> I took a course from Michael Wolfe, the "superoptimizing supcomiler for >> supercomputers guy", who said the same thing, although not so forcefully. >> >> They do emphasize that they dislike totally fixed register bindings, >> such as "Instruction FOO can only read from reg r1 and write to reg r2". That's relatively straightforward to handle, it just causes additional overhead compared to not having that restriction. >> But as long as each operand can come from or go to a few places, say 2 >> or 4, they say they can usually schedule without too much wasted motion. Maybe, but I am not aware of papers about that problem, so it would probably require quite a bit of effort to find good heuristics to deal with that. The quick-and-dirty solution would be to generate code as if the registers were fixed. Maybe the compiler writer you were communicating with had some technique for dealing with this problem. >Mike Wolfe is simply saying that, "Yes, of course we can do the same >sort of tracking and long-term scheduling as a human asm programmer." :-) If he was saying that, it would sound overconfident to me. >The part of disliking anything totally fixed is borne out by the x86 >usage of CL/CX/ECX/RCX for all variable shift counts: I have never seen >a compiler that understood that said shift(s) could be so >(latency-)critical that all the rest of the register allocations had to >be switched around, just so that those particular shift counts would end >up naturally in ECX. Certainly, that's a typical phase conflict. Register allocation is usually dumb about latencies; while there is some work in that direction, I don't think it is used much in production compilers, nor has there been much followup research. One reason is that first RISCs and later OoO made this look not very relevant. And my guess is that this kind of code is rare enough that a typical evaluation (i.e., use the compiler on standard benchmarks) would show little benefit from addressing such things. - 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 | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2012-02-11 18:29 +0000 |
| Message-ID | <jh6c36$90d$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #5858 |
In article <g32f09-nl8.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says... > >The part of disliking anything totally fixed is borne out by the x86 >usage of CL/CX/ECX/RCX for all variable shift counts: I have never seen >a compiler that understood that said shift(s) could be so >(latency-)critical that all the rest of the register allocations had to >be switched around, just so that those particular shift counts would end >up naturally in ECX. > Not to mention all the other instructions with dedicated registers (string instructions (ECX, EDI, ESI, EAX), I/O, loop & jcxz, Multiply, divide, etc). (BTW, why is jcxz expensive and CMP CX,0/JZ is not?) Intel added a three operand RORX instruction for Haswell, too bad they didn't add a three operand shift group the allowed something besides CL to be used. New string instructions that allowed flexible register usage would also be cool, and they could even add some useful ones that combine MOVS & SCAS or CMPS & SCAS (allows one instruction strcpy & strcmp). - Tim
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-11 15:35 -0800 |
| Message-ID | <4F36FB3A.3070304@SPAM.comp-arch.net> |
| In reply to | #5881 |
On 2/11/2012 10:29 AM, Tim McCaffrey wrote: > In article<g32f09-nl8.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says... >> > >> The part of disliking anything totally fixed is borne out by the x86 >> usage of CL/CX/ECX/RCX for all variable shift counts: I have never seen >> a compiler that understood that said shift(s) could be so >> (latency-)critical that all the rest of the register allocations had to >> be switched around, just so that those particular shift counts would end >> up naturally in ECX. >> > > Not to mention all the other instructions with dedicated registers (string > instructions (ECX, EDI, ESI, EAX), I/O, loop& jcxz, Multiply, divide, etc). > (BTW, why is jcxz expensive and CMP CX,0/JZ is not?) http://download.intel.com/design/pentiumii/manuals/24281603.pdf gives JCXZ a uop count of 2, versus 1 uop for the "normal" Jccs. I don't think that JCXZ is intrinsically expensive. It could be decoded into a uop TargetIP := JumpIfReg0(CX,Offset), if Intel's datapath supported that. It's just that there is only so much room in the fast path decoders. The "normal" Jcc pretty much have to be fast. They look something like TargetIP := Jcc(Flag,Offset). JCXZ would require something verging on a new uop type (I say "verging on", since there is not that much difference between JumpIfReg0 and Jcc, on an out of order machine if the flags are attached to the high bits of a physical register - e.g. bits >31 on a 32 bit machine, >63 on a 64 bit machine, etc. But if the flags are a completely differehnt type of dataflow operand, then a new uop type.) JCXZ isn't close to Jcc, so would have required an extra pattern - minterms - in the fast decoder to make fast. But Jcc is close to a whole slew of other slow, deprecated, instructions - the other LOOP instructions, IN and OUT - so probably naturally wants to be covered by minterms for slowness. Back on earlier in-order machines, JCXZ was deprecated. E.g. on Pentium it was NP, non-paired. JCXZ only comes with an 8 bit displacement, as do the LOOP instructions, whereas the other Jccs can have 16 bit displacements. This is probably the kiss of death: JCZ and LOOP* mikght well have been made fast, if they had 16 bit displacements, displacements large enough to be useful. But, with only an 8 bit displacement, nobody uses them; and since nobody uses them, nobody optimizes for them. Compare-Jcc fusion, although equivalent in "complexity" to JCXZ, is much more useful/much more widely used.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2012-02-12 00:47 +0100 |
| Message-ID | <p8bj09-voq.ln1@ntp6.tmsw.no> |
| In reply to | #5881 |
Tim McCaffrey wrote: > In article<g32f09-nl8.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says... >> The part of disliking anything totally fixed is borne out by the x86 >> usage of CL/CX/ECX/RCX for all variable shift counts: I have never seen >> a compiler that understood that said shift(s) could be so >> (latency-)critical that all the rest of the register allocations had to >> be switched around, just so that those particular shift counts would end >> up naturally in ECX. >> > > Not to mention all the other instructions with dedicated registers (string > instructions (ECX, EDI, ESI, EAX), I/O, loop& jcxz, Multiply, divide, etc). Sure, although MUL is helped a lot by IMUL as long as you don't care about 2N wide results. > (BTW, why is jcxz expensive and CMP CX,0/JZ is not?) Not used by compilers, so not worth making fast? > > Intel added a three operand RORX instruction for Haswell, too bad they didn't > add a three operand shift group the allowed something besides CL to be used. > > New string instructions that allowed flexible register usage would also be > cool, and they could even add some useful ones that combine MOVS& SCAS or > CMPS& SCAS (allows one instruction strcpy& strcmp). They have that, in spades: The 256-way byte compare state machine hidden inside the SSE parallel string operations can do any or all of those. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-02-04 17:56 -0600 |
| Message-ID | <jgkgik$6jt$1@dont-email.me> |
| In reply to | #5706 |
On 04-Feb-12 13:53, Terje Mathisen wrote: > Stephen Sprunk wrote: >> On 04-Feb-12 00:49, Andy (Super) Glew wrote: >>> However, I think it is worth noting that OoO P6 x86 is really the Intel >>> chip that killed the RISC upstarts. >> >> Right, for the reason mentioned above. However, if x86 had been >> load-store from the start, compilers would (or at least could) have done >> their own load hoisting rather than waiting for the silicon to do it for >> them, and perhaps x86 would have pulled ahead earlier--and then wider >> in-order execution or larger caches on the P5 would have put the nail in >> competitors' coffins rather than the P6. > > As I think you noted earlier, a compiler would have had big problems > with the original 6-7 available x86 registers, so you could only get rid > of load-op if you used those instruction bits to double the number of > registers. Indeed; that would have been the most logical use of the two bits recovered by eliminating ModRM's addressing-mode field. However, I don't know what eight extra registers would have cost the 8086 in terms of transistors, nor whether reduced stack spills would have made up for the need for explicit loads/stores. > Register pressure was in fact the main reason good asm programmers could > consistently beat the best compilers by a factor of 1.5 to 3 on most code. How much was the asm advantage on systems with less register pressure? >> The RISC upstarts had huge code bloat due to 3-operand, fixed-size >> instructions. That meant they required more RAM, disk, I-cache and >> memory bandwidth for the same code, which hurt their price/performance >> ratio. The idea wasn't so bad, but they didn't have the volume to hang >> on until code size didn't matter. > > I'm not convinced 3-operand is a net loss at all, even if most of the > obvious wins are in really short sequences of complicated > latency-critical operations. Perhaps I'm conflating 3-operand instructions with fixed-size instructions, but the two seem to travel together. A fixed-size instruction format (eg. MIPS) capable of encoding three operands means a lot of bits are wasted, resulting in code that is roughly double the size of 2-operand, variable-length instruction sets (eg. x86, m68k). Are there examples of a 3-operand, variable-length instruction set? Or, better yet, a variable-length instruction set where the third operand is optional? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2012-02-05 02:17 -0600 |
| Message-ID | <ggtgp-C93532.02175905022012@netnews.mchsi.com> |
| In reply to | #5710 |
In article <jgkgik$6jt$1@dont-email.me>, Stephen Sprunk <stephen@sprunk.org> wrote: > Perhaps I'm conflating 3-operand instructions with fixed-size > instructions, but the two seem to travel together. A fixed-size > instruction format (eg. MIPS) capable of encoding three operands means a > lot of bits are wasted, resulting in code that is roughly double the > size of 2-operand, variable-length instruction sets (eg. x86, m68k). > > Are there examples of a 3-operand, variable-length instruction set? Or, > better yet, a variable-length instruction set where the third operand is > optional? Yes, Amtel AVR32 http://en.wikipedia.org/wiki/AVR32 http://www.atmel.com/Images/doc32000.pdf Also ARM Thumb2/Cortex
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2012-02-05 10:53 -0800 |
| Message-ID | <70426974-7642-4c09-b28c-d146a1dfd4a0@w19g2000vbe.googlegroups.com> |
| In reply to | #5713 |
On Feb 5, 3:17 am, Brett Davis <gg...@yahoo.com> wrote: > In article <jgkgik$6j...@dont-email.me>, > Stephen Sprunk <step...@sprunk.org> wrote: > > > Perhaps I'm conflating 3-operand instructions with fixed-size > > instructions, but the two seem to travel together. A fixed-size > > instruction format (eg. MIPS) capable of encoding three operands means a > > lot of bits are wasted, resulting in code that is roughly double the > > size of 2-operand, variable-length instruction sets (eg. x86, m68k). > > > Are there examples of a 3-operand, variable-length instruction set? Or, > > better yet, a variable-length instruction set where the third operand is > > optional? > > Yes, Amtel AVR32http://en.wikipedia.org/wiki/AVR32http://www.atmel.com/Images/doc32000.pdf > > Also ARM Thumb2/Cortex And microMIPS (similar to Thumb2).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-02-05 02:20 -0600 |
| Message-ID | <4kesi759vcck9ob4kgeivm1cce2fr6s5dv@4ax.com> |
| In reply to | #5710 |
On Sat, 04 Feb 2012 17:56:02 -0600, Stephen Sprunk <stephen@sprunk.org> wrote: >On 04-Feb-12 13:53, Terje Mathisen wrote: >> Stephen Sprunk wrote: >>> On 04-Feb-12 00:49, Andy (Super) Glew wrote: >>>> However, I think it is worth noting that OoO P6 x86 is really the Intel >>>> chip that killed the RISC upstarts. >>> >>> Right, for the reason mentioned above. However, if x86 had been >>> load-store from the start, compilers would (or at least could) have done >>> their own load hoisting rather than waiting for the silicon to do it for >>> them, and perhaps x86 would have pulled ahead earlier--and then wider >>> in-order execution or larger caches on the P5 would have put the nail in >>> competitors' coffins rather than the P6. >> >> As I think you noted earlier, a compiler would have had big problems >> with the original 6-7 available x86 registers, so you could only get rid >> of load-op if you used those instruction bits to double the number of >> registers. > >Indeed; that would have been the most logical use of the two bits >recovered by eliminating ModRM's addressing-mode field. However, I >don't know what eight extra registers would have cost the 8086 in terms >of transistors, nor whether reduced stack spills would have made up for >the need for explicit loads/stores. > >> Register pressure was in fact the main reason good asm programmers could >> consistently beat the best compilers by a factor of 1.5 to 3 on most code. > >How much was the asm advantage on systems with less register pressure? > >>> The RISC upstarts had huge code bloat due to 3-operand, fixed-size >>> instructions. That meant they required more RAM, disk, I-cache and >>> memory bandwidth for the same code, which hurt their price/performance >>> ratio. The idea wasn't so bad, but they didn't have the volume to hang >>> on until code size didn't matter. >> >> I'm not convinced 3-operand is a net loss at all, even if most of the >> obvious wins are in really short sequences of complicated >> latency-critical operations. > >Perhaps I'm conflating 3-operand instructions with fixed-size >instructions, but the two seem to travel together. A fixed-size >instruction format (eg. MIPS) capable of encoding three operands means a >lot of bits are wasted, resulting in code that is roughly double the >size of 2-operand, variable-length instruction sets (eg. x86, m68k). > >Are there examples of a 3-operand, variable-length instruction set? Or, >better yet, a variable-length instruction set where the third operand is >optional? CDC 6600 and Cray-1 (and various of their successors) come to mind. Neither of those really had optional third operands, although both had some two operand instructions, these were encoded with an ignored third operand field.
[toc] | [prev] | [next] | [standalone]
| From | nospam@ab-katrinedal.dk (Niels Jørgen Kruse) |
|---|---|
| Date | 2012-02-05 11:31 +0100 |
| Message-ID | <1kezoy6.11ddig88fqwhgN%nospam@ab-katrinedal.dk> |
| In reply to | #5710 |
Stephen Sprunk <stephen@sprunk.org> wrote: > instructions, but the two seem to travel together. A fixed-size > instruction format (eg. MIPS) capable of encoding three operands means a > lot of bits are wasted, resulting in code that is roughly double the > size of 2-operand, variable-length instruction sets (eg. x86, m68k). IIRC years ago Anton Ertl posted executable sizes for various ISAs, that disagree with your claim. -- Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-02-05 09:34 -0600 |
| Message-ID | <jgm7h8$e5o$1@dont-email.me> |
| In reply to | #5716 |
On 05-Feb-12 04:31, Niels Jørgen Kruse wrote: > Stephen Sprunk <stephen@sprunk.org> wrote: >> instructions, but the two seem to travel together. A fixed-size >> instruction format (eg. MIPS) capable of encoding three operands means a >> lot of bits are wasted, resulting in code that is roughly double the >> size of 2-operand, variable-length instruction sets (eg. x86, m68k). > > IIRC years ago Anton Ertl posted executable sizes for various ISAs, that > disagree with your claim. Recent research seems to support it, though my "roughly double" may have been overstating the case: http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf Instruction length correlates very well (0.9381) with code size, and the number of operands per instruction correlates fairly well (0.4982). S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | nospam@ab-katrinedal.dk (Niels Jørgen Kruse) |
|---|---|
| Date | 2012-02-05 17:06 +0100 |
| Message-ID | <1kf04rz.139coh41amuiv4N%nospam@ab-katrinedal.dk> |
| In reply to | #5719 |
Stephen Sprunk <stephen@sprunk.org> wrote: > On 05-Feb-12 04:31, Niels Jørgen Kruse wrote: > > Stephen Sprunk <stephen@sprunk.org> wrote: > >> instructions, but the two seem to travel together. A fixed-size > >> instruction format (eg. MIPS) capable of encoding three operands means a > >> lot of bits are wasted, resulting in code that is roughly double the > >> size of 2-operand, variable-length instruction sets (eg. x86, m68k). > > > > IIRC years ago Anton Ertl posted executable sizes for various ISAs, that > > disagree with your claim. > > Recent research seems to support it, though my "roughly double" may have > been overstating the case: > > http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf > > Instruction length correlates very well (0.9381) with code size, and the > number of operands per instruction correlates fairly well (0.4982). That is for handoptimized assembler, not compiled code. -- Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-02-05 12:06 -0500 |
| Message-ID | <iHyXq.1967$Tu.651@newsfe05.iad> |
| In reply to | #5719 |
Stephen Sprunk wrote: > On 05-Feb-12 04:31, Niels Jørgen Kruse wrote: >> Stephen Sprunk <stephen@sprunk.org> wrote: >>> instructions, but the two seem to travel together. A fixed-size >>> instruction format (eg. MIPS) capable of encoding three operands means a >>> lot of bits are wasted, resulting in code that is roughly double the >>> size of 2-operand, variable-length instruction sets (eg. x86, m68k). >> IIRC years ago Anton Ertl posted executable sizes for various ISAs, that >> disagree with your claim. > > Recent research seems to support it, though my "roughly double" may have > been overstating the case: > > http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf > > Instruction length correlates very well (0.9381) with code size, and the > number of operands per instruction correlates fairly well (0.4982). > > S > Hmmm... they were correlating to minimum instruction length. I don't think that is very useful as an ISA may have only a couple of one byte instructions (noop and halt), and the rest all 2 or 3 bytes. Average length would have been a useful measure. Correlating fixed vs variable would have been interesting, if only to confirm what everyone "knows" (fixed has lots of zeros). The number of integer registers vs code size I would expect to have a U shape, with the minimum from 16 to 31/32. There might also be combination interactions. Number of operands is low correlation, but #operands with #registers is high because 3 operand might need 31/32 regs to avoid spillage. Eric
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-02-05 13:04 -0600 |
| Message-ID | <jgmjrv$ppc$1@dont-email.me> |
| In reply to | #5721 |
On 05-Feb-12 11:06, EricP wrote: > Stephen Sprunk wrote: >> On 05-Feb-12 04:31, Niels Jørgen Kruse wrote: >>> Stephen Sprunk <stephen@sprunk.org> wrote: >>>> instructions, but the two seem to travel together. A fixed-size >>>> instruction format (eg. MIPS) capable of encoding three operands >>>> means a lot of bits are wasted, resulting in code that is roughly >>>> double the size of 2-operand, variable-length instruction sets (eg. >>>> x86, m68k). >>> >>> IIRC years ago Anton Ertl posted executable sizes for various ISAs, >>> that disagree with your claim. >> >> Recent research seems to support it, though my "roughly double" may >> have been overstating the case: >> >> http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf >> >> Instruction length correlates very well (0.9381) with code size, and the >> number of operands per instruction correlates fairly well (0.4982). > > Hmmm... they were correlating to minimum instruction length. > I don't think that is very useful as an ISA may have only > a couple of one byte instructions (noop and halt), > and the rest all 2 or 3 bytes. > Average length would have been a useful measure. True, though variable-length instructions do tend towards the low end, so I'm not sure how much difference it would make. > Correlating fixed vs variable would have been interesting, > if only to confirm what everyone "knows" (fixed has lots of zeros). Agreed. > The number of integer registers vs code size I would expect > to have a U shape, with the minimum from 16 to 31/32. That is the conventional wisdom. However, 16-register code seems to consistently beat 32-register code on size, so the minimum may be at 16. OTOH, that could be a result of the correlation between #register and other factors (below). > There might also be combination interactions. > Number of operands is low correlation, > but #operands with #registers is high because > 3 operand might need 31/32 regs to avoid spillage. I don't see why that would be the case; you can always set the destination in a 3-operand instruction to one of the sources, effectively making it a 2-operand instruction, if you don't need to preserve both sources. OTOH, a 2-operand instruction set would require an extra instruction to preserve a source. The correlation between #operands and #registers may be misleading, as both correlate well with larger, fixed-size instructions: lots of bits to burn, which apparently doesn't turn out to be productive very often. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
Page 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
Back to top | Article view | comp.arch
csiph-web