From owner-freebsd-alpha Thu Feb 4 20:43:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA24328 for freebsd-alpha-outgoing; Thu, 4 Feb 1999 20:43:15 -0800 (PST) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA24323 for ; Thu, 4 Feb 1999 20:43:14 -0800 (PST) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id UAA06118; Thu, 4 Feb 1999 20:42:55 -0800 (PST) Message-Id: <199902050442.UAA06118@lestat.nas.nasa.gov> To: Don Cc: Stuart Krivis , freebsd-alpha@FreeBSD.ORG Subject: Re: alpha PC Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 04 Feb 1999 20:42:54 -0800 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 4 Feb 1999 22:47:03 -0500 (EST) Don 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message