Previously the MPW linker script would generate a secondary script to be
executed. This was unnecessarily complicated, and it left some junk in
the build tree.
Whenever a field was added to the end of the Primary System Area (PSA)
record, the offsets of all other fields would change. When reversing NK
version 02.27, I noticed that 32 bytes had been added to the end of the
PSA between 02.27 and 02.28. To build a byte-perfect 02.27, all
references to PSA fields must therefore use the record definition in
NKPublic.s instead of a numeric offset.
In this commit, all PSA references are identified by field name (_FFF if
the field has not yet been reversed).
These + and - characters in a branch mnemonic can cause the assembler to
produce conditional branch instructions with that hint the branch
predictor. The default for forward branches is -, and for backward
branches is +. If a mnemonic is issued with the opposite sign, then bit
10 of the instruction (the LSB of the BO field) is set.
My long-retired "ppcdisasm" script inserted these hints unconditionally,
despite 98% of them not being required. The code is much cleaner now.
I read in some old MPW release notes that PPCAsm and PPCLink together
exhibit a quirk when linking conditional branches to imported symbols.
PPCAsm always assembles these conditional branches as if they were
forward branches (that is, a + hint will always set the hint bit, and a
- hint will never). I hoped to use this property to divine whether the
NanoKernel was linked from one or many assembly files, but I was
frustrated by the lack of conditional branches between files.
Version 02.11 of the NanoKernel prints an annotated crash dump of the
EDP. This version has been partly reversed (using Hopper!), and the
sometimes-cryptic EDP field names have been added to EmulatorPublic.a.
This is part of the work to get the mini running well. The
kcPowerDispatch and kcCacheDispatch entry points were explored. The dead
code implementing a Timer "Heartbeat" was also used to label some
structures better.
CPU plugins are code fragment resources that allow the NanoKernel to
perform CPU-specific functions, such as starting or stopping a processor
core or getting core temperature. They live in the Apple CPU Plugins
file. The Power Manager selects a plugin at boot (or doesn't), prepares
and holds it in memory, and registers it with the NanoKernel using
MPRegisterCpuPlugin(). The NanoKernel can then call any of the plugin's
entry points synchronously using its SIGP() function, which is also
exposed via the MPCpuPlugin() call. The plugin return path is tricky,
but involved the ReturnFromInterrupt trap instruction in the emulator
ROM code.
The CPU plugin calling convention is described in the SIGP comments. CPU
plugins operate in the blue address space, but with interrupts disabled
and supervisor mode on.
This code was reversed to get the Mac mini working. It is not clear how
the Power Manager determines CPU temperature when there are no CPU
registers to do this.
VeryPopularFunction (now GetPARPageInfo) takes a page number in the PAR
and returns a bunch of info on it. The flags of the PTE are copied into
cr5-cr7 of the condition register so that VMCalls can easily make
decisions off of them. I had already figured out the bit flags of the
PTEs Mac OS 9 uses when I reversed PagingFunc1. The definitions are in
the end of the 'Area Definitions.txt' file I sent you a while ago.
If you see a ' bltl cr5, VMDoSomethingWithTLB' (now RemovePageFromTLB)
followed by a ' bltl cr5, major_0x09b40' (now RemovePTEFromHTAB), you
know that the function is manipulating pages directly. RemovePageFromTLB
clears a page from the TLB if it follows a VeryPopularFunction call.
RemovePTEFromHTAB takes a page that is resident in the HTAB and removes
its HTAB entry. cr5_lt is bit 20 (mask 0x800), which my notes tell me is
set when the PTE is in the HTAB. Altogether, the sequence translates to
'if the page is in the HTAB, flush it from the TLB and delete its HTAB
entry'. VMExchangePages uses this (twice) to make sure there are no race
conditions when it is swapping the data in the pages.
I still don't have proof, but I am very very strongly convinced that
KDP.FlatPageListPointer is always equal to the PAR's PageMapArrayPtr.
On an unrelated note, KCMapPage seems to always panic when called on an
area where the PageMapArrayPtr is 2d. I have absolutely no idea why this
happens, but it is bad news for MPMapper because the threshold for
2-dimensionality is around 1 MB. I would have to make 512 separate
CreateArea calls to map all the memory without the NK panicking. I will
have to look into this.
Namely queues, semaphores, critical regions, event groups and
"notifications". The MP calls implementing these services have been
named after their MPLibrary wrapper functions. This convention will be
followed in the future (no more NKCreateEvent).
