Date: Fri, 18 Feb 2000 15:02:19 -0800 From: Arun Sharma <adsharma@sharmas.dhs.org> To: freebsd-hackers@freebsd.org Subject: Re: 64bit OS? Message-ID: <20000218150219.A17763@sharmas.dhs.org>
next in thread | raw e-mail | index | archive | help
[ My apologies if this is a repeat - my earlier mail didn't seem to make it ] On Fri, 18 Feb 2000 12:03:37 +1100, Patryk Zadarnowski <patrykz@ilion.eu.org> wrote: > On the other hand, IA-64 is a very exotic architecture from the OS's > point of view, and anyone planning to port *BSD to it should probably > start planning ASAP. I'm a former Intel employee and I have worked on the Linux IA-64 project. I think there is plenty of planning to do to get an OS running on IA-64, which is more complex than most other architectures I've known. First of all - there is plenty of reading to do: http://developer.intel.com/design/ia-64/manuals/index.htm http://devresource.hp.com/devresource/Docs/Refs/IA64ISA/index.html Some of the design decisions to make: (a) Programming model - LP64 would probably be the most sensible (b) Page table architecture IA-64 supports both the long and short format VHPT (virtual hash page table). Linux chose to use the short format - which really uses no hashing. Linux has the concept of machine independent multi level page tables and has generic algorithms which manipulate them in machine independent code. Where possible, it tries to map them to hardware dependent page tables. On architectures like IA-64 and Power PC, this becomes a little awkward and Linux essentially treats hardware page tables as TLBs. The problem with the above approach is duplication of information between Linux page tables and hardware page tables and inefficient use of memory for page tables. I think OSes like FreeBSD which don't have a concept of machine independent page table are essentially free to do anything in the hat layer and thus have more flexibility. On Linux/IA-64, such duplication is avoided by having a 3 level page table and overloading the L3 page table with the hardware page table functionality. In a nutshell, all L3 page tables are mapped in a region in the *virtual* address space, such that to get the vtop translation for address P, you can just index into this "linear" virtual page table. Because the page table is in *virtual* address space, recursive faults are possible. A significant chunk of the virtual address space has to be reserved for this sparse, linear page table. The other alternative is to use a global hash page table and walk the collision chains in software. The advantage of this scheme is savings in terms of both physical memory and virtual address space, but a heavier dependence on the hardware implemented hashing algorithm's characteristics. It isn't really clear which one is superior, but FreeBSD's VM architecture allows a choice. (c) Handling the register stack on system call entry and exit Sparc has shown how frequent register stack flushing can offset the good effects of register stacks. IA-64 has some nice tricks which can be used to avoid the flush. (d) Restarting of system calls and interactions with the register stack Linux does this by using a gcc directive which was created for this purpose. The normal calling conventions allow input registers to be treated as scratch. But under this directive they will be preserved, so that system calls can be restarted. The disadvantage of this approach is compiler specific code (which Linux has not been averse to in the past) and some register allocation inefficiency in the kernel. The alternate approach is to return ERESTART from the system call, catch the error in libc and restart the system call with saved args. Other general notes: - Writing assembly code is tricky and writing efficient assembly code is trickier - Lots of architectural state to keep track of - Implementing setjmp and longjmp is tricky, because of the interaction with the register stack - Errata, lack of support can be worked around by looking at Linux sources I'd love to have technical discussions about the IA-64 architecture from an OS perspective, if anyone on this list is interested. Since last September, I've moved on to a new daytime job, which has nothing to do with operating systems or kernels. I have a limited amount of spare time and I'm willing to help out with a IA-64 port, if the FreeBSD project decides to pursue it. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000218150219.A17763>