155 lines
6.5 KiB
Plaintext
155 lines
6.5 KiB
Plaintext
$WW,1$Paging is almost not used, but 64-bit mode requires it to be active. Virtual is identity-mapped to physical. All tasks on all cores use the same page table map, just as though all addresses are physical addresses. 2 Meg page table entries are used, except the first 2 Meg, which uses 4K page tables entries. Nothing swaps to disk, either.
|
||
|
||
In TempleOS, the lowest 2 Gig of memory is called the "$FG,2$code heap$FG$". TempleOS's compiler always uses 32-bit signed relative JMP & CALL instructions because 64-bit CALLs take two instructions. With signed +/- 32-bit values, code can only call a function within 2 Gig distance. Therefore, TempleOS keeps all code in the lowest 2 Gig memory addresses including what would normally be called "the kernel". Two Gig is plenty, don't worry.
|
||
|
||
You can create new, independent heaps by first allocating mem with $LK,"MemBlksUncachedAlloc","MN:MemBlksUncachedAlloc"$() or $LK,"MemBlksNonTaskAlloc","MN:MemBlksNonTaskAlloc"$(), then calling $LK,"HeapCtrlIndependentInit","MN:HeapCtrlIndependentInit"$() and, then, using $LK,"MAlloc","MN:MAlloc"$().
|
||
|
||
Memory allocated by a task will be freed when the task is killed.
|
||
|
||
Eventually, memory will become fragmented, requiring a reboot.
|
||
|
||
See $LK,"MemRep","MN:MemRep"$().
|
||
|
||
$FG,5$$TX+CX,"Single System-wide Mem Map"$
|
||
|
||
$FG,2$ 0x00$TX+D,"00007C00","DD_KERNEL"$- 0x00$TX+D,"0003DADF","DD_KERNEL_END"$$FG$
|
||
$ID,2$Kernel module, placed here by the boot-loader, $LK,"BOOT_RAM_BASE","MN:BOOT_RAM_BASE"$.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"0003DAE0","DD_COMPILER"$- 0x00$TX+D,"00078FFF","DD_COMPILER_END"$$FG$
|
||
$ID,2$Compiler module, loaded by $LK,"LoadCompiler","MN:LoadCompiler"$().
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"00096600","DD_BOOT_HIGH_LOC"$- 0x00$TX+D,"00096FFF","DD_BOOT_HIGH_LOC_END"$$FG$
|
||
$ID,2$$FG$Boot block relocated here before loading the Kernel module, $LK,"BootCD","FI:::/TempleOS/Adam/Boot/BootCD.CPP"$ & $LK,"BootHD","FI:::/TempleOS/Adam/Boot/BootHD.CPP"$.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"00097000","DD_MP_VECT"$- 0x00$TX+D,"0009702E","DD_MP_VECT_END"$$FG$
|
||
$ID,2$Multicore start-up vect code, $LK,"MPN_VECT","MN:MPN_VECT"$.
|
||
$ID,-2$
|
||
$FG,2$~0x000009F000- 0x000009FFFF
|
||
$ID,2$$FG$Extended BIOS data area.
|
||
$ID,-2$
|
||
$FG,2$ 0x00000A0000- 0x00000BFFFF$FG$
|
||
$ID,2$VGA graphics mem, marked as write-through cache.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"00100000","DD_PAGE_TABLE_BASE"$- 0x00$TX+D,"00182FFF","DD_PAGE_TABLE_END"$$FG$
|
||
$ID,2$Page tables, $TX+D,"128 Gig","DD_MAPPED_MEM_SPACE_GIG"$ of address space
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"00183000","DD_SYS_HEAP_BASE"$- 0x00$TX+D,"7FFFFFFF","DD_SYS_HEAP_LIMIT"$$FG$
|
||
$ID,2$Code Heap mem.
|
||
$ID,-2$
|
||
$FG,2$ 0x00E0000000- 0x00FFFFFFFF$FG$
|
||
$ID,2$32-bit devices could allocate memory at 0xF0000000 going up, but this is wrong, since some PCs already have devices at 0xF0000000. No PCI devices are supported, so $LK,"Mem32DevAlloc","MN:Mem32DevAlloc"$() flaws are not an issue.
|
||
$ID,-2$
|
||
$FG,2$ 0x0080000000-~0x00DFFFFFFF$FG$
|
||
$FG,2$ 0x0100000000-~0x$TX+D,"1FFFFFFFFF","DD_MAPPED_MEM_SPACE_END"$$FG$
|
||
$ID,2$Data Heap mem.
|
||
$ID,-2$
|
||
$FG,2$ - 0x$TX+D,"1FFFFFFFFF","DD_MAPPED_MEM_SPACE_END"$$FG$$FG$
|
||
$ID,2$64-bit devices are allocated with $LK,"Mem64DevAlloc","MN:Mem64DevAlloc"$() counting backward from $TX+D,"128 Gig","DD_MAPPED_MEM_SPACE_GIG"$, but no PCI devices are actually supported$WW,0$.
|
||
$ID,-2$
|
||
$WW,0$
|
||
$LK,"CBlkPool","MN:CBlkPool"$s $LK,"CHeapCtrl","MN:CHeapCtrl"$s
|
||
$SP,"",1$
|
||
|
||
0000,0000,0000,0000 Core 0
|
||
|
||
0000,0000,$TX+D,"0000,7C00","DD_KERNEL2"$ Kernel
|
||
0000,0000,$TX+D,"0003,DADF","DD_KERNEL_END2"$
|
||
|
||
0000,0000,$TX+D,"0003,DAE0","DD_COMPILER2"$ Compiler
|
||
0000,0000,$TX+D,"0007,8FFF","DD_COMPILER_END2"$
|
||
|
||
0000,0000,$TX+D,"0010,0000","DD_PAGE_TABLE_BASE2"$ Page_Tables AdamTask
|
||
|
||
$FG,1$0000,0000,$TX+D,"0018,3000","DD_SYS_HEAP_BASE2"$
|
||
|
||
sys_code_bp
|
||
|
||
$FG$Task
|
||
|
||
|
||
|
||
|
||
Core 1
|
||
SethTask
|
||
|
||
$FG,1$0000,0000,$TX+D,"7FFF,FFFF","DD_SYS_HEAP_LIMIT2"$
|
||
$FG,10$0000,0000,8000,0000
|
||
|
||
|
||
$FG,10$
|
||
sys_data_bp
|
||
$FG$Task
|
||
$FG,10$0000,0000,DFFF,FFFF
|
||
$FG,6$0000,0000,F000,0000 32-bit devices
|
||
|
||
$FG,10$0000,0001,0000,0000
|
||
$FG$
|
||
SethTask
|
||
|
||
|
||
|
||
$FG,10$
|
||
sys_data_bp$FG,0$ Core n
|
||
|
||
|
||
|
||
$FG,4$
|
||
Independent
|
||
|
||
|
||
|
||
$FG,6$
|
||
64-bit devices
|
||
|
||
0000,$TX+D,"001F,FFFF,FFFF","DD_MAPPED_MEM_SPACE_END2"$
|
||
|
||
$WW,1$$FG$* Note: There is a break in the data-heap block pool. This has no effect except the obvious effect that fragmentation has on contiguous requests. I can $LK,"MAlloc","MN:MAlloc"$() an 8 Gig chunk on my 12 Gig machine.
|
||
|
||
* Note: For systems with less than 2 Gig RAM, the code and data heap block pools are the same. For systems with 2-4 Gig of RAM, the code heap is 1/4 of the total. See $LK,"HeapsInit","MN:HeapsInit"$().
|
||
|
||
* See $LK,"Independent Heap Ctrl Example","FA:::/TempleOS/Kernel/KEnd.CPP,Independent Heap Ctrl Example"$.
|
||
|
||
˜
|
||
0
|
||
0 ˜ 0
|
||
˜ 0 ˜
|
||
˜ 8 8
|
||
8 H
|
||
H ˜ H
|
||
˜ H ˜ 8
|
||
˜ P P
|
||
P `
|
||
` ˜ `
|
||
˜ ` ˜ P
|
||
˜ ` Ä `
|
||
Ä ` Ä Ä
|
||
Ä Ä ˜ Ä
|
||
˜ Ä ˜ `
|
||
|
||
˜ È Ä È
|
||
Ä È Ä
|
||
Ä ˜
|
||
˜ ˜ È
|
||
˜ Ä
|
||
Ä Ä l
|
||
˜ ˜ l ˜ l ˜ l ¤ t ¬ l ¸ d Ä l
|
||
Ä ¬ Ä Œ ˜ Œ ˜ Œ ¤ ” ° Œ ¼ „ Ä Œ
|
||
˜ Œ ˜ ¬
|
||
˜ ¬ Ä ¬
|
||
|
||
D ` ¸ÿÿÿ¿ ˆ < È _O|ð¿
|
||
ˆ T È _O|ð¿ ˆ t È _O|ð¿
|
||
ˆ Œ È _O|ð¿ ˆ ¬ È _O|ð¿
|
||
ˆ Ä È _O|ð¿ ˆ ä È _O|ð¿
|
||
ˆ ü È _O|ð¿ ˆ È _O|ð¿
|
||
ˆ 4 È _O|ð¿ ˆ ` È _O|ð¿ , Ü Ü ˜ , ˜ , , Ü Ü , , , Ü Ü P , P ,
|
||
H X H
|
||
€ X €
|
||
X Ä Ä
|
||
X Ü Ü
|
||
Ü È Ø
|
||
È Ø Ì Ü
|
||
È Ø Ì Ô
|
||
X
|
||
X 4 4
|
||
< ` ` x < X F x t X J x Œ X ‚ ` Æ ð x 4 X 4 Æ x T X ~ H Æ n x X x ® X  € Æ Ð Ä Æ š x â X Æ x  X Ú x ü X Þ 4 Æ â x ` L ` x 0 Ø 0 Ø d x d x 0 x h Ø h Ø ˜ x ˜ x h x x Ð Ø Ð Ø x x Ø Ø Ø Ø x x Ø x x D Ø D Ø x |