Rev 126 | Rev 133 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 126 | Rev 130 | ||
---|---|---|---|
Line 1... | Line 1... | ||
1 | <?xml version="1.0" encoding="UTF-8"?> |
1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | <appendix id="archspecs"> |
2 | <appendix id="archspecs"> |
3 | <?dbhtml filename="arch.html"?> |
3 | <?dbhtml filename="arch.html"?> |
- | 4 | ||
4 | <title>Architecture specific notes</title> |
5 | <title>Architecture specific notes</title> |
5 | 6 | ||
6 | <section> |
7 | <section> |
- | 8 | <title>AMD64/Intel EM64T</title> |
|
- | 9 | ||
- | 10 | <para>The AMD64 architecture is a 64-bit extension of the older IA-32 |
|
- | 11 | architecture. Only 64-bit applications are supported. Creating this port |
|
- | 12 | was relatively easy, because it shares a lot of common code with IA-32 |
|
- | 13 | platform. However, the 64-bit extension has some specifics, which made the |
|
- | 14 | porting interesting.</para> |
|
- | 15 | ||
- | 16 | <section> |
|
- | 17 | <title>Virtual Memory</title> |
|
- | 18 | ||
- | 19 | <para>The AMD64 architecture uses standard processor defined 4-level |
|
- | 20 | page mapping of 4KB pages. The NX(no-execute) flag on individual pages |
|
- | 21 | is fully supported.</para> |
|
- | 22 | </section> |
|
- | 23 | ||
- | 24 | <section> |
|
- | 25 | <title>TLB-only Paging</title> |
|
- | 26 | ||
- | 27 | <para>All memory on the AMD64 architecture is memory mapped, if the |
|
- | 28 | kernel needs to access physical memory, a mapping must be created. |
|
- | 29 | During boot process the boot loader creates mapping for the first 20MB |
|
- | 30 | of physical memory. To correctly initialize the page mapping system, an |
|
- | 31 | identity mapping of whole physical memory must be created. However, to |
|
- | 32 | create the mapping it is unavoidable to allocate new - possibly unmapped |
|
- | 33 | - frames from frame allocator. The ia32 solves it by mapping first 2GB |
|
- | 34 | memory during boot process. The same solution on 64-bit platform becomes |
|
- | 35 | unfeasible because of the size of the possible address space.</para> |
|
- | 36 | ||
- | 37 | <para>As soon as the exception routines are initialized, a special page |
|
- | 38 | fault exception handler is installed which provides a complete view of |
|
- | 39 | physical memory until the real page mapping system is initialized. It |
|
- | 40 | dynamically changes the page tables to always contain exactly the |
|
- | 41 | faulting address. The page then becomes cached in the TLB and on the |
|
- | 42 | next page fault the same tables can be utilized to handle another |
|
- | 43 | mapping.</para> |
|
- | 44 | </section> |
|
- | 45 | ||
- | 46 | <section> |
|
- | 47 | <title>Mapping of Physical Memory</title> |
|
- | 48 | ||
- | 49 | <para>The AMD64 ABI document describes several modes of program layout. |
|
- | 50 | The operating system kernel should be compiled in a |
|
- | 51 | <emphasis>kernel</emphasis> mode - the kernel is located in the negative |
|
- | 52 | 2 gigabytes (0xffffffff80000000-0xfffffffffffffffff) and can access data |
|
- | 53 | anywhere in the 64-bit space. This wouldn't allow kernel to see directly |
|
- | 54 | more than 2GB of physical memory. HelenOS duplicates the virtual mapping |
|
- | 55 | of the physical memory starting at 0xffff800000000000 and accesses all |
|
- | 56 | external references using this address range.</para> |
|
- | 57 | </section> |
|
- | 58 | ||
- | 59 | <section> |
|
- | 60 | <title>Thread Local Storage</title> |
|
- | 61 | ||
- | 62 | <para>The code accessing thread local storage uses a segment register FS |
|
- | 63 | as a base. The thread local storage is stored in the hidden 64-bit part |
|
- | 64 | of the FS register which must be written using priviledged machine |
|
- | 65 | specific instructions. Special syscall to change this register is |
|
- | 66 | provided to user applications. The TLS address for this platform is |
|
- | 67 | expected to point just after the end of the thread local data.</para> |
|
- | 68 | </section> |
|
- | 69 | ||
- | 70 | <section> |
|
- | 71 | <title>Fast SYSCALL/SYSRET Support</title> |
|
- | 72 | ||
- | 73 | <para>The entry point for system calls was traditionally a speed problem |
|
- | 74 | on IA32 architecture. AMD64 supports a SYSCALL/SYSRET instructions. Upon |
|
- | 75 | encountering SYSCALL instruction, the processor changes privilege mode |
|
- | 76 | and transfers control to an address stored in machine specific register. |
|
- | 77 | Unlike other similar instructions it does not change stack to a known |
|
- | 78 | kernel stack, which must be done by the syscall entry routine. A hidden |
|
- | 79 | part of a GS register is provided to support the entry routine with data |
|
- | 80 | needed for switching to kernel stack.</para> |
|
- | 81 | </section> |
|
- | 82 | ||
- | 83 | <section> |
|
- | 84 | <title>Debugging Support</title> |
|
- | 85 | ||
- | 86 | <para>To provide developers tools for finding bugs, hardware breakpoints |
|
- | 87 | and watchpoints are supported. The kernel also supports self-debugging - |
|
- | 88 | it sets watchpoints on certain data and upon every modification |
|
- | 89 | automatically checks whether a correct value was written. It is |
|
- | 90 | worthwhile to mention, that since this feature was implemented, the |
|
- | 91 | watchpoint was never fired.</para> |
|
- | 92 | </section> |
|
- | 93 | </section> |
|
- | 94 | ||
- | 95 | <section> |
|
- | 96 | <title>Intel IA32</title> |
|
- | 97 | ||
- | 98 | <para>The IA32 architecture uses 4K pages and processor supported 2-level |
|
- | 99 | page tables. Along with AMD64 It is one of the 2 architectures that fully |
|
- | 100 | supports SMP configurations. IA32 is mostly similar to AMD64, it even |
|
- | 101 | shares a lot of code. The debugging support is the same as with AMD64. The |
|
- | 102 | thread local storage uses GS register.</para> |
|
- | 103 | </section> |
|
- | 104 | ||
- | 105 | <section> |
|
- | 106 | <title>MIPS32</title> |
|
- | 107 | ||
- | 108 | <para>Both little and big endian kernels are supported. In order to test |
|
- | 109 | different page size it was set to 16K. The MIPS architecture is TLB-only, |
|
- | 110 | the kernel simulates 2-level page tables. On processors that support it, |
|
- | 111 | lazy FPU context switching is implemented.</para> |
|
- | 112 | ||
- | 113 | <section> |
|
- | 114 | <title>Thread Local Storage</title> |
|
- | 115 | ||
- | 116 | <para>The thread local storage support in compilers is a relatively |
|
- | 117 | recent phenomena. The standardization of such support for MIPS platform |
|
- | 118 | is very new and even the newest versions of GCC cannot generate 100% |
|
- | 119 | correct code. Because of some weird MIPS processor variants, it was |
|
- | 120 | decided, that the TLS pointer will be gathered not from some of the free |
|
- | 121 | registers, but a special instruction was devised and the kernel is |
|
- | 122 | supposed to emulate it. HelenOS expects that the TLS pointer is in the |
|
- | 123 | K1 register. Upon encountering the reserved instruction exception and |
|
- | 124 | checking that the application is requesting a TLS pointer, it returns |
|
- | 125 | the contents of the K1 register. The K1 register is expected to point |
|
- | 126 | 0x7000 bytes after the beginning of the thread local data.</para> |
|
- | 127 | </section> |
|
- | 128 | </section> |
|
- | 129 | ||
- | 130 | <section> |
|
- | 131 | <title>Power PC</title> |
|
- | 132 | ||
- | 133 | <para></para> |
|
- | 134 | </section> |
|
- | 135 | ||
- | 136 | <section> |
|
7 | <title>amd64</title> |
137 | <title>IA-64</title> |
8 | 138 | ||
9 | <para>amd64 bits</para> |
139 | <para></para> |
10 | </section> |
140 | </section> |
11 | </appendix> |
141 | </appendix> |
12 | 142 |