home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!ryn.mro4.dec.com!wrksys.enet.dec.com!bhandarkar
- From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
- Subject: Re: DEC Alpha architecture issues
- Message-ID: <1992Nov23.175327.26617@ryn.mro4.dec.com>
- Sender: news@ryn.mro4.dec.com (USENET News System)
- Organization: Digital Equipment Corporation
- References: <1992Nov18.210416.27212@nntpd.lkg.dec.com> <lgnfc3INNqnt@spim.mti.sgi.com>
- Date: 23 NOV 92 12:53:40
- Lines: 20
-
-
- In article <lgnfc3INNqnt@spim.mti.sgi.com>, woodacre@mips.com (Michael Woodacre) writes...
- >
- >Can you explain how this is different from kernel code with interrupts
- >disabled on any other risc processor? For instance, an R4000 can
- >implement uniprocessor-atomic "instructions" which are sequences of
- >MIPS instructions to implement complex functions by running code
- >in kernel level with interrupts switched off.
- >
- It is very similar. The difference is that the high level function is defined
- and software developers can count on this function being available in a
- consistent way across many implementations. Our model was that a processor
- designers would write the PALcode for their machine. The other advantage is
- that you avoid the overhead of a system service call. If the function
- requires memory access, you can implement it easily by executing PALcode
- with memory management on for data accesses, so you don't have to check page
- table entries explicitly in software.
-
- Dileep
- Co-inventor of what used to be EPICODE on PRISM
-