Re: Stacks, was Segments

On Mon, 20 Jan 2025 22:05:10 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

On Mon, 20 Jan 2025 11:12:54 +0000, Waldek Hebisch wrote:
 

Michael S <already5chosen@yahoo.com> wrote: 

On Sun, 19 Jan 2025 18:28:40 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
 

>
In My 66000 the code cannot read/write that other stack with LD
and ST instructions. It can only be accessed by ENTER (stores)
and EXIT (LDs). The mapping PTE is marked RWE = 000.
>
So, while you can still overrun buffers, you cannot damage the
call/ return stack or the preserved registers !! 

>
Not that I am a specialist in GC, but according to my understanding
the most common and the best performing variants of GC can not work
without read access to preserved registers. Compacting collector
seems to need write access as well.
As to return addresses, I would think that read access to stack of
return addresses is necessary for exception handling. 

>
_Correctness_ of GC depends on ability to see preserved registers
and return address: return address may be the only live reference
to some function and similarly for preserved registers.  On could
try to work around lack of access using separate software-managed
stack duplicating data from "hardware" stack, but that is ugly
and is likely to kill any performance advantage from hardware
features.
>
BTW, the same holds for debuggers and exception handling.  Those
clearly need some way to go around hardware limitations. 

 
Yes, there is a way to do all those things, but I am not in a position
to discuss due to USPTO rules.
 
It is like there is a privilege level between application and GuestOS.
{{I spent all afternoon trying to think of a name for this privilege
above application "non-privileged" and below "privileged". Maybe
meso-privileged ?!?
 

Call it 'user'. Then rename the level that you now call 'application'
to 'sandbox'.

I/O works similarly--in that to the application a page may be marked
RWE=001 (execute only) but the swap disk is allowed to read or write
those pages.