153 lines
6.4 KiB
Plaintext
153 lines
6.4 KiB
Plaintext
$WW,1$$FG,5$$TX+CX,"Memory Overview"$$FG$
|
||
|
||
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",A="MN:MemBlksUncachedAlloc"$() or $LK,"MemBlksIndependentAlloc",A="MN:MemBlksIndependentAlloc"$(), then calling $LK,"HeapCtrlBPInit",A="MN:HeapCtrlBPInit"$() and, then, using $LK,"MAlloc",A="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",A="MN:MemRep"$().
|
||
|
||
$FG,5$$TX+CX,"Single System-wide Mem Map"$
|
||
|
||
$FG,2$ 0x0000000000- 0x00$TX,"00006FFF",D="DD_PROTECTED_LOW"$$FG$
|
||
$ID,2$Pages marked not present so NULL ptr dereference causes a fault.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"000360CF",D="DD_KERNEL_END"$$FG$
|
||
$ID,2$Kernel module, placed here by the boot-loader, $LK,"BOOT_RAM_BASE",A="MN:BOOT_RAM_BASE"$.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX,"00096600",D="DD_BOOT_HIGH_LOC"$- 0x00$TX,"00096FFF",D="DD_BOOT_HIGH_LOC_END"$$FG$
|
||
$ID,2$$FG$Boot block relocated here before loading the Kernel module, $LK,"BootCD",A="FI:::/Adam/Boot/BootCD.CPP"$ & $LK,"BootHD",A="FI:::/Adam/Boot/BootHD.CPP"$.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX,"00097000",D="DD_MP_VECT"$- 0x00$TX,"0009702E",D="DD_MP_VECT_END"$$FG$
|
||
$ID,2$Multicore start-up vect code, $LK,"MPN_VECT",A="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,"00100000",D="DD_FIXED_AREA_BASE"$- 0x00$TX,"001845FF",D="DD_FIXED_AREA_END"$$FG$
|
||
$ID,2$$LK,"CSysFixedArea",A="MN:CSysFixedArea"$ for page tables and misc. $TX,"128 Gig",D="DD_MAPPED_MEM_SPACE_GIG"$ of address space mapped.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX,"00184600",D="DD_SYS_HEAP_BASE"$- 0x00$TX,"7FFFFFFF",D="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",A="MN:Mem32DevAlloc"$() flaws are not an issue.
|
||
$ID,-2$
|
||
$FG,2$ 0x0080000000-~0x00DFFFFFFF$FG$
|
||
$FG,2$ 0x0100000000-~0x$TX,"1FFFFFFFFF",D="DD_MAPPED_MEM_SPACE_END"$$FG$
|
||
$ID,2$Data Heap mem.
|
||
$ID,-2$
|
||
$FG,2$ - 0x$TX,"1FFFFFFFFF",D="DD_MAPPED_MEM_SPACE_END"$$FG$$FG$
|
||
$ID,2$64-bit devices are allocated with $LK,"Mem64DevAlloc",A="MN:Mem64DevAlloc"$() counting bwd from $TX,"128 Gig",D="DD_MAPPED_MEM_SPACE_GIG"$, but no PCI devices are actually supported$WW,0$.
|
||
$ID,-2$
|
||
$WW,0$
|
||
$LK,"CBlkPool",A="MN:CBlkPool"$s $LK,"CHeapCtrl",A="MN:CHeapCtrl"$s
|
||
$SP,"",BI=1$
|
||
|
||
|
||
|
||
0000,0000,0000,0000 *NULL Protected
|
||
0000,0000,$TX,"0000,6FFF",D="DD_PROTECTED_LOW2"$ Core 0
|
||
|
||
0000,0000,$TX,"0000,7C00",D="DD_KERNEL2"$ Kernel
|
||
0000,0000,$TX,"0003,60CF",D="DD_KERNEL_END2"$
|
||
|
||
0000,0000,$TX,"0010,0000",D="DD_FIXED_AREA_BASE2"$ FIXED_AREA AdamTask
|
||
|
||
$FG,1$0000,0000,$TX,"0018,4600",D="DD_SYS_HEAP_BASE2"$
|
||
|
||
sys_code_bp
|
||
|
||
$FG$Task
|
||
|
||
|
||
|
||
|
||
Core 1
|
||
SethTask
|
||
|
||
$FG,1$0000,0000,$TX,"7FFF,FFFF",D="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,"001F,FFFF,FFFF",D="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",A="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",A="MN:HeapsInit"$().
|
||
|
||
* See $LK,"Independent Heap Ctrl Example",A="FA:::/Kernel/KEnd.CPP,Independent Heap Ctrl Example"$.
|
||
Ì
|
||
˜ 8 :
|
||
: H
|
||
˜ H ˜ 8
|
||
H ˜ H
|
||
˜ 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 |