$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˜ ˜88 8H H˜H ˜H˜8 ˜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