Hacker News Reader

Comment by jvert | Hacker News Reader

PAL code didn't do anything like context switches and I'm not sure how it could, given how the OS needs to know the specifics of the thread context in many scenarios.

View on HN

That's correct. On NT/Alpha context switching was done in ntos\ke\alpha\ctxsw.s, which was regular kernel mode assembler code. A PAL call was made but it simply set the new Teb and Pdr; two or three lines of code. I've never seen the PALcode for VMS or OSF/Tru64 but the NT PAL for swpctx was designed so that alpha assembler code in NT looked as much like the mips code that davec wrote. It made the port easier that way.

Interesting Raymond continues to mention NT/Alpha now and then. If you run into him mention I have a collection of NT/Alpha artifacts and anecdotes he might be interested in.

I believe in the specific case of L4/Alpha, the PALCode did perform the context switches. Granted, I doubt it was as robust as the VMS or Tru64 PALCode versions that were production-ready.

PALcode implemented context switches for all systems, including Linux (which uses Digital Unix PALcode). Specifically, PALcode covered various internal details of the CPU presenting unified interface to OS - each CPU needed custom PALcode implementation, though IIRC there were only few mandatory PALcode calls (related to memory barriers, iirc). The kernel covered switching OS-specific structure pointers over, PALcode handled all sorts of MMU, TLB, PASID indexing of TLB, internal CPU state etc.

L4/Alpha PALcode was limited to specific set of CPUs it was implemented for, so unlike VMS, NT or Digital Unix PALcode it wasn't available outside of those few machines.

Reply on news.ycombinator.com