118 lines
6.4 KiB
Plaintext
118 lines
6.4 KiB
Plaintext
$WW,1$I didn't want to use paged memory mode, but 64-bit mode requires it. For all intents and purposes, virtual mem (paging) is not used. SparrowOS identity maps pages to physical memory. All cores use the same page table map. Page table entries have a granularity of 2 Meg, except the first 2 Meg. It does not swap to disk.
|
||
|
||
SparrowOS always uses 32-bit signed relative jump/call instructions. It is a signed +/- value, so if one part of your code calls a function, the function must be within 2 Gig distance. Therefore, SparrowOS keeps all code in the lowest 2 Gig memory addresses including what would normally be called "the kernel." This lowest 2 Gig I call the "$FG,2$code heap$FG$".
|
||
|
||
The compiler/assembler only creates position independent code. In fact, you can't create code which is loaded at a fixed, specified location. The code is position independent by virtue of the fact that absolute addresses get patched.
|
||
|
||
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_OSMAIN"$- 0x00$TX+D,"0003D83F","DD_OSMAIN_END"$$FG$
|
||
$ID,2$OSMain kernel module, placed here by the boot-loader, $LK,"BOOT_RAM_BASE","MN:BOOT_RAM_BASE"$.
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"0007F000","DD_MP_VECT"$- 0x00$TX+D,"0007F02E","DD_MP_VECT_END"$$FG$
|
||
$ID,2$Multicore start-up vect code, $LK,"MPN_VECT","MN:MPN_VECT"$.
|
||
$ID,-2$
|
||
$FG,2$ 0x000007F600- 0x000007FFFF
|
||
$ID,2$$FG$Boot block relocated here before loading the OSMain module, $LK,"BootCD","FI:::/SparrowOS/Adam/Boot/BootCD.CPP.Z"$ & $LK,"BootHD","FI:::/SparrowOS/Adam/Boot/BootHD.CPP.Z"$.
|
||
$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 space
|
||
$ID,-2$
|
||
$FG,2$ 0x00$TX+D,"00183000","DD_SYS_HEAP_BASE"$- 0x007FFFFFFF$FG$
|
||
$ID,2$Code Heap mem.
|
||
$ID,-2$
|
||
$FG,2$ 0x00E0000000- 0x00FFFFFFFF$FG$
|
||
$ID,2$Various hardware devices have addresses here. 32-bit devices are allocated memory starting at 0xF0000000 going up.
|
||
$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 mapped counting backward from $TX+D,"128 Gig","DD_MAPPED_MEM_SPACE_GIG"$$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,"000007C00","DD_OSMAIN2"$ OSMain
|
||
0000,0000,$TX+D,"0003,D83F","DD_OSMAIN_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,7FFF,FFFF
|
||
$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,1$
|
||
$FG$SethTask
|
||
|
||
$FG,10$
|
||
|
||
|
||
$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:::/SparrowOS/OSMain/OSEnd.CPP.Z,Independent Heap Ctrl Example"$.
|
||
|
||
|