::SHE+ILA:: Address Registers

More about ::SHE+ILA:: Address Registers

Very often we need to process each element of an array which itself be nested inside another array (e.g. Foo <:: (1,2,(3,4,5),6,7); ) We may just make a copy (e.g. Innerarray <:: Foo[3]; remember ::SHE+ILA:: is origin 1 (like Fortran) not origin 0 (like C++)) or repeatedly index into the inner array (e.g. ttyout(Foo[3][1], Foo[3][2], Foo[3][3], CRLF);) but that can be rather inefficient if we have to start from the outer array each time. So we have Address Registers (just like C++ pointers). So we can say :
@A <:: &Foo[3];
ttyout(@A[1], @A[2], @A[3], CRLF);
Now, remembering how datastore pages can be mapped into *any* physical RAM pageframe, how does the system avoid the segment processing overhead when a page is swapped in or out? Answer: Each thread has 26 dedicated Address Registers (@A to @Z), predefined, which live in the ::SHE:: protected-mode kernel, and these are automatically updated by the virtual storage handler, so allow for the case where a page is swapped into a different RAM page frame. They are implemented as special-case SEGID's $41 to $5A ("A" to "Z"), normal SEGID's being $80 to $E3 (00 to 99, packed decimal). They don't need declaring in the GHOST (Global Hosting Online Segment Table) or the local variable header of a function, they are automatically built-in (which is why we only have 26 of them). They default to NULL until initialised, and should be reset by the user program to NULL after use (the kernel also sets any Address Registers to NULL which point to a deleted object). As they belong to the ::SHE:: kernel , they cannot be "hacked" by a curious user in order to circumvent protected mode and modify unauthorised store locations. There are *no* ALUops (such as @A++ or @A += 10) allowed on Address Registers. As they must be initialised to point to an existing segment (e.g. @A <:: &Foo[1]) they cannot be made to point into segments not belonging to the user (as specified in the User Account GHOST table).