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.
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).
