|Don||Feb 4, 1999 4:32 am|
|Adauto Souza||Feb 4, 1999 4:39 am|
|Andrew Gallatin||Feb 4, 1999 6:09 am|
|Doug Rabson||Feb 4, 1999 6:22 am|
|Joerg Czeranski||Feb 4, 1999 6:40 am|
|Andrew Gallatin||Feb 4, 1999 6:53 am|
|Scot Elliott||Feb 4, 1999 6:56 am|
|Stuart Krivis||Feb 4, 1999 7:28 am|
|Martin Heller||Feb 4, 1999 8:19 am|
|Todd Vierling||Feb 4, 1999 8:26 am|
|Ted Spradley||Feb 4, 1999 8:33 am|
|Stuart Krivis||Feb 4, 1999 8:42 am|
|Ted Spradley||Feb 4, 1999 8:47 am|
|Matthew Jacob||Feb 4, 1999 9:41 am|
|Don||Feb 4, 1999 7:26 pm|
|Don||Feb 4, 1999 7:46 pm|
|Peter Wemm||Feb 4, 1999 7:54 pm|
|Terry Lambert||Feb 4, 1999 8:08 pm|
|Jason Thorpe||Feb 4, 1999 8:42 pm|
|Jason Thorpe||Feb 4, 1999 8:48 pm|
|Peter Wemm||Feb 4, 1999 10:01 pm|
|Christian Weisgerber||Feb 5, 1999 2:09 am|
|Scot Elliott||Feb 5, 1999 2:51 am|
|Christian Weisgerber||Feb 5, 1999 1:35 pm|
|Don||Feb 5, 1999 1:45 pm|
|John Birrell||Feb 5, 1999 1:56 pm|
|Don||Feb 5, 1999 4:50 pm|
|Doug Rabson||Feb 9, 1999 11:59 am|
|Subject:||Re: alpha PC|
|From:||Jason Thorpe (thor...@nas.nasa.gov)|
|Date:||Feb 4, 1999 8:42:32 pm|
On Thu, 4 Feb 1999 22:47:03 -0500 (EST) Don <do...@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 <thor...@nas.nasa.gov>
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message