$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 ˜PP 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, HXH €X€ XÄ Ä XÜ Ü ÜÈØ ÈØÌÜ ÈØÌÔ X  X4 4 <` `x<XFxtXJxŒX‚ `Æðx4X4 Æ xTX~ HÆnxXx®X €ÆÐ ÄÆšxâXÆxÂXÚxüXÞ 4Æâx`L` x0Ø0Ødxdx0 xhØhؘx˜xh x xÐØÐØ x  xØØØØxxØ xxDØDØx