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 14 of 20 — ← Prev page 1 … 12 13 [14] 15 16 … 20 Next page →
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2012-02-29 00:19 +0000 |
| Message-ID | <9r598uFkvhU1@mid.individual.net> |
| In reply to | #6147 |
On Tue, 28 Feb 2012 17:24:23 +0000, nmm1 wrote: > Yes, that puts it in a nutshell. There are circumstances where any > interrupt is bad news, but they are relatively rare and can usually be > dealt with fairly simply. If, however, the easiest solution is to > eliminate interrupts entirely, I am happy with that - but, as always, > with the proviso "if done competently". I don't see how it can be done "competently". To my mind, interrupts are the lesser of two evil approaches. If you remove interrupts, thus vastly simplifying the (relatively tiny but important) task of task switching, and also simplifying the models that describe inter-process communication, you instead burden *every* piece of code on the system, written by even the newbiest of application coders with the requirement that no code path exceed N-microseconds between system calls, for some smallish N. That becomes essentially impossible for anything both tight and scaleable, like memory copy functions or FFT functions, where the requirement turns into a need to explicitly tesselate loops: turning every singly-nested loop into a doubly-nested one, with a yield() call of some sort tacked into the second-to-inner loop. Now, it often happens that highly optimised code for these sorts of tasks *will* be of that form already, for reasons of cache-blocking and what-not. But naiive code won't, in general, and that then becomes your limiting factor. Is it better to have your system limited by the most naiive code it has to run, or by it's most competently written kernels? We've all seen how well cooperatively multi-tasked operating systems worked. They worked "fine" for a while, while all of the applications were written by the designers and other experts, and while expectations of performance by users were low. In the end, the only way to deal with them is to throw them against a wall and replace them with a competently- written genuine time-sharing system. > Of course, writing schedulers and spin-loops is complicated by having to > allow for interrupts, but it's not as truly evil as writing handlers. But at least the interrupt handlers generally only have to be written by people who are up to the task, and who understand the issues. Cheers, -- Andrew
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2012-02-29 09:27 +0100 |
| Message-ID | <a54129-ujb2.ln1@ntp6.tmsw.no> |
| In reply to | #6152 |
Andrew Reilly wrote: > On Tue, 28 Feb 2012 17:24:23 +0000, nmm1 wrote: >> Of course, writing schedulers and spin-loops is complicated by having to >> allow for interrupts, but it's not as truly evil as writing handlers. > > But at least the interrupt handlers generally only have to be written by > people who are up to the task, and who understand the issues. I think I'm somewhere in the middle here: I think interrupts are _fine_, but I really don't want them to have (immediate) user-visible consequences. I.e. except for the task switch interrupt, I would like _all_ interrupt handlers to be of the absolute minimal form: Read a status port or two to figure out exactly what needs to be done, save away any critical data in a fifo buffer and send a signal to a regular thread to do the rest of the work, before returning cleanly. Async callbacks to user code is of course absolutely out of the question! With such a model it is easy to (manually) make sure that there are no side effects and no way for the interrupted program to be perturbed. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Bernd Felsche <berfel@innovative.iinet.net.au> |
|---|---|
| Date | 2012-02-29 17:17 +0800 |
| Message-ID | <127129xcig.ln2@innovative.iinet.net.au> |
| In reply to | #6163 |
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Andrew Reilly wrote: >> On Tue, 28 Feb 2012 17:24:23 +0000, nmm1 wrote: >>> Of course, writing schedulers and spin-loops is complicated by >>> having to allow for interrupts, but it's not as truly evil as >>> writing handlers. >> But at least the interrupt handlers generally only have to be >> written by people who are up to the task, and who understand the >> issues. >I think I'm somewhere in the middle here: >I think interrupts are _fine_, but I really don't want them to have >(immediate) user-visible consequences. >I.e. except for the task switch interrupt, I would like _all_ interrupt >handlers to be of the absolute minimal form: >Read a status port or two to figure out exactly what needs to be done, >save away any critical data in a fifo buffer and send a signal to a >regular thread to do the rest of the work, before returning cleanly. Interrupt handling should be only a matter of preserving the context within which the interrupt occurred and assigning/scheduling a thread to do the heavy lifting, outside of the interrupt handler. >Async callbacks to user code is of course absolutely out of the question! >With such a model it is easy to (manually) make sure that there are no >side effects and no way for the interrupted program to be perturbed. There is no technical reason why a user-level program should not be able to be assign a thread to be event-driven; either by internal events (e.g. floating-point exceptions) or external (e.g. mouse events, interrupts and async-io-completion). Few "regular programmers" are able to work effectively in an event-driven environment; because so much code base to which they are routinely exposed is predominately procedural. It takes a different frame of mind to undertake efficient, event-driven programming. -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | For every complex problem there is an X against HTML mail | answer that is clear, simple, and wrong. / \ and postings | --HL Mencken
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 09:03 +0000 |
| Message-ID | <jikpk7$9lj$1@gosset.csi.cam.ac.uk> |
| In reply to | #6152 |
In article <9r598uFkvhU1@mid.individual.net>, Andrew Reilly <areilly---@bigpond.net.au> wrote: >On Tue, 28 Feb 2012 17:24:23 +0000, nmm1 wrote: > >> Yes, that puts it in a nutshell. There are circumstances where any >> interrupt is bad news, but they are relatively rare and can usually be >> dealt with fairly simply. If, however, the easiest solution is to >> eliminate interrupts entirely, I am happy with that - but, as always, >> with the proviso "if done competently". > >I don't see how it can be done "competently". To my mind, interrupts are >the lesser of two evil approaches. If you remove interrupts, thus vastly >simplifying the (relatively tiny but important) task of task switching, >and also simplifying the models that describe inter-process >communication, you instead burden *every* piece of code on the system, >written by even the newbiest of application coders with the requirement >that no code path exceed N-microseconds between system calls, for some >smallish N. ... No, it doesn't. Firstly, suitably privileged code can be exempt, secondly, it is easy to have an attribute on an executable stating how much time it needs, thirdly, it's NOT particularly difficult in code like that, fourthly, current scheduler intervals are usually 10 MILLI seconds, fifthly, that is what compilers are there for, sixthly, an unused yield point doesn't slow the program down, .... ALL of those are established technologies, and damn few users would even notice. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2012-02-29 10:39 +0000 |
| Message-ID | <9r6digFbseU1@mid.individual.net> |
| In reply to | #6164 |
On Wed, 29 Feb 2012 09:03:03 +0000, nmm1 wrote: > In article <9r598uFkvhU1@mid.individual.net>, > Andrew Reilly <areilly---@bigpond.net.au> wrote: >>On Tue, 28 Feb 2012 17:24:23 +0000, nmm1 wrote: >> >>> Yes, that puts it in a nutshell. There are circumstances where any >>> interrupt is bad news, but they are relatively rare and can usually be >>> dealt with fairly simply. If, however, the easiest solution is to >>> eliminate interrupts entirely, I am happy with that - but, as always, >>> with the proviso "if done competently". >> >>I don't see how it can be done "competently". To my mind, interrupts >>are the lesser of two evil approaches. If you remove interrupts, thus >>vastly simplifying the (relatively tiny but important) task of task >>switching, and also simplifying the models that describe inter-process >>communication, you instead burden *every* piece of code on the system, >>written by even the newbiest of application coders with the requirement >>that no code path exceed N-microseconds between system calls, for some >>smallish N. ... > > No, it doesn't. > > Firstly, suitably privileged code can be exempt, secondly, it is easy to > have an attribute on an executable stating how much time it needs, > thirdly, it's NOT particularly difficult in code like that, fourthly, > current scheduler intervals are usually 10 MILLI seconds, fifthly, that > is what compilers are there for, sixthly, > an unused yield point doesn't slow the program down, .... > > ALL of those are established technologies, and damn few users would even > notice. And yet those of us who have been down that path are glad that we aren't there any more. At least when that path is determined entirely in software. I imagine that a hardware-based approach, where (for example, and as has been suggested) every taken branch was an implicit yield point could work pretty well, but I've not encountered a system like that. The point is that the yield points have to cost exactly zero, or else they dominate the cost of very tiny loop bodies. (On x86 and the like, you would also have to somehow limit the iteration counts of the rep-mov (string/block) instructions.) There are still systems that require secure compilers, but they're not particularly popular either. Yes, your system's timer interrupts might run at 10ms, but most are around 1ms these days, and I doubt that you'd want even that much to be the lower limit for network packet response or other sequentially dependent events. You can burn up a lot of time, one ms at a time. Been there, done that. Happy to put up with the difficulties presented by asynchronous interrupts. Cheers, -- Andrew
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 13:10 +0000 |
| Message-ID | <jil83l$tsb$1@gosset.csi.cam.ac.uk> |
| In reply to | #6169 |
In article <9r6digFbseU1@mid.individual.net>, Andrew Reilly <areilly---@bigpond.net.au> wrote: >> >And yet those of us who have been down that path are glad that we aren't >there any more. On how many 16+ core chips have you been there? Please do tell. What you are missing is that the ability to have an essentially unlimited number of small, slow cores is a game changer. > I imagine that a hardware-based approach, where (for example, >software. I imagine that a hardware-based approach, where (for example, >and as has been suggested) every taken branch was an implicit yield point >could work pretty well, but I've not encountered a system like that. The >point is that the yield points have to cost exactly zero, or else they >dominate the cost of very tiny loop bodies. ... As I posted, I was proposing a simple hardware instruction with almost precisely such a cost! >Yes, your system's timer interrupts might run at 10ms, but most are >around 1ms these days, and I doubt that you'd want even that much to be >the lower limit for network packet response or other sequentially >dependent events. You can burn up a lot of time, one ms at a time. Sigh. For the Nth time, I was talking about dedicating a core to every device (or at least every bus). That just isn't an issue. >Been there, done that. Happy to put up with the difficulties presented >by asynchronous interrupts. So you don't give a damn about low RAS on anything except the sort of embedded system where ALL of the software is cooperating to ensure that the asynchronous interrupt handling is reliable? Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2012-02-29 23:08 +0000 |
| Message-ID | <9r7peoFtjjU1@mid.individual.net> |
| In reply to | #6170 |
On Wed, 29 Feb 2012 13:10:13 +0000, nmm1 wrote: > In article <9r6digFbseU1@mid.individual.net>, > Andrew Reilly <areilly---@bigpond.net.au> wrote: >>> >>And yet those of us who have been down that path are glad that we aren't >>there any more. > > On how many 16+ core chips have you been there? Please do tell. > What you are missing is that the ability to have an essentially > unlimited number of small, slow cores is a game changer. Multi-core: none. My excursions into cooperative tasking have all been single-core. Shared memory multi-core has the asynchronous aliasing problem whether you have interrupts or not, right? So that's kind of a red herring, I think. I think that I agree with you that multi-core probaby makes the practical need for low-latency time-sharing go away, but I'm not entirely sure about that. Not sure how you could really make sure there weren't gotchas without doing the experiment. Since that would require both different processors and different code, that sounds like a fairly herculean ground-up effort. I'd like to see it, but I doubt that I will. >> I imagine that a hardware-based approach, where (for example, >>software. I imagine that a hardware-based approach, where (for example, >>and as has been suggested) every taken branch was an implicit yield >>point could work pretty well, but I've not encountered a system like >>that. The point is that the yield points have to cost exactly zero, or >>else they dominate the cost of very tiny loop bodies. ... > > As I posted, I was proposing a simple hardware instruction with almost > precisely such a cost! OK. I'd like to see that, in fact. Given the out-of-order nature of current (and likely future) processors, they would still need herioic memory ordering mechanism to give even synchronous task switches the single-task semantics that the software will be expecting. If you have that, then I'm not sure I'm convinced that the special yield instruction, or special branch semantics necessarily help. >>Yes, your system's timer interrupts might run at 10ms, but most are >>around 1ms these days, and I doubt that you'd want even that much to be >>the lower limit for network packet response or other sequentially >>dependent events. You can burn up a lot of time, one ms at a time. > > Sigh. For the Nth time, I was talking about dedicating a core to every > device (or at least every bus). That just isn't an issue. I still think that it would be tricky to avoid the problems of cooperative systems of the past, that would often lock-up waiting for network packets, or disk paging. I expect that it could be done, but then you're back in the realm of requiring *all* or at least a large chunk of the software base to have the appropriate degree of "competence". Certainly, sufficient incompetence can still produce similar lockups in an asynchronous interrupt environment, so it isn't all a win. The best performance I ever managed with a software cooperative system was a little over 10% of the processor time being spent in the three- instruction "yield" macro. The same functionality with interrupts burned less than half of that in non-functional FLIH code, and the payback was significantly simpler application code and greatly reduced debugging and tuning (yield-location) effort. So count me once-bitten. On the other hand, I also have experience with spreading the same problem across multiple processors, so that each of the different rate-specific tasks had their own core. In a situation like that, a cooperative system would be easy. Not necessarily efficient, unless all of the rate-tiers have the same or similar computational load. Physical process placement competes with whole-system throughput in non-trivial ways. Perhaps abundance can make that a smaller concern... Largest system I ever put together with that software structure had 20 processors, I think. >>Been there, done that. Happy to put up with the difficulties presented >>by asynchronous interrupts. > > So you don't give a damn about low RAS on anything except the sort of > embedded system where ALL of the software is cooperating to ensure that > the asynchronous interrupt handling is reliable? No, you have that exactly backwards. I like high RAS on everything with a competently-written interrupt handling framework and runtime/OS, because I don't expect all of the software running to be competently cooperating. I also like the high reliability *and* real-time low latency that I can get on embedded systems that have well-prioritised, asynchronously interrupted processes. Cheers, -- Andrew
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 23:36 +0000 |
| Message-ID | <jimcq1$577$1@gosset.csi.cam.ac.uk> |
| In reply to | #6196 |
In article <9r7peoFtjjU1@mid.individual.net>, Andrew Reilly <areilly---@bigpond.net.au> wrote: >>>> >>>And yet those of us who have been down that path are glad that we aren't >>>there any more. >> >> On how many 16+ core chips have you been there? Please do tell. >> What you are missing is that the ability to have an essentially >> unlimited number of small, slow cores is a game changer. > >Multi-core: none. My excursions into cooperative tasking have all been >single-core. Shared memory multi-core has the asynchronous aliasing >problem whether you have interrupts or not, right? So that's kind of a >red herring, I think. No, it's not. A device driver doesn't share memory with a user's application. >OK. I'd like to see that, in fact. Given the out-of-order nature of >current (and likely future) processors, they would still need herioic >memory ordering mechanism to give even synchronous task switches the >single-task semantics that the software will be expecting. One doesn't HAVE to implement the yield instruction incompetently, you know! It would actually simply software considerably, as you can see by the codes that use signal masking (ugh) for just that purpose. >I still think that it would be tricky to avoid the problems of >cooperative systems of the past, that would often lock-up waiting for >network packets, or disk paging. I expect that it could be done, but >then you're back in the realm of requiring *all* or at least a large >chunk of the software base to have the appropriate degree of >"competence". Certainly, sufficient incompetence can still produce >similar lockups in an asynchronous interrupt environment, so it isn't all >a win. Having done both, I can assure you that it is MUCH easier to get that right with parallelism than with asynchronous interrupts. >The best performance I ever managed with a software cooperative system >was a little over 10% of the processor time being spent in the three- >instruction "yield" macro. The same functionality with interrupts burned >less than half of that in non-functional FLIH code, and the payback was >significantly simpler application code and greatly reduced debugging and >tuning (yield-location) effort. So count me once-bitten. I know half a dozen people who have had exactly the converse experience, but you are STILL missing the point that silicon is almost free nowadays! Who cares whether 90% of the service core time is wasted, if there is lashings of it? >No, you have that exactly backwards. I like high RAS on everything with >a competently-written interrupt handling framework and runtime/OS, >because I don't expect all of the software running to be competently >cooperating. I also like the high reliability *and* real-time low >latency that I can get on embedded systems that have well-prioritised, >asynchronously interrupted processes. That is the easy, indeed almost trivial, case. Now try a general-purpose system running applications written by a variety of not-entirely competent, not-entirely cooperative third parties. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2012-03-01 15:32 -0500 |
| Message-ID | <hlmvk7dl4ap8nmcnn24d8pol2c711mf8ea@4ax.com> |
| In reply to | #6197 |
On Wed, 29 Feb 2012 23:36:33 +0000 (GMT), nmm1@cam.ac.uk wrote: >In article <9r7peoFtjjU1@mid.individual.net>, >Andrew Reilly <areilly---@bigpond.net.au> wrote: > >>Shared memory multi-core has the asynchronous aliasing >>problem whether you have interrupts or not, right? So that's kind of a >>red herring, I think. > >No, it's not. A device driver doesn't share memory with a user's >application. A driver that operates directly on user provided buffers certainly is sharing memory with the application. I suppose an argument can be made that a driver initiating DMA technically is not "sharing" the buffer, but IMO that is just semantics ... correct operation demands that the application can't touch the buffer while the driver is "using" it (for whatever definition of "using"). George
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-03-01 20:52 +0000 |
| Message-ID | <jionhl$d61$1@gosset.csi.cam.ac.uk> |
| In reply to | #6205 |
In article <hlmvk7dl4ap8nmcnn24d8pol2c711mf8ea@4ax.com>, George Neuner <gneuner2@comcast.net> wrote: >> >>>Shared memory multi-core has the asynchronous aliasing >>>problem whether you have interrupts or not, right? So that's kind of a >>>red herring, I think. >> >>No, it's not. A device driver doesn't share memory with a user's >>application. > >A driver that operates directly on user provided buffers certainly is >sharing memory with the application. I suppose an argument can be >made that a driver initiating DMA technically is not "sharing" the >buffer, but IMO that is just semantics ... correct operation demands >that the application can't touch the buffer while the driver is >"using" it (for whatever definition of "using"). Sigh. The context was that of an interrupt for a probably unrelated request. Even if it IS for the same process, the point you mentioned means that it brings in none of the semantic issues of shared memory. Between initiating the I/O and being told that it has completed, the application may not even have access to the memory. Outside the I/O call, the device driver is similarly constrained. And even that applies SOLELY to transfer buffers. ALL other memory is entirely in the application or entirely in the driver, except (on some systems) while arguments are being copied between the two. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-28 13:15 -0800 |
| Message-ID | <581ed8f5-b08f-4657-ba02-f7fc36e8bfda@q12g2000yqg.googlegroups.com> |
| In reply to | #6143 |
On Feb 28, 9:45 am, MitchAlsup <MitchAl...@aol.com> wrote: > I disagree that Nick does not like interrupts. What Nick does not like is architectures that make the writing of interrupt handlers require the skill and patience of brain surgens in order to write code to reliably handle interrupts. I agree with Nick, here. I'd agree with that, too. But if that's what he is saying, he seems also to be saying that all architectures, or at least all modern architectures, with interrupts are like that. In the case of "modern architectures", that may well be true, I don't know. When it comes to humble systems like the PDP-8 or the Motorola 6800 (yes, the 8-bit one), however. I really doubt that interrupts "didn't work" in any reasonable sense of the phrase on those systems. And I'm suspecting that in the case of modern microprocessors, the problems with interrupts he is citing may be caused more by the quirks of modern operating systems than by the hardware - due to his mention of signals in POSIX in one post. John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-28 22:28 +0000 |
| Message-ID | <jijke6$86d$1@gosset.csi.cam.ac.uk> |
| In reply to | #6149 |
In article <581ed8f5-b08f-4657-ba02-f7fc36e8bfda@q12g2000yqg.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: >On Feb 28, 9:45=A0am, MitchAlsup <MitchAl...@aol.com> wrote: > >> I disagree that Nick does not like interrupts. What Nick does not like is= > architectures that make the writing of interrupt handlers require the skil= >l and patience of brain surgens in order to write code to reliably handle i= >nterrupts. I agree with Nick, here. > >I'd agree with that, too. But if that's what he is saying, he seems >also to be saying that all architectures, or at least all modern >architectures, with interrupts are like that. As I have said repeatedly, the problems are fundamental. That does not mean that they cannot be resolved by heroic efforts on the part of CPU architects, operating system designers and language run-time system designers, but it DOES mean that such heroic efforts are required - and by all of them, in cooperation. Now, back in the real world, that isn't what happens. >When it comes to humble systems like the PDP-8 or the Motorola 6800 >(yes, the 8-bit one), however. I really doubt that interrupts "didn't >work" in any reasonable sense of the phrase on those systems. As I said, please don't use misrepresentations as an indication of what I said. >And I'm suspecting that in the case of modern microprocessors, the >problems with interrupts he is citing may be caused more by the quirks >of modern operating systems than by the hardware - due to his mention >of signals in POSIX in one post. That is true. Now, I suggest that you try to design an operating system interface that (a) is implementable for reasonable effort on most modern systems and (b) is usable with reasonable reliability by language run-time systems and applications. Go on - the mental exercise will be good for you :-) Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-28 16:13 -0800 |
| Message-ID | <23c57d6f-9b53-4336-9ec6-4b9d1a401f91@t16g2000yqt.googlegroups.com> |
| In reply to | #6150 |
On Feb 28, 3:28 pm, n...@cam.ac.uk wrote: > As I have said repeatedly, the problems are fundamental. That does > not mean that they cannot be resolved by heroic efforts on the part > of CPU architects, operating system designers and language run-time > system designers, but it DOES mean that such heroic efforts are > required - and by all of them, in cooperation. > That is true. Now, I suggest that you try to design an operating > system interface that (a) is implementable for reasonable effort on > most modern systems and (b) is usable with reasonable reliability > by language run-time systems and applications. Go on - the mental > exercise will be good for you :-) Oh. Now I think I see the source of my confusion. What's this about "language run-time systems"? You're seriously suggesting that anyone in his right mind would try to write any code for those portions of an operating system that handle interrupts in a *higher-level language* (although I've heard rumors that C is a possible exception to this rule) where the programmer doesn't really have any control over whether or not his code is going to (as a random example inspired by other posts in this discussion) generate calls to non-reentrant subroutines? In that case, I agree with you wholeheartedly. Interrupts and higher- level languages do not mix, and if it's impossible to get away from higher-level languages on modern machines (the Itanium certainly is an example of an architecture that bids fair to either drive insane or cause to go blind anyone who would attempt extensive programming thereof in assembly language) then interrupts on modern architectures are indeed toxic - even if this toxicity is kept to a dull roar by whatever kludges may be generally employed. I regret doubting you: it is that I lack imagination, and thus fail to realize the depths of stupidity to which certain sectors of the computing world can sink. John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 10:04 +0000 |
| Message-ID | <jikt70$9sc$1@gosset.csi.cam.ac.uk> |
| In reply to | #6151 |
In article <23c57d6f-9b53-4336-9ec6-4b9d1a401f91@t16g2000yqt.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > >> As I have said repeatedly, the problems are fundamental. That does >> not mean that they cannot be resolved by heroic efforts on the part >> of CPU architects, operating system designers and language run-time >> system designers, but it DOES mean that such heroic efforts are >> required - and by all of them, in cooperation. > >> That is true. Now, I suggest that you try to design an operating >> system interface that (a) is implementable for reasonable effort on >> most modern systems and (b) is usable with reasonable reliability >> by language run-time systems and applications. Go on - the mental >> exercise will be good for you :-) > >Oh. Now I think I see the source of my confusion. What's this about >"language run-time systems"? You're seriously suggesting that anyone >in his right mind would try to write any code for those portions of an >operating system that handle interrupts in a *higher-level language* >(although I've heard rumors that C is a possible exception to this >rule) where the programmer doesn't really have any control over >whether or not his code is going to (as a random example inspired by >other posts in this discussion) generate calls to non-reentrant >subroutines? Well, we did it on the mainframes, which is where I have implemented it as a first-class facility (even for C, which is actually LESS capable of it than most other languages, except for C++). However, if you exclude that, you are saying that no mere peasant of an application author should be allowed to use anything other than polling. Interrupt handling is reserved for the hoi eloi. That's bad system design, and encourages people to write privileged code when it shouldn't be. Look at MVT for an example of THAT! Also, you are saying that POSIX is a disaster area and should be abandoned (in which case, I agree with you), because it ALSO means that you need to abolish EINTR and change many of its functions' interfaces to return correct data irrespective of an internal interrupt. Well, good luck to you in getting that one across :-) Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-29 10:26 -0800 |
| Message-ID | <93a54518-e6fd-4578-931d-5f67ba141c17@1g2000yqv.googlegroups.com> |
| In reply to | #6167 |
On Feb 29, 3:04 am, n...@cam.ac.uk wrote: > However, if you exclude that, you are saying that no mere peasant of > an application author should be allowed to use anything other than > polling. Interrupt handling is reserved for the hoi eloi. That's > bad system design, and encourages people to write privileged code > when it shouldn't be. Look at MVT for an example of THAT! Interrupt handling is reserved for the people who maintain the operating system, as opposed to applications authors who do not have privileged access to the system. However, they don't engage in polling either; they don't do I/O themselves, and that would be extremely wasteful. I have no objection to them using "on condition" constructs in their languages, however. That isn't writing code to service interrupts, even if it looks similar. Of course, in today's world of computing, people do have complete access to their computers, because they own the computer, and they don't have to worry about being charged a lot of money at the end of a batch job because they made the mistake of using polling. That changed situation, though, hasn't much changed the right way to use a computer efficiently. John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 18:28 +0000 |
| Message-ID | <jilqnh$3jd$1@gosset.csi.cam.ac.uk> |
| In reply to | #6182 |
In article <93a54518-e6fd-4578-931d-5f67ba141c17@1g2000yqv.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > >> However, if you exclude that, you are saying that no mere peasant of >> an application author should be allowed to use anything other than >> polling. Interrupt handling is reserved for the hoi eloi. That's >> bad system design, and encourages people to write privileged code >> when it shouldn't be. Look at MVT for an example of THAT! > >Interrupt handling is reserved for the people who maintain the >operating system, as opposed to applications authors who do not have >privileged access to the system. However, they don't engage in polling >either; they don't do I/O themselves, and that would be extremely >wasteful. > >I have no objection to them using "on condition" constructs in their >languages, however. That isn't writing code to service interrupts, >even if it looks similar. So you would abolish C and POSIX signal handling? :-) Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-29 11:24 -0800 |
| Message-ID | <086f5908-77a7-4b3c-9c61-5c92f223b457@b1g2000yqb.googlegroups.com> |
| In reply to | #6183 |
On Feb 29, 11:28 am, n...@cam.ac.uk wrote: > In article <93a54518-e6fd-4578-931d-5f67ba141...@1g2000yqv.googlegroups.com>, > Quadibloc <jsav...@ecn.ab.ca> wrote: > >I have no objection to them using "on condition" constructs in their > >languages, however. That isn't writing code to service interrupts, > >even if it looks similar. > > So you would abolish C and POSIX signal handling? :-) I think that C signal handling at least has the potential of being within the category of things I would allow, depending, of course, on how it is implemented. As long as a "signal" isn't a real interrupt, just something that the operating system has already predigested, I don't have an objection... even though there is, of course, still a similar potential for causing problems to an applications program, if the language feature wasn't properly supported. It goes without saying that a compiler writer needs to properly support the features of the language that it claims to compile. The possibility of failure in the quest to achieve this goal is not a reason to abolish a language feature, because in that case one would have to abolish every language feature: i.e. no language could have trig function libraries, because they could have errors. John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 19:32 +0000 |
| Message-ID | <jilug5$3v9$1@gosset.csi.cam.ac.uk> |
| In reply to | #6187 |
In article <086f5908-77a7-4b3c-9c61-5c92f223b457@b1g2000yqb.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > >> >I have no objection to them using "on condition" constructs in their >> >languages, however. That isn't writing code to service interrupts, >> >even if it looks similar. >> >> So you would abolish C and POSIX signal handling? :-) > >I think that C signal handling at least has the potential of being >within the category of things I would allow, depending, of course, on >how it is implemented. As long as a "signal" isn't a real interrupt, >just something that the operating system has already predigested, I >don't have an objection... even though there is, of course, still a >similar potential for causing problems to an applications program, if >the language feature wasn't properly supported. Er, I don't think that you understand the problem. I have implemented signal handling for C that even allowed recursive interrupts, but wouldn't know how to start under a POSIX or Microsoft system if I wanted to make it even reasonably reliable for even non-recursive interrupts. There is FAR more involved than the operating system "predigesting" the interrupt, and as far as I know no current mainstream system provides enough functionality to the author of the language run-time system to get it right. Even if those people have the extremely unusual combination of skills needed to do so. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Felsche <berfel@innovative.iinet.net.au> |
|---|---|
| Date | 2012-03-01 03:37 +0800 |
| Message-ID | <gcb229xkel.ln2@innovative.iinet.net.au> |
| In reply to | #6183 |
nmm1@cam.ac.uk wrote: >Quadibloc <jsavard@ecn.ab.ca> wrote: >>> However, if you exclude that, you are saying that no mere peasant of >>> an application author should be allowed to use anything other than >>> polling. Interrupt handling is reserved for the hoi eloi. That's >>> bad system design, and encourages people to write privileged code >>> when it shouldn't be. Look at MVT for an example of THAT! >>Interrupt handling is reserved for the people who maintain the >>operating system, as opposed to applications authors who do not have >>privileged access to the system. However, they don't engage in polling >>either; they don't do I/O themselves, and that would be extremely >>wasteful. >>I have no objection to them using "on condition" constructs in their >>languages, however. That isn't writing code to service interrupts, >>even if it looks similar. >So you would abolish C and POSIX signal handling? :-) Not necessary to abolish if one can simply ignore what doesn't work. Don't buy the jacket if it doesn't fit. -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | For every complex problem there is an X against HTML mail | answer that is clear, simple, and wrong. / \ and postings | --HL Mencken
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-02-29 12:14 -0500 |
| Message-ID | <65t3r.2733$HX7.1008@newsfe11.iad> |
| In reply to | #6151 |
Quadibloc wrote: > > Oh. Now I think I see the source of my confusion. What's this about > "language run-time systems"? You're seriously suggesting that anyone > in his right mind would try to write any code for those portions of an > operating system that handle interrupts in a *higher-level language* > (although I've heard rumors that C is a possible exception to this > rule) where the programmer doesn't really have any control over > whether or not his code is going to (as a random example inspired by > other posts in this discussion) generate calls to non-reentrant > subroutines? Yes and no. For most languages the compiler generates fully reentrant code if you write reentrant code. An exception to this would be Fortran 77 where the language rules allow routine local vars to be allocated in static memory. However most languages are not so brain damaged. The C standard run time libraries are NOT fully reentrant. That is why, at least for WNT, you are not allowed to call them inside the kernel. There is set of kernel library routines that are safe to use. The C language itself is safe for writing ISR's and drivers and the vast majority (99.999%) of the WNT. Only a tiny portion is written in assembler. This is exactly what one wants because the major investment is in the large amount of portable kernel code. Eric
[toc] | [prev] | [next] | [standalone]
Page 14 of 20 — ← Prev page 1 … 12 13 [14] 15 16 … 20 Next page →
Back to top | Article view | comp.arch
csiph-web