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 12 of 20 — ← Prev page 1 … 10 11 [12] 13 14 … 20 Next page →
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-02-27 15:22 -0500 |
| Message-ID | <5CR2r.19160$HR6.16050@newsfe21.iad> |
| In reply to | #6101 |
Michael S wrote: > On Feb 26, 8:05 pm, EricP <ThatWouldBeTell...@thevillage.com> wrote: >> Michael S wrote: >>> On Feb 26, 12:09 pm, n...@cam.ac.uk wrote: >>>> In article <4F49DE8B.9060...@SPAM.comp-arch.net>, >>>>> But interrupt like facilities for user programs have never quite taken off. >>>> That is true. I have implemented them, because mainframes did support >>>> them (unlike Unices and derivatives, like Microsoft), >>> Microsoft [Windows NT family of operation systems] supports user-level >>> asynchronous signals? Since when? >> Apparently it always did just as VMS did, >> only for WinNT it was undocumented. >> MS reserve unto themselves the right to use this, >> and supposedly elsewhere the delivery mechanism is lobotomized >> so it will only deliver true user mode asynchronous thread >> interrupts to a specific set of destinations >> (references to KeUserModeCallback come up a lot). > > I don't see anything in your links that violates my assertion. The way I read it, user APC's would by default be delivered on the next kernel to user transition if the kernel thread's Alertable flag is set (irrespective of synchronization). That K->U transition would occur, for example, after the next interrupt or syscall. However as the normal Windows routines only allow Alertable to be set True at specific "polling" points the effect to make them synchronous. IOW, if you could somehow set a single boolean flag in the kernel thread header, it would do what you want. > Of course, as in any OS that is based on monolithic kernel, Nt kernel- > mode device driver *can* do just about everything to user thread. > However *correct* device driver has to limit itself to documented > interfaces and follow DDK guides. And, as long as driver uses > documented interfaces and follows DDK guides, APCs are delivered to > user threads only in synchronous manner, i.e. in well defined points. MS never felt terribly obliged to color inside the lines and look where they got. > BTW, I feel that "asynchronous procedure call" is a very bad name. > They should have call this mechanism "queued procedure call" or > something like that. "Deferred procedure call" would be the best name > if there was no danger of confusion with kernel mode namesake. Yes. I think they should have both real, maskable user mode APC's and polled Synchronized Callbacks SCB's (= current user APC's). For things like IO completion or QueueUserXxx the programmer gets to decide which is appropriate. If you use real APC's then you must take care to disable them when in non reentrant code like heaps. Currently there is no way to force a Windows thread to do your bidding. You can use QueueUserApc but if the thread never polls its alerts, nothing happens. Eric
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-27 09:21 -0800 |
| Message-ID | <4F4BBB9B.7050300@SPAM.comp-arch.net> |
| In reply to | #6091 |
On 2/26/2012 2:09 AM, nmm1@cam.ac.uk wrote: > In article<4F49DE8B.9060104@SPAM.comp-arch.net>, > Andy (Super) Glew<andy@SPAM.comp-arch.net> wrote: >> >> In my own conversation with Nick he said something about UNIX signals. >> >> Perhaps this is what he means, or should mean: > > This is getting ridiculous. I have NO idea why you regard interrupts > as Holy Dogma, but it is preventing you from actually thinking either > about their problems or about alternatives. I don't regard interrupts as Holy Dogma. However, none of the suggestions you put forward for eliminating interrupts make sense. I am willing to posit that you, being a fairly smart guy, have reasons for what you are saying. I am trying to figure out what those reasons are, since you seem to be unable to explain them. However, the most likely scenario seems to be that you are mistaken. For example, earlier in this conversation I mentioned what I call hardware cooperative multitasking - require that there be an interrupt safe point periodically, e.g. a taken branch, or a special "interrupt safe marking". And, if too long a time passes without such a safe point, it is deemed an error, and a non-recoverable interrupt is generated. In most situations, that would be a user program error, with the user program being killed, but the OS keeping going. If the OS was the SW responsible, it would be an OS error, and the OS would be killed, but a VMM might keep going, etc. This is the only scenario I have understood where asynchronous interrupts could be eliminated. You seemed to concur that this was something along the lines of what you were talking about. You seemed to say that that what I call HW cooperative multitasking is what you were calling a semi-synchronous solution. I say "seem" because I am not 100% sure - it is hard to pin you down, Nick, and understand your precise meaning.Undoubtedly because of cultural and linguistic differences - you are English, I am Canadian with English parents, who spent much of my childhood in England, so it is quite understandable that we should not be able to understand one another. Now, let me be clear: that HW cooprative multitasking is the ONLY way that I currently understand that your agenda of eliminating asynchronous interrupts could work. If there is another way, please explain. Please do not slip out of it by saying that there are many other ways obvious to anyone who has an ounce of brain. Also, you keep saying that asynchronous interrupts have proven to be a bad idea. But I do not recall ever seeing a real example of such proof. And I must admit that I am puzzled, since pretty much all modern computers use asynchronous interrupts. It's wonderful to imagine that we can throw everything out and start over, but that would be silly unless there is an alternative that is reasonably likely to succeed. As explained above, I keep trying to pin you down on what you think such an alternative might be, but never really get an answer. At the moment, the HW cooperative multitasking idea, which I think you call a "semi-synchronous" solution, is the only alternative I can imagine. (Actually, I am also willing to imagine SW cooperative multitasking, especially in the context of a dynamic or interpreted language.) Anyway: I would love to see a credible example of why you think interrupts have such major RAS problems. BTW, I agree that many *implentations* of interrupts have RAS problems. Especially those that try to optimize state saving. But as far as I can tell the basic idea of interrupts - act AS IF you have stopped at a single place in the code, with precise state - is workable. Of course, that requires the notion of a precise state. Anyway^2...: I would love to see your examples. Now, let me say this: I try to understand the mindset of the people I am talking to. At the moment, my guess as to your mindset and motivation is that you *have* had to debug many interesting RAS problems with interrupts. Particularly since you have long worked at an interesting academic computer facility, where not only do you get leading edge hardware, but you also have worked with lots of advanced and prototype British and European computers. I'm guessing that worked with various ARMs, Meikos, Transputers, Ferrantes. And probably some academic prototype machines. And that you put idiosyncratic OSes and runtimes on many more mass market machines. Anyway, I am guessing that, because of this experience, you have encountered many challenging problems with interrupts, and that because of this you may have said to yourself "Wouldn't it be better if there were no asynchronous interrupts." Or even possibly that you worked with some systems, British and otherwise, that did not have asynchronous interrupts at all, and observed that they had far fewer problems. E.g. I believe the Transputer runtime was like this. OK, me saying stuff like this sometimes infuriates people, in particular one famous professor "You have no right to speak for me". (But it turned out that, while I had no right, I was correct.) Anyway, Nick: I am trying to understand why you are making what I believe to be an incorrect overgeneralization about interrupts. I am trying to get behind imprecise words, and/or get more precise words. Are you willing to try to communicate more clearly? Or, perhaps, just write me off as a useless case. > >> * UNIX signal handlers are, in some ways, an attempt to make a facility >> like asynchronous interrupts available to user code >> >> * UNIX signal handlers are not a terribly big success. At times people >> have said that the only thing you can reliably do in a signal handler is >> exit the program without printing an error message. That is an >> exaggeration - I use signals on a regular basis to monitor long running >> simulations. But I think it is fair to say that signals don't live up >> to what one might hope. > > Actually, it's an understatement, for reasons that you should know. > Start by reading the POSIX 'specification' and then try to work out > how you would write a signal-safe run-time system and libraries, > remembering that they are often written by non-experts. And the > answer is that there are always parts of the run-time system that > will fail if interrupted by a signal, even with a null handler. > Nowadays, with very low probability, which is why you claim that > it doesn't happen. OK, so you are just being stronger and more forceful than me. And more categorical. By the way, I did NOT know that there were places that were unsafe, even with a null signal handler. What are these places? (Although, by the way, POSIX is certainly not a religion to me.) > >> Obviously, interrupts work well enough, since pretty much all modern >> computers use them. But this is at OS level. > > Clearly my standards are considerably higher than yours, or you are > being very blinkered. If you have never some across any of the > serious problems they cause, then you haven't been observant. As I > have posted, I have found at least one serious bug on every system > I have ever used extensively, and on many that I have not. But I > DO have a lot of implementation experience here, and DO know how to > recognise the symptoms and check whether I am right. > > You do know how much trouble this caused systems on the early x86s, > which is one reason that signals are so cocked-up in the C and POSIX > standards? And on the Itanic? That had several such problems :-) > Note that this is hardware misdesigns leading to operating system > misdesigns leading to language run-time system misdesigns leading to > language standard misdesigns .... I don't know of early x86 problems, because I was not at Intel at that time. I know of many Itanium problems, but I believe all were fixable, and fixed. Although I will say that Itanium was one of those places where some of the architects were willing to take shortcuts. (Fortunately, GH did not.) Anyway: if something is not publicly known about Itanium, I am not free to discuss it. I am still under Intel NDAs. But if you know examples of such problems that you are free to discuss, that you are not under NDA for, please, Please, PLEASE share them. >> But interrupt like facilities for user programs have never quite taken off. > > That is true. I have implemented them, because mainframes did support > them (unlike Unices and derivatives, like Microsoft), and have been > involved with them at all levels from language standards to the FLIH > and even hardware. I have met two other people who have implemented > them, and no of one other, but I should be surprised if there were > more than a dozen people still working with comparable experience. I started architecting and implementing such a facility for Gould Real Time UNIX. But the POSIX standardization sidetracked my work in that area. This is one of the reasons that I look with a jaundiced eye on POSIX. And, I admit that I have only ever worked on such stuff at the OS and/or HW level. I have only worked with language and runtime developers, but never actually on languages and runtimes. Anyway, Nick, you probably have much more experience in this area. Which is why I ask for you to share that experience. Details, because the level that you have shared so far to me seems logically incomplete, and even incorrect.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-27 19:47 +0000 |
| Message-ID | <jigmkj$k9o$1@gosset.csi.cam.ac.uk> |
| In reply to | #6116 |
In article <4F4BBB9B.7050300@SPAM.comp-arch.net>,
Andy (Super) Glew <andy@SPAM.comp-arch.net> wrote:
OK, let's get back to technical discussions!
>For example, earlier in this conversation I mentioned what I call
>hardware cooperative multitasking - require that there be an interrupt
>safe point periodically, e.g. a taken branch, or a special "interrupt
>safe marking". And, if too long a time passes without such a safe
>point, it is deemed an error, and a non-recoverable interrupt is
>generated. In most situations, that would be a user program error, with
>the user program being killed, but the OS keeping going. If the OS was
>the SW responsible, it would be an OS error, and the OS would be killed,
>but a VMM might keep going, etc.
Let's go with that one.
Only the kernel thread actually executing need be killed, and (in the
most common and most 'correct' case) that is associated with a stuck
device. Mainframes (like MVS) could survive the most amazing succession
of kernel thread crashes, but we don't need to go there to make this no
less RAS-worthy than at present.
The question of whether such a thread is holding a lock is solved better
under this scheme, because at least you can recover the lock when the
process is killed. Systems that have had uncooperative lock recovery
have never been a great success.
The point about lots of small, simple cores (including one per relevant
device) is that one doesn't even need the hardware cooperative
multitasking, but that's more of a simplification and optimisation than
critical. However, it IS where I came in.
>Also, you keep saying that asynchronous interrupts have proven to be a
>bad idea. But I do not recall ever seeing a real example of such proof.
>
>Anyway: I would love to see a credible example of why you think
>interrupts have such major RAS problems.
>
>BTW, I agree that many *implentations* of interrupts have RAS problems.
> Especially those that try to optimize state saving. But as far as I
>can tell the basic idea of interrupts - act AS IF you have stopped at a
>single place in the code, with precise state - is workable. Of course,
>that requires the notion of a precise state.
Right. Let's go there.
The first theoretical problem is that they introduce arbitrary aliasing
at EVERY location in the interruptible process, between the process and
the interrupt handler plus anything it calls (including another process
in the same parallel application). Like parallelism? Unfortunately,
no, because there is no way of providing a proper, two-sided
synchronisation mechanism, because the interrupted code can't execute
until resumed. One can't even use the simple 'set an in-use bit; update
object; unset in-use bit' method, because that can lead to deadlock, for
the same reason. Well, actually, one can, but one has to assume that
the kernel scheduler will then interrupt the second process to allow the
first to run. And don't even think of relying on time-aware critical
sections and spin-loops!
So one has to absolutely forbid shareable updating (including on files),
write some FIENDISHLY evil interrupt-safe synchronisation, pray that the
scheduler does exactly what you want, or introduce an interrupt-masking
facility - but a mistake with that means that you have the worst of both
worlds. If I recall, MVS added such a facility, had trouble, added an
override, had trouble, added an override to the override, .... That's
why we have to use 'kill -9' so much, and often even 'sudo kill -9' :-(
When one comes down to handlers within a single application, one can say
that a handler must be 'pure' and do no more than use atomic operations.
But that's not enough, because any global data that it reads may be
temporarily corrupt, so all it can do is to set a flag or code that is
solely for that purpose. But how can the interruptible process use
that? Er, only by polling ....
But it also impacts RAS because the semantic analysis ('program
proving') of unrestrained interrupts is virtually impossible, which also
means that their semantics are virtually impossible to specify in
languages and interfaces. So they are left undefined, so no application
that relies on them can be portable or reliable :-( I know how it can
be done, and Ada MIGHT do it, but nothing else that I know of does more
than that.
>By the way, I did NOT know that there were places that were unsafe, even
>with a null signal handler. What are these places?
Any system where even SIGIGN is handled by calling the application back
and having it ignore it can trigger that. The first problem is that the
run-time system must get into an environment that it can at least
execute code and access its global data, and most operating systems are
NOT cooperative! The second is that it must complete and return without
having any of the handler's state propagated back to the interrupted
process - and the same remark applies. And the third is that, in POSIX
unlike in MVS, system calls are usually terminated by any received
signal, and must be restarted - and many are not idempotent!
Getting that right under MVS was hell. I wouldn't know how to start
under POSIX. But all good systems provide interfaces to do that? No
way, Jose! I have looked at the interfaces provided by half-a-dozen
Unices, and they were all inadequate; of the few I tried, some sort-of
worked, and others didn't work at all. At a wild guess, this is
probably the main cause of failure, and not the kernel or hardware.
But it gets worse. Because the hardware typically only does a small
part of the job, the FLIH has to complete it and (as you say is very
often optimised to not save and restore everything). Now what gets
optimised out? Typically the fancier registers and state not used by
the kernel, such as floating-point - the saving of that is left until
there is a full-blown context switch.
So that will fail only if (a) the interrupted program has important data
in the unsaved state and (b) the interrupt handler calls a kernel thread
that changes that state (improperly). We are now talking about a VERY
low-frequency, non-repeatable failure that occurs in an arbitrary user
program. I am one of 2-3 people I know of who has ever tracked such a
bug down without using privilege, and my success rate is VERY low. In
most cases, even I didn't try.
Even if someone does manage to track such a bug down, and print
registers in two consecutive statements, how does he report it? He
first has to get the bug acknowledged - and remember that it's not
repeatable - and then the hardware, operating system and language
run-time system people will all blame each other. And, in the absence
of either program proving or a practical way of bug reporting, such bugs
are unavoidable and almost immortal.
>I don't know of early x86 problems, because I was not at Intel at that time.
>
>I know of many Itanium problems, but I believe all were fixable, and
>fixed. Although I will say that Itanium was one of those places where
>some of the architects were willing to take shortcuts. (Fortunately, GH
>did not.)
>
>Anyway: if something is not publicly known about Itanium, I am not free
>to discuss it. I am still under Intel NDAs.
>
>But if you know examples of such problems that you are free to discuss,
>that you are not under NDA for, please, Please, PLEASE share them.
The early x87 chips ran asynchronously, and interrupts didn't preserve
enough information to restart. That is why C90 specified that SIGFPE
handlers could not be returned from (though, in fact, returning is the
ONLY thing that has a hope in hell of working in most systems).
As you know, the Itanium's register saving in interrupts was complicated
beyond all sanity. I heard that the Linux FLIH got rewritten from
scratch several times (the last time by THE expert) because of this.
Even then, I know of half-a-dozen people who gave up on installed,
paid-for systems because of unreliability that smelled very like
interrupt-related bugs. Also, shortly before release, one HP person
posted a question to Usenet that was demonstrably because of an
interrupt-corrupted floating-point register. I sent him a message
telling him, and offering more advice, but I suspect that he was sat on
by his management!
>Now, let me say this: I try to understand the mindset of the people I am
>talking to.
>
>At the moment, my guess as to your mindset and motivation is that you
>*have* had to debug many interesting RAS problems with interrupts.
Essentially, yes. And, even though my success rate is relatively
extremely high, it's still abysmal.
One reason that I am such an anti-interrupt-head is that I have
experience of implementing interrupt-safe language run-time systems,
tracking down language run-time systems and kernel interrupt-related
bugs in real applications, have looked at the designs of some FLIHs, and
so on. It's because I have the experience and can work at most of the
relevant levels (as you can) that I recognise the symptoms and can
occasionally track the bugs down.
The second reason is not the range of unusual systems, but that HPC
vastly increases the probability of such bugs being visible. The bugs
may well cause one (noticed) misbehaviour a month on an ordinary server
or desktop, but might cause several a day on an HPC system. That both
makes them critical to investigate and makes it easier to do so.
Regards,
Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-28 19:16 -0800 |
| Message-ID | <4F4D987B.5060007@SPAM.comp-arch.net> |
| In reply to | #6123 |
On 2/27/2012 11:47 AM, nmm1@cam.ac.uk wrote:
> In article<4F4BBB9B.7050300@SPAM.comp-arch.net>,
> Andy (Super) Glew<andy@SPAM.comp-arch.net> wrote:
> The question of whether such a thread is holding a lock is solved better
> under this scheme, because at least you can recover the lock when the
> process is killed. Systems that have had uncooperative lock recovery
> have never been a great success.
What sort of lock recovery does UNIX / Linux have, generically?
However, folks like Oracle have stuck lock recovery on top.
>
> The point about lots of small, simple cores (including one per relevant
> device) is that one doesn't even need the hardware cooperative
> multitasking, but that's more of a simplification and optimisation than
> critical. However, it IS where I came in.
But, you do need some way to regain control of cores that software has
run out of control on.
That's either an interrupt, or a way for code running on some other core
to force the runaway into some known state - possibly killing whatever
software is running on it.
In
http://semipublic.comp-arch.net/wiki/Can_asynchronous_interrupts_be_completely_eliminated%3F
I call that "remote control".
There may be some simplifications by only allowing destructive preemption.
On the other hand, when something has runaway and has to be killed, I
like to be able to see what it was doing. I.e. I like to be able to
save its state. And if you have a way of restoring the saved state...
>
>> Also, you keep saying that asynchronous interrupts have proven to be a
>> bad idea. But I do not recall ever seeing a real example of such proof.
>>
>> Anyway: I would love to see a credible example of why you think
>> interrupts have such major RAS problems.
>>
>> BTW, I agree that many *implentations* of interrupts have RAS problems.
>> Especially those that try to optimize state saving. But as far as I
>> can tell the basic idea of interrupts - act AS IF you have stopped at a
>> single place in the code, with precise state - is workable. Of course,
>> that requires the notion of a precise state.
>
> Right. Let's go there.
>
> The first theoretical problem is that they introduce arbitrary aliasing
> at EVERY location in the interruptible process, between the process and
> the interrupt handler plus anything it calls (including another process
> in the same parallel application). Like parallelism? Unfortunately,
> no, because there is no way of providing a proper, two-sided
> synchronisation mechanism, because the interrupted code can't execute
> until resumed. One can't even use the simple 'set an in-use bit; update
> object; unset in-use bit' method, because that can lead to deadlock, for
> the same reason. Well, actually, one can, but one has to assume that
> the kernel scheduler will then interrupt the second process to allow the
> first to run. And don't even think of relying on time-aware critical
> sections and spin-loops!
Ah, now we are getting to the nub.
I agree: I have often found that the best thing to do in an interrupt
handler is initiate a thread and return - and allow the thread to
compete using "normal" thread scheduling.
As we have discussed elsewhere, I am not averse to thinking about having
interrupts (really, I/O events) automatically spawn threads or make
threads runnable. Or queue up messages for some thread. And if the
thread happens to have a core to itself, fine.
Doing so might remove the possibility of the FLIH being messed up.
But, again - this is not a logically complete solution, if there is any
possibility that such a thread or core can run out of control.
>
> So one has to absolutely forbid shareable updating (including on files),
> write some FIENDISHLY evil interrupt-safe synchronisation, pray that the
> scheduler does exactly what you want, or introduce an interrupt-masking
> facility - but a mistake with that means that you have the worst of both
> worlds. If I recall, MVS added such a facility, had trouble, added an
> override, had trouble, added an override to the override, .... That's
> why we have to use 'kill -9' so much, and often even 'sudo kill -9' :-(
Again, I agree: I have seen several block bits for supposedly
non-blockable interrupts.
Any architect who says that "this facility will never be interrupted" is
deluding himself for the short term.
Virtual machines may need to be able to interrupt most OS level
"interrupt blocked" regions. Which is okay ... unless there was
hardware that assumed that could never happen.
> But it also impacts RAS because the semantic analysis ('program
> proving') of unrestrained interrupts is virtually impossible, which also
> means that their semantics are virtually impossible to specify in
> languages and interfaces. So they are left undefined, so no application
> that relies on them can be portable or reliable :-( I know how it can
> be done, and Ada MIGHT do it, but nothing else that I know of does more
> than that.
This addresses the question somebody else - Stephen Fuld - asked about
what he acronymized as SSI/HCM (Semi-Synchronous Interrupts/HW
Cooperative Multitasking). Why is it easier to be interruptible onbly
at certain places, not everywhere? Part of the answer is ease of analysis.
Much of this boils down to atomicity. Very few machines have had ways
of making user software define complex atomic regions. Atomicity is
always relative, so making atomic relative to interrupts would involve
interrupt blocking, usually an OS level facility. Atomicity relative to
other threads and processors is only ever cooperative, using locks.
The great hope of mechanisms such as Transactional Memory, whether HW or
SW, is that they might give us a way of creating atomicity without
having the cooperation of all parties involved.
>
>> By the way, I did NOT know that there were places that were unsafe, even
>> with a null signal handler. What are these places?
>
> Any system where even SIGIGN is handled by calling the application back
> and having it ignore it can trigger that. The first problem is that the
> run-time system must get into an environment that it can at least
> execute code and access its global data, and most operating systems are
> NOT cooperative! The second is that it must complete and return without
> having any of the handler's state propagated back to the interrupted
> process - and the same remark applies. And the third is that, in POSIX
> unlike in MVS, system calls are usually terminated by any received
> signal, and must be restarted - and many are not idempotent!
Fair enough. Many, many, programs do not handle error returns from
system calls properly, let alone EINTR.
IMHO most programs would be better off dying when such errors are
thrown. (Not quite Freudian slip there.)
> But it gets worse. Because the hardware typically only does a small
> part of the job, the FLIH has to complete it and (as you say is very
> often optimised to not save and restore everything). Now what gets
> optimised out? Typically the fancier registers and state not used by
> the kernel, such as floating-point - the saving of that is left until
> there is a full-blown context switch.
>
> So that will fail only if (a) the interrupted program has important data
> in the unsaved state and (b) the interrupt handler calls a kernel thread
> that changes that state (improperly). We are now talking about a VERY
> low-frequency, non-repeatable failure that occurs in an arbitrary user
> program. I am one of 2-3 people I know of who has ever tracked such a
> bug down without using privilege, and my success rate is VERY low. In
> most cases, even I didn't try.
>
> Even if someone does manage to track such a bug down, and print
> registers in two consecutive statements, how does he report it? He
> first has to get the bug acknowledged - and remember that it's not
> repeatable - and then the hardware, operating system and language
> run-time system people will all blame each other. And, in the absence
> of either program proving or a practical way of bug reporting, such bugs
> are unavoidable and almost immortal.
Fair enough.
Although this is consistent with my observation that premature
optimization is the cause of many, if not most, such problems.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2012-02-29 05:07 +0000 |
| Message-ID | <9r5q3rF2ckU1@mid.individual.net> |
| In reply to | #6158 |
On Tue, 28 Feb 2012 19:16:11 -0800, Andy (Super) Glew wrote: > As we have discussed elsewhere, I am not averse to thinking about having > interrupts (really, I/O events) automatically spawn threads or make > threads runnable. Or queue up messages for some thread. And if the > thread happens to have a core to itself, fine. I'm pretty sure that that's exactly how the "interrupt handlers" in several (most?) modern OSes actually work. Certainly current versions of FreeBSD do that: device "interrupts" have their own kernel thread, and the only purpose of the hardware FLIH is to mark the corresponding thread runnable (and presumably exit through the scheduler somehow? I've never actually looked at the code.) Seems less efficient than just queuing data, but I suspect that it addresses some of these issues of use of multiple cores, OS priority levels and OS locking mechanisms. Cheers, -- Andrew
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-02-29 10:49 -0500 |
| Message-ID | <8Pr3r.2729$HX7.1643@newsfe11.iad> |
| In reply to | #6161 |
Andrew Reilly wrote: > On Tue, 28 Feb 2012 19:16:11 -0800, Andy (Super) Glew wrote: > >> As we have discussed elsewhere, I am not averse to thinking about having >> interrupts (really, I/O events) automatically spawn threads or make >> threads runnable. Or queue up messages for some thread. And if the >> thread happens to have a core to itself, fine. > > I'm pretty sure that that's exactly how the "interrupt handlers" in > several (most?) modern OSes actually work. Certainly current versions of > FreeBSD do that: device "interrupts" have their own kernel thread, and > the only purpose of the hardware FLIH is to mark the corresponding thread > runnable (and presumably exit through the scheduler somehow? I've never > actually looked at the code.) Seems less efficient than just queuing > data, but I suspect that it addresses some of these issues of use of > multiple cores, OS priority levels and OS locking mechanisms. > > Cheers, > There are real time OS's that use the same approach. It provides a conceptually easier programming environment and some additional flexibility at the cost of incurring a full task switch. It is logically identical to on WinNT having an ISR wake up a real time priority thread which then services the device. There are some devices that are serviced that way, the floppy driver was one. The race conditions for two threads at different priority accessing a common data structure are the same as ISR's: the lower priority thread must raise its priority to the higher ones to block a task switch during the access. (The rules are slight more complicated than that because task switching allows more flexibility than priority ISR's. For example, the priority raising approach to mutual exclusion presumes the scheduler queues supplanted tasks at the front of the queue so it runs next at that priority.) Eric
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 10:14 +0000 |
| Message-ID | <jiktqp$rru$1@gosset.csi.cam.ac.uk> |
| In reply to | #6158 |
In article <4F4D987B.5060007@SPAM.comp-arch.net>, Andy (Super) Glew <andy@SPAM.comp-arch.net> wrote: > >> The question of whether such a thread is holding a lock is solved better >> under this scheme, because at least you can recover the lock when the >> process is killed. Systems that have had uncooperative lock recovery >> have never been a great success. > >What sort of lock recovery does UNIX / Linux have, generically? Easy. Locks are optional - just do the operation unlocked. It might even work - sometimes .... >> The point about lots of small, simple cores (including one per relevant >> device) is that one doesn't even need the hardware cooperative >> multitasking, but that's more of a simplification and optimisation than >> critical. However, it IS where I came in. > >But, you do need some way to regain control of cores that software has >run out of control on. > >That's either an interrupt, or a way for code running on some other core >to force the runaway into some known state - possibly killing whatever >software is running on it. Yes and no. If cores are dedicated to devices or device classes, and the software dies, you may as well write off that device or class, because you can't recover without risking worse problems. Also, as I said and you know, implementing a DIE-DIE-DIE interrupt is trivial compared to implementing one that allows recovery. >In >http://semipublic.comp-arch.net/wiki/Can_asynchronous_interrupts_be_completely_ eliminated%3F >I call that "remote control". I will look at that. >I agree: I have often found that the best thing to do in an interrupt >handler is initiate a thread and return - and allow the thread to >compete using "normal" thread scheduling. > >As we have discussed elsewhere, I am not averse to thinking about having >interrupts (really, I/O events) automatically spawn threads or make >threads runnable. Or queue up messages for some thread. And if the >thread happens to have a core to itself, fine. > >Doing so might remove the possibility of the FLIH being messed up. > >But, again - this is not a logically complete solution, if there is any >possibility that such a thread or core can run out of control. Right. >This addresses the question somebody else - Stephen Fuld - asked about >what he acronymized as SSI/HCM (Semi-Synchronous Interrupts/HW >Cooperative Multitasking). Why is it easier to be interruptible onbly >at certain places, not everywhere? Part of the answer is ease of analysis. > >Much of this boils down to atomicity. Very few machines have had ways >of making user software define complex atomic regions. Atomicity is >always relative, so making atomic relative to interrupts would involve >interrupt blocking, usually an OS level facility. Atomicity relative to >other threads and processors is only ever cooperative, using locks. > >The great hope of mechanisms such as Transactional Memory, whether HW or >SW, is that they might give us a way of creating atomicity without >having the cooperation of all parties involved. Again, agreed. >Fair enough. Many, many, programs do not handle error returns from >system calls properly, let alone EINTR. > >IMHO most programs would be better off dying when such errors are >thrown. (Not quite Freudian slip there.) Dead right :-( Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-29 08:28 -0800 |
| Message-ID | <4F4E522A.50405@SPAM.comp-arch.net> |
| In reply to | #6168 |
On 2/29/2012 2:14 AM, nmm1@cam.ac.uk wrote: > In article<4F4D987B.5060007@SPAM.comp-arch.net>, > Andy (Super) Glew<andy@SPAM.comp-arch.net> wrote: >> >>> The question of whether such a thread is holding a lock is solved better >>> under this scheme, because at least you can recover the lock when the >>> process is killed. Systems that have had uncooperative lock recovery >>> have never been a great success. >> >> What sort of lock recovery does UNIX / Linux have, generically? > > Easy. Locks are optional - just do the operation unlocked. It might > even work - sometimes .... Yes, that's the UNIX way: they removed all of the implicit locking, etc., that older OSes provided to make programs more likely to be correct.
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-29 08:24 -0800 |
| Message-ID | <4F4E512A.6050306@SPAM.comp-arch.net> |
| In reply to | #6123 |
On 2/27/2012 11:47 AM, nmm1@cam.ac.uk wrote: > In article<4F4BBB9B.7050300@SPAM.comp-arch.net>, > Andy (Super) Glew<andy@SPAM.comp-arch.net> wrote: >> I don't know of early x86 problems, because I was not at Intel at that time. > > The early x87 chips ran asynchronously, and interrupts didn't preserve > enough information to restart. That is why C90 specified that SIGFPE > handlers could not be returned from (though, in fact, returning is the > ONLY thing that has a hope in hell of working in most systems). OK, you reminded me of this. The x87 FP interface is still inspired by this old interface. FP exceptions were signaled not on the original instruction that caused the exception, but on the next FP instruction (just before it started executing). Which might be a long way off. By the time I started paying attention to x86, the ISA provided everything necessary to fix up such delayed exceptions: * FIP, the IP of the instruction that caused the exception * FOP, it's opcode * FEA, the effective address of the memory operand Q: I think that these features were present in the original x87, but unfortunately I have packed up those manuals and Now, you could simply take an FP exception, do nothing, and return. But if you wanted to emulate any features of the instruction, you would have to interpret FIP/FOP/FEA. Asynchronous interrupts that entered and returned? Not a problem IIRC, so long as they did not do FP, and obtain such a delayed FP exception. What if you wanted to use FP in the interrupt handler? Or context switch to a new process? Basically, you would have to drain any pending interrupt like this. I can't remember if there was a standard way to reload the state of FIP/FOP/FEA when context switching to a new process, or returning from an FP using interrupt. Can somebody remind me? IIRC the SMI, system management interrupt introduced for power management was the first interrupt to provide a way of saving and restoring FIP/FOP/FEA. I'm pretty sure that virtual machines do this in the VMCS. --- Things were complicated by the fact that the original x87s were wired up incorrectly. (Or, kluged to make up for pin architecture deficiencies.) Instead of producing a true x87 FP exception, they signalled such problems through an external interrupt. I can't remember how this interacted with FIP/FOP/FEA. By the time I was at Intel it was well enough behaved, but I can easily imagine that it might have broken when x87s were first hooked up to 8086s, or thereabouts. === Anyway: if I am remembering accurately, and if this is what you were referring to, Nick, then I think that it is relevant that this mess arose not because of asynchronous interrupts, but because of an optimization for semi-synchronous, deferred synchronous, exceptions. And possibly because FIP/FOP/FEA were not always treated as first class state. Here's my line in the sand: there must be a clean definition of architectural state. Anything that influences the results of execution, the data values, should be architectural state. And it should be possible to save/restore all such state. --- I also am not terribly fond of deferred exceptions. I am not terribly fond of an interrupt handler or exception handler having to emulate in SW some instructions. It's better to be able to return to a single instruction pointer, and have everything start up again. But if you are going to have to emulate instructions, then that should be a standard facility, a library function. And, as I have mentioned before, I think that there might be some ISA support to make decoding and emulation of instructions like this more portable - so that new instructions can be added to machines that will run old OSes.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 16:43 +0000 |
| Message-ID | <jilkjf$312$1@gosset.csi.cam.ac.uk> |
| In reply to | #6176 |
In article <4F4E512A.6050306@SPAM.comp-arch.net>, Andy (Super) Glew <andy@SPAM.comp-arch.net> wrote: > >Anyway: if I am remembering accurately, and if this is what you were >referring to, Nick, then I think that it is relevant that this mess >arose not because of asynchronous interrupts, but because of an >optimization for semi-synchronous, deferred synchronous, exceptions. >And possibly because FIP/FOP/FEA were not always treated as first class >state. That's another way of looking at it. >Here's my line in the sand: there must be a clean definition of >architectural state. Anything that influences the results of execution, >the data values, should be architectural state. And it should be >possible to save/restore all such state. If you are going to support asynchronous interrupts, I fully agree. If you get rid of them, temporary state need not be architectural. The x86 mistake was to try riding both horses at once. >I also am not terribly fond of deferred exceptions. I am :-) But the software absolutely needs to be able to control the window in which they occur, and they are essentially incompatible with any recovery that doesn't involve the normal execution of that window being idempotent. Fine for a transactional system; hopeless for anything else. >I am not terribly >fond of an interrupt handler or exception handler having to emulate in >SW some instructions. It's better to be able to return to a single >instruction pointer, and have everything start up again. But if you are >going to have to emulate instructions, then that should be a standard >facility, a library function. And, as I have mentioned before, I think >that there might be some ISA support to make decoding and emulation of >instructions like this more portable - so that new instructions can be >added to machines that will run old OSes. We are in complete agreement there. Come back Ferranti - all is forgiven! Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-02-29 09:08 -0800 |
| Message-ID | <328dd913-c973-44bd-8850-fd30bbcc50dc@l7g2000vbw.googlegroups.com> |
| In reply to | #6176 |
On Feb 29, 6:24 pm, "Andy (Super) Glew" <a...@SPAM.comp-arch.net> wrote: > On 2/27/2012 11:47 AM, n...@cam.ac.uk wrote: > > > In article<4F4BBB9B.7050...@SPAM.comp-arch.net>, > > Andy (Super) Glew<a...@SPAM.comp-arch.net> wrote: > >> I don't know of early x86 problems, because I was not at Intel at that time. > > > The early x87 chips ran asynchronously, and interrupts didn't preserve > > enough information to restart. That is why C90 specified that SIGFPE > > handlers could not be returned from (though, in fact, returning is the > > ONLY thing that has a hope in hell of working in most systems). > > OK, you reminded me of this. > > The x87 FP interface is still inspired by this old interface. FP > exceptions were signaled not on the original instruction that caused the > exception, but on the next FP instruction (just before it started > executing). Which might be a long way off. > > By the time I started paying attention to x86, the ISA provided > everything necessary to fix up such delayed exceptions: > > * FIP, the IP of the instruction that caused the exception > * FOP, it's opcode > * FEA, the effective address of the memory operand > > Q: I think that these features were present in the original x87, but > unfortunately I have packed up those manuals and > > Now, you could simply take an FP exception, do nothing, and return. But > if you wanted to emulate any features of the instruction, you would have > to interpret FIP/FOP/FEA. > > Asynchronous interrupts that entered and returned? Not a problem IIRC, > so long as they did not do FP, and obtain such a delayed FP exception. > > What if you wanted to use FP in the interrupt handler? Or context > switch to a new process? Basically, you would have to drain any pending > interrupt like this. > > I can't remember if there was a standard way to reload the state of > FIP/FOP/FEA when context switching to a new process, or returning from > an FP using interrupt. Can somebody remind me? > > IIRC the SMI, system management interrupt introduced for power > management was the first interrupt to provide a way of saving and > restoring FIP/FOP/FEA. I'm pretty sure that virtual machines do this in > the VMCS. > > --- > > Things were complicated by the fact that the original x87s were wired up > incorrectly. (Or, kluged to make up for pin architecture deficiencies.) > Instead of producing a true x87 FP exception, they signalled such > problems through an external interrupt. I can't remember how this > interacted with FIP/FOP/FEA. By the time I was at Intel it was well > enough behaved, but I can easily imagine that it might have broken when > x87s were first hooked up to 8086s, or thereabouts. > > === > > Anyway: if I am remembering accurately, and if this is what you were > referring to, Nick, then I think that it is relevant that this mess > arose not because of asynchronous interrupts, but because of an > optimization for semi-synchronous, deferred synchronous, exceptions. Thank you for excellent explanation, Andy. Now I am starting to understand what Nick was talking about. I'd say, the mess arose because of attempt to take advantage of parallelism between main CPU and FP co-processor. There are people around that again try to sell us idea of off-core fine-grain* co-processors again. And if they succeed then, no doubt, there will come people that would try to take advantage of parallelism between co-processor and host CPU :( ------------------------ fine-grain - in a meaning "exchanging small units of works with host". I don't know the academic name. I have nothing again "coarse grain" co-processors that exchange order of high tens or hundreds of usec units of work with the host. Such co- processor is, essentially, yet another I/O device. But 'fine grain" co- processors look to me as extremely misleading idea.
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2012-02-29 12:17 -0800 |
| Message-ID | <a122189b-9fc4-4af6-a76e-2abfd3b42380@k6g2000vbz.googlegroups.com> |
| In reply to | #6179 |
On Feb 29, 12:08 pm, Michael S <already5cho...@yahoo.com> wrote: [snip] > There are people around that again try to sell us idea of off-core > fine-grain* co-processors again. And if they succeed then, no doubt, > there will come people that would try to take advantage of parallelism > between co-processor and host CPU :( > > ------------------------ > fine-grain - in a meaning "exchanging small units of works with host". > I don't know the academic name. > I have nothing again "coarse grain" co-processors that exchange order > of high tens or hundreds of usec units of work with the host. Such co- > processor is, essentially, yet another I/O device. But 'fine grain" co- > processors look to me as extremely misleading idea. Why would a fine-grained coprocessor be a problem? The method for communicating completion of an operation (as well as the operands) would be different for different granularities. At a granularity closer to a functional unit (with specialized internal state), one might use an ordinary instruction with scoreboarding on a result register to communicate when the result is ready. A somewhat coarser grained coprocessor might provide a processor-local event bitvector that could be polled by software. (It might be desirable to support multiple bitvectors with context IDs to allow events for a just switched-out context to be caught without forcing an interrupt. Since this is small and less timing-critical state, supporting between two and four entries would allow the coprocessor to complete shortly after a context switch without bothering the active context.) Perhaps somewhere in between one might have a memory interface where the completion is probed by a load operation (and appears something like a cache miss if the coprocessor operation has not yet completed). If one knows that an operation is likely to take a moderate amount of time, it makes sense that one would try to work on something else while the coprocessor is busy. (Even without specialized operation, the ability to spawn a temporary thread or message an existing thread to do some side work could be attractive at somewhat fine granularity.) Since you have actual work experience (and I am not even a programmer), I assume I am missing something.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <SFuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2012-02-27 12:23 -0800 |
| Message-ID | <jigoop$4eb$1@dont-email.me> |
| In reply to | #6116 |
On 2/27/2012 9:21 AM, Andy (Super) Glew wrote: snipped a very insightfull post Thank you Andy. You expressed pretty much exactly what I would have said. One further elaboration. I have been trying to see how having multiple small cores (which Nick also advocates) relates to this. At first I thought they were totally orthogonal issues, but I do see one possible connection. If you have small, dedicated cores that could handle the interrupt and start the next I/O, etc, you could presumably lengthen the time between when semi-synchronous interrupts or hardware cooperative multitasking yield points are allowed. That is, if another core is handling the interrupts, you reduce the pressure for the main core to handle them promptly. I'm not sure how valuable that is. Speaking of this (how about SSI/HCM as a shorthand, at least for this post), I don't see a big advantage. Yes, you potentially allow more interrupt coalescing, but if you have a potential interrupt every branch which is perhaps a dozen instructions, how much are you really saving? Is the hardware that much easier if you can take an interrupt at some arbitrary software specified point rather than after each instruction? It seems you are mearly reversing the sense of a privilidged instruction to lock out interrupts. That is, they are locked out by default until you say you allow them rather than they are allowed by default until you say they are locked out. Is that a big deal? -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-02-28 17:12 -0800 |
| Message-ID | <4F4D7B60.3080300@SPAM.comp-arch.net> |
| In reply to | #6125 |
On 2/27/2012 12:23 PM, Stephen Fuld wrote: > On 2/27/2012 9:21 AM, Andy (Super) Glew wrote: > > snipped a very insightfull post > > Thank you Andy. You expressed pretty much exactly what I would have said. > > One further elaboration. I have been trying to see how having multiple > small cores (which Nick also advocates) relates to this. At first I > thought they were totally orthogonal issues, but I do see one possible > connection. If you have small, dedicated cores that could handle the > interrupt and start the next I/O, etc, you could presumably lengthen the > time between when semi-synchronous interrupts or hardware cooperative > multitasking yield points are allowed. That is, if another core is > handling the interrupts, you reduce the pressure for the main core to > handle them promptly. I'm not sure how valuable that is. I think it's great, definitely worth exploring. Especially in this era when power efficiency is so important. Offload cores can make sense if the workload suits. Measure and try it out. Although... back when I was an OS guy at Moto, performance analysis revealed that the "offload engine" to handle the BSD, no, I think it was SystemV networking stack interrupt processing really needed to be comparable to, if not more powerful than, the engine that was handling the user code - which at that time was vi and emacs, and the beginning of X. (The offload engine that had been built was really just a generation or two older 68000 card, with the main CPU being an 88K. It couldn't keep up - and it was running an always out of date software that did not have the latest performance fixes.) A mainframe architect came in and said "Surely you don't do a lot of processing in the interrupt handler itself?" Umm, sorry, bad assumption... By the way, that sort of thing was "fixed" multiple times. Trouble is, the code never propagated to the master distro, so it kept having to be refixed. Anyway, offload cores can make sense if the workload suits. Measure and try it out. > Speaking of this (how about SSI/HCM as a shorthand, at least for this > post), I don't see a big advantage. Neither do I. Which is what puzzled me about so much of this conversation. Offload engines occasionally make sense. They are an empirical question: measure, estimate, try it out. Semi-synchronous / hardware cooperative multithreading doesn't really make sense to me. Since at the least you need to be able to kill an accidentally not-very-cooperative thread. I can imagine interrupt based preemption for user threads, with SSI/HCM inside the OS. And I think that might be an easier issue, since seldom will a user thread be holding kernel locks while in user code. (Except... callbacks, bloody callbacks. User calls OS, giving the OS a callback. OS gets a lock, and then calls the user. So the user code is now running, and may be preempted while a kernel lock is held. Bad BAD BAD. Stupid. IMHO callbacks like this are as big a source of bugs as anything else.) Yes, you potentially allow more > interrupt coalescing, but if you have a potential interrupt every branch > which is perhaps a dozen instructions, how much are you really saving? I don't think very much. Especially if you consider the old mainframe strategy of interrupt batching: delay interrupt delivery to allow coalescing. If the interrupt load is high, block interrupts globally, opening windows up only periodically. > Is the hardware that much easier if you can take an interrupt at some > arbitrary software specified point rather than after each instruction? Not in my experience. Although lots of hardware people have tried to take shortcuts, and gotten smacked. But I think Nick's point - apart from having encountered problems like this in hardware - is that software might find this easier. Also remember: most systems do not have a good way of blocking interrupts from user code. > It seems you are mearly reversing the sense of a privilidged instruction > to lock out interrupts. That is, they are locked out by default until > you say you allow them rather than they are allowed by default until you > say they are locked out. Is that a big deal? It does reduce the number of places that you have to analyze for being interrupt safe.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-29 09:09 +0000 |
| Message-ID | <jikq04$9m9$1@gosset.csi.cam.ac.uk> |
| In reply to | #6154 |
In article <4F4D7B60.3080300@SPAM.comp-arch.net>, Andy (Super) Glew <andy@SPAM.comp-arch.net> wrote: >On 2/27/2012 12:23 PM, Stephen Fuld wrote: > >> Is the hardware that much easier if you can take an interrupt at some >> arbitrary software specified point rather than after each instruction? > >Not in my experience. > >Although lots of hardware people have tried to take shortcuts, and >gotten smacked. > >But I think Nick's point - apart from having encountered problems like >this in hardware - is that software might find this easier. Yes, especially operating and run-time systems. But it DOES enable extra dynamic optimisation in hardware. For example, some of the inter-instruction linkage data (condition codes and their cousins) wouldn't need to be saveable. That would also significantsimplify and speed-up the initial interrupt handling. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Brett Davis <ggtgp@yahoo.com> |
|---|---|
| Date | 2012-02-27 20:33 -0600 |
| Subject | Re: Itanium fixed |
| Message-ID | <ggtgp-FBBDD9.20331927022012@netnews.mchsi.com> |
| In reply to | #6116 |
In article <4F4BBB9B.7050300@SPAM.comp-arch.net>, "Andy (Super) Glew" <andy@SPAM.comp-arch.net> wrote: > I know of many Itanium problems, but I believe all were fixable, and > fixed. Itanium does seem to win a few benchmarks, but now x86 also has huge L3 caches, so is Itanium in general competitive, and is there any hope that Itanium could have an overall performance advantage? I would dump the register windows, and maybe keep the register rotation, and replace the triple packed 128 bit instructions with simple 48 bit instructions, but then its almost just another RISC chip. The preload/loadCheck instructions were not used in general, so what is left after optimizing away all the stuff that did not work, or cost more than it was worth.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2012-02-25 11:15 -0500 |
| Message-ID | <m3aa46zy68.fsf@garlic.com> |
| In reply to | #6075 |
Quadibloc <jsavard@ecn.ab.ca> writes: > There is a connection between re-entrant code and interrupts. If any > subroutine is called by programs that can be interrupted which is also > called by the interrupt service routines, that subroutine has to be > fully re-entrant. But that restriction applies to subroutines provided > by the operating system as part of its API, not to every piece of code > written by users to solve their problems. This was sort of how we got atomic compare&swap instruction out. Charlie had invented compare&swap (mnenomic CAS are his initials) while doing fine-grain multiprocessor locking work on cp67 at the science center ... misc. past posts mentioning science center http://www.garlic.com/~lynn/subtopic.html#545tech Initial attempts to get compare&swap included in 370 architecture was rebuffed by the architecture owners; their comment was that the favorite son operating system people were saying test&set was more than adequate for multiprocessor locking. The challenge was to come up with a justification that wasn't multiprocessor specific. Thus was born the examples for multi-threaded application code (that was enabled for interrupts) like large DBMS (that required serialization/locking) ... and compare&swap got included in 370 architecture. misc. past posts mentioning multiprocessor and/or compare&swap http://www.garilc.com/~lynn/subtopic.html#smp the examples continue to survive (multiprogramming is mainframe speak for multi-threaded) 40yrs later Multiprogramming and Multiprocessing Examples http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320 -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-02-25 18:10 +0000 |
| Message-ID | <jib861$jak$1@gosset.csi.cam.ac.uk> |
| In reply to | #6077 |
In article <m3aa46zy68.fsf@garlic.com>, Anne & Lynn Wheeler <lynn@garlic.com> wrote: >Quadibloc <jsavard@ecn.ab.ca> writes: > >> There is a connection between re-entrant code and interrupts. If any >> subroutine is called by programs that can be interrupted which is also >> called by the interrupt service routines, that subroutine has to be >> fully re-entrant. But that restriction applies to subroutines provided >> by the operating system as part of its API, not to every piece of code >> written by users to solve their problems. > >This was sort of how we got atomic compare&swap instruction out. Charlie >had invented compare&swap (mnenomic CAS are his initials) while doing >fine-grain multiprocessor locking work on cp67 at the science center >... misc. past posts mentioning science center >http://www.garlic.com/~lynn/subtopic.html#545tech > >Initial attempts to get compare&swap included in 370 architecture was >rebuffed by the architecture owners; their comment was that the favorite >son operating system people were saying test&set was more than adequate >for multiprocessor locking. ... That claim lasted until the early 1970s - God alone knows why, because even a few minutes thought made it clear that test and set just wasn't enough for efficient atomic transactions. Indeed, I have seen the claim resurface in the past 5 years by people who ought to know better! Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Erik Trulsson <ertr1013@student.uu.se> |
|---|---|
| Date | 2012-02-27 08:47 +0000 |
| Message-ID | <jiffub$aj9$1@Iltempo.Update.UU.SE> |
| In reply to | #6068 |
EricP <ThatWouldBeTelling@thevillage.com> wrote: > The only reason code is non interruptible is if it is not > properly (either serially or fully) reentrant. Wrong. That may be the only *good* reason for why a particular piece of code *should* be made non-interruptible, but it is not exactly unheard of for code to block interrupts for longer than necessary - sometimes much longer. The reasons for this vary, but mostly boil down to the fact that programmers are not perfect. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-02-25 12:37 -0800 |
| Message-ID | <73ac805c-8ccd-48bc-800e-22696fe55197@b3g2000yqi.googlegroups.com> |
| In reply to | #6057 |
On Feb 24, 11:40 am, n...@cam.ac.uk wrote: > 1) For interrupts to be reliable, no interruptible process may > ever call a non-interruptible primitive that potentially may run > longer than the maximum interrupt delay. It is almost impossible > to overstate the severity of failure to enforce that on RAS. Here, as noted, interruptible processes - which, of course, must include most of the operating system, not just user code - generally _do_ do this. The only thing that's not interruptible is the first few microseconds of the interrupt handling routine - it saves the state, and then it re-enables interrupts, at least those of higher priority than the interrupt that it is continuing to service. > 2) If a process can be arbitrarily interrupted, then it must > allow for ANY potentially shared external state to change at ANY > point. Even when it can and does test and retry, the result of > doing so is often livelock. It is true that one of the interrupts to which user code is subject is a real-time clock interrupt, which may end up passing control to other user code. So, indeed, shared state can be changed unexpectedly - generally speaking, interrupt handlers and the operating system don't concern themselves with the internal business of application programs. And so we indeed do have interlock problems on timeshared systems. They haven't made such systems unusable. John Savard
[toc] | [prev] | [next] | [standalone]
Page 12 of 20 — ← Prev page 1 … 10 11 [12] 13 14 … 20 Next page →
Back to top | Article view | comp.arch
csiph-web