Files
TempleOS-Rijn/SparrowOS/Doc/Mem.TXT
T
2018-09-08 21:45:28 +02:00

118 lines
6.4 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
$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"$.
̘ ˜,˜,Ä,Ä,Ä Ä ˜ ˜8Ä8Ä8ÄDÄD˜D˜D˜8˜HÄHÄHĬĬ˜¬˜¬˜H
˜°Ä°Ä°ÄèÄè˜è˜è˜°˜øÄøÄøÄT˜ø˜T
˜T˜T¤\¬T¸LÄTÄ”Ät
˜t˜t¤|°t¼lÄt˜t˜”˜”Ä”

DH€ ˆ$=5#?|ð¿
 ˆ<=5#?|ð¿ ˆ\=5#?|ð¿
 ˆt=5#?|ð¿ ˆ”=5#?|ð¿
 ˆ¬=5#?|ð¿ ˆÌ=5#?|ð¿
 ˆä=5#?|ð¿ ˆ=5#?|ð¿
 ˆ=5#?|ð¿ ˆH=5#?|ð¿,ÜÜ€,€,,ˆÜˆÜð,ð,ˆ,øÜøÜ8,8,ø 0X0 hXhX¬ ¬XÄ Ä ÄÈÀÈÀÌÄÈÀ̼X X <H H!x$X.!x\X2!xtXj! HÆØ!xX! ƈ!x<Xf! 0ÆV!xX!x–Xª! hƸ! ¬Æ‚!xÊX®!xªXÂ!xäXÆ! ÆÊ!xHLHxØØLxLxxPØPØ€x€xPxˆx¸Ø¸ØˆxˆxÀØÀØðxðxÀxøx,Ø,Øøxø