1 / 22

OpenVMS on the Itanium TM Processor Family

OpenVMS on the Itanium TM Processor Family. Clair Grant OpenVMS Engineering. The big challenges. No Alpha ™ SRM Console No Alpha ™ PALcode Different primitives in the CPU Compilers* Calling Standard (Intel-based) * Object Format (ELF) * Debug Symbol Tables (DWARF) *

devin
Download Presentation

OpenVMS on the Itanium TM Processor Family

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OpenVMSon theItaniumTM Processor Family Clair Grant OpenVMS Engineering

  2. The big challenges • No Alpha™SRM Console • No Alpha™ PALcode • Different primitives in the CPU • Compilers* • Calling Standard (Intel-based) * • Object Format (ELF) * • Debug Symbol Tables (DWARF) * * - to be covered in Session 1690 at 2:30

  3. Selected topics of interest • Console Functions • PALcode • IPL / ASTs / Software Interrupts • Memory Management • Synchronization Techniques • Context Switching

  4. Console functions • Booting • Special Run Time Services • Power Management

  5. Console: Booting on the EFI Console • Intel Console: • Processor Abstraction Layer (PAL) • System Abstraction Layer (SAL) • Extensible Firmware Interface (EFI) • Reads a FAT32 file partition to get OS loader • We will overlay that partition on an ODS-2 disk • There will be a new OS loader

  6. Console: Special Run Time Services • Console Terminal I/O • OpenVMS will do it • Partitioning • Need “ownership of devices” info • Need “switch of ownership” capabilities • Soft partitions (Galaxy) will be very challenging • Crash Dump • Driver • File system knowledge • CPU Management

  7. Console: Power Management • Advanced Configuration and Power Interface (ACPI) provides • configuration data • interface to control device availability • Current OpenVMS RAS support • ACPI provides a lot but not all we need • Some additions to OpenVMS • Some additions in an EFI application

  8. Application Application Application OpenVMS OpenVMS OpenVMS* SW Console Console Console PALcode* HW VAX* Alpha IA-64 It’s all in the software

  9. Privileged Architecture Library (PALcode) • PALcode execution environment • Complete control of machine state • Interrupts disabled • I-stream mapping disabled

  10. PALcode Functions • Instructions • Complex sequencing and atomic operation • VAX interlocked instructions • Privileged instructions • Translation buffer management • Interrupt and exception dispatching • Synchronization primitives

  11. CALL_PAL Examples • CHMK * • REI * • SWPCTX • CSERVE • MFPR / MTPR * • Atomic Queue Instructions * * = VAX instruction

  12. Remove from head of queue, interlocked • VAX instruction REMQHI • Alpha CALL_PAL REMQHIL • IA-64 instruction EPC + MF + OpenVMS code

  13. IPL / ASTs / Software Interrupts • 0 - 31 IPLs (but we only define 13 of them… (2,3,4,5,6,7,8,9,10,11,15,21,22,31) • Map 16-31 directly onto a 16-bit interrupt register • Use another register for software levels 0-15 • SETIPL / REI • Alpha™AST Summary Register • Alpha™Software Interrupt Summary Register

  14. Memory management • Page Size • Page Protection • Virtual Address Space • PTE Format

  15. Page size • Page size will be 8KB initially • GH factors (huge pages) will be handled by the VMS TLB miss handler • Same GH factors as on Alpha • 3 full levels of page tables

  16. Page protection • IA-64 access rights and privilege levels can do all common VAX and Alpha page protections except • User Read, Exec Write (UREW) - considering using User Read, Super Write (URSW) • User Read, Super Write (URSW) and Super Read, Exec Write (SREW) won't allow execute access. (Privileged code must change to write code, then set page read only.) • OpenVMS will allow ‘no execute’ pages.

  17. Virtual address space • address space will be 8TB in size initially • 32-bit System Page Table (SPT) window will still be created in S1 space for 32-bit device driver code • Each IA-64 region will have its own page table space • P0, P1, S0, S1 will be 32-bit; P2 and S2 will be 64-bit S0, S1, S2 7 6 5 4 3 2 1 0 P0, P1, P2

  18. PTE Format • Since OpenVMS will implement the TLB miss handler it can retain its current PTE formats. • The Address Space Match (ASM) bit will not be set for system space. ASM will be a function of the virtual address, not a PTE bit. All addresses in IA-64 region 7 will essentially have ASM set. • Other than protection and ASM, all PTE bits will be the same as on Alpha

  19. Synchronization techniques • Requirement: to read/write a shared location in a single atomic operation • Example OpenVMS Uses: • Spinlock • MUTEX • Semaphore • Queue instructions • Alpha: CALL_PAL, LDL/STC and MB • IA-64: FETCHADDx, CMPXCHGx, XCHGx, EPC, and MF

  20. Context switching • Probably a little worse: • More registers to save • More context to save on full interruption • Probably a little better: • No “interruption” for software interrupt • Fewer full interruptions

  21. Portable OpenVMS • 1978 VAX • 1992 Alpha™ • 2003 IA-64 • 20?? ?

More Related