Date: Thu, 04 Feb 1999 20:42:54 -0800 From: Jason Thorpe <thorpej@nas.nasa.gov> To: Don <don@calis.BlackSun.org> Cc: Stuart Krivis <stuart@apk.net>, freebsd-alpha@FreeBSD.ORG Subject: Re: alpha PC Message-ID: <199902050442.UAA06118@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
On Thu, 4 Feb 1999 22:47:03 -0500 (EST)
Don <don@calis.BlackSun.org> wrote:
> ARC and SRM aren't just boot loaders. They also define a set of low level
> functions for interaction with the hardware. In order to work with a 64
> bit platform ARC has a limited subset of these system calls which are only
> 32 bits. (A certain bloated poorly implemented Windowing New Technology
> 32 bit operating system needs these calls in order to be able to run on
> the Alpha). Since FreeBSD does not want to limit itself by using
> ARC (which would restrict a lot of the low level calls to 32 bit ones),
> they are working on other solutions similar to MILO.
Not exactly :-)
ARC and SRM both provide PALcode. ARC provides NT PALcode. SRM provides
OSF/1 PALcode. OSF/1 is what is needed to run Unix on an Alpha processor.
It provides a set of semantics which suit the needs of Unix. Similarly,
the VMS PALcode provides a set of semantics suitable for the needs of
OpenVMS.
It's not that the NT PALcode is a *subset* of the OSF/1 PALcode; in fact,
there are, the last time I peered at the architecture reference, far more
NT PALcode ops than OSF/1 PALcode ops.
It is true that the NT PALcode implements a 32-bit address space[*], laid out
*exactly* like the MIPS address space (no surprise there, since that was
NT's first platform :-), but it also provides low-level support for NT's
task switching, etc.
[*] There actually is support for an extended address space, which is where
devices, et al get mapped, I think. This lives in the upper half of the
64-bit address space. Tasks, however, still only get (32 - N) bits of address
space (however many are allocated to USEG on the MIPS ... I forget exactly).
Basically, if you want to try and make Unix run on the NT PALcode, please
drill a hole in your head. You'll save yourself a lot of trouble by just
starting with the inevitable last step :-)
It's not an issue of NetBSD or FreeBSD limiting itself by running on
the NT PALcode... it's an issue of "wow, this looks like a completely
different architecture if we do". I mean, the only thing in common really
is the instruction set, which is minor if you consider that the vast majority
of the kernel is written in C. The hard parts of a port are low level virtual
memory, interrupts, and traps.
> What MILO does is basically install it's own firmware. ARC boots and then
> MILO runs and installs it's own firmware code into memory. This code
> resides in memory until the machine is rebooted and it replaces all of the
> poor ARC calls with its own thus restoring true 64 bit capability to the
> system.
MILO installs its own *PALcode*. There is a distinct difference between
PALcode and firmware :-)
And, it is worth noting that even with NT PALcode, registers, etc. are
still 64 bits. The only thing that is "limited" is the virtual address
space (and it is even not limited when you consider the extended address
space support that the NT PALcode has; it's simply not laid out the same
way).
-- Jason R. Thorpe <thorpej@nas.nasa.gov>
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?199902050442.UAA06118>