home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!spool.mu.edu!umn.edu!kksys.com!edgar!technix!bret
- From: bret@technix.mn.org (Bret Indrelee)
- Newsgroups: comp.arch
- Subject: Re: DEC Alpha architecture issues
- Message-ID: <1992Nov21.194311.7600@technix.mn.org>
- Date: 21 Nov 92 19:43:11 GMT
- References: <1992Nov19.204209.6619@nntpd.lkg.dec.com> <DOCONNOR.92Nov20095251@potato.sedona.intel.com> <1992Nov20.183610.12796@crl.dec.com>
- Organization: Private System - Saint Paul, MN
- Lines: 37
-
- In article <1992Nov20.183610.12796@crl.dec.com> payne@crl.dec.com (Andrew Payne) writes:
- >DEC Cambridge Research Lab
- [ Text deleted ]
- >When the processor is running in PAL mode (as a result of executing a
- >call PAL opcode or taking an exception) the processor is fetching and
- >executing instructions as usual, but:
-
- [ First two points deleted ]
-
- >3. Interrupts are disabled (so you can do atomic operations)
-
-
- Hold it! Disabling interrupts is not usually enough to guarentee that
- an operation is atomic!
-
- Either I am missing something, or PALcode has to do more in order to make
- sure that the operation is atomic.
-
-
- The Alpha machines included models with multiprocessors. Disabling the
- interrupts on one processor does not, by itself, prevent one of the other
- processors from changing the memory location.
-
- Even on single-processor machines, disabling interrupts is not enough.
- The high-end machines can have Futurebus+ cards on them, such as an
- intelligent graphics engine. These devices can be accessing memory,
- and should be able to do atomic transactions. The processor (and
- system memory bus) have to do more than just disable interrupts in
- order to guarentee a truely atomic transaction!
-
- -Bret
-
-
- --
- ------------------------------------------------------------------------------
- Bret Indrelee | Insanity is all in the mind.
- email: bret@technix.mn.org |
-