Date: Fri, 05 Feb 1999 14:02:11 +0800 From: Peter Wemm <peter@netplex.com.au> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: Stuart Krivis <stuart@apk.net>, freebsd-alpha@FreeBSD.ORG Subject: Re: alpha PC Message-ID: <199902050602.OAA28276@spinner.netplex.com.au> In-Reply-To: Your message of "Thu, 04 Feb 1999 20:48:26 PST." <199902050448.UAA06189@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Thorpe wrote: > On Fri, 05 Feb 1999 11:54:24 +0800 > Peter Wemm <peter@netplex.com.au> wrote: > > > etc. In the console code is embedded a copy of "palcode". Palcode is > > both a blessing and a curse. It's the low level pseudo-microcode that > > provides a personality for the execution environment. It is meant to > > Ah ah ah! It's not microcode! Remember, this is a RISC system! Thar > be no microcode here! I didn't say it was microcode, I called it pseudo-microcode because it performs many of the system management functions that are traditionally performed by microcode on systems that have it. Like real microcode, it's inner workings are generally outside the visibility of the OS, including horrible things like TLB miss and page table management etc. Compare that to things like the MIPS systems where the OS has to implement TLB management directly and page tables are entirely a convenience for the OS programmer thing and have nothing to do with actual hardware. On the MIPS one can do away with page tables entirely if one wanted (and was masochistic enough). > What really sets PALcode apart is that it is written in the standard > Alpha instruction set. It *does* use some facilities only avalable to > PALcode, e.g. the hw_* instructions (which are different from Alpha > processor model to model) and the IPRs (internal processor registers). > > But, it's really just a program, much like a kernel, which runs at a > higher privilege level (PAL mode). Yep, and that's what's good about it because it's not burned onto the CPU silicon and can be tuned for particular environments to provide a uniform environment across different CPU variations etc. But that's also the bad thing, it requires the hardware developers to provide PALcode variations for the different environments... What I'm curious about though, is how dependent the NT Palcode (and other palcode in general) is on the OS using the provided task switch mechanisms.. Does the OS have enough context available to do it's own context switching inside a single NT "task"? Or does it have to use the mechanisms in order to do interrupt processing? Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902050602.OAA28276>