[Info-vax] RMS and SSIO (again)

[Arne Vajhøj]

On 1/11/2022 2:25 PM, Arne Vajhøj wrote:
> On 1/11/2022 2:08 PM, Simon Clubley wrote:
>> On 2022-01-11, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>> On 1/11/2022 1:43 PM, Simon Clubley wrote:
>>>> BTW, am I the only one who thinks it's a pity that stacks don't grow
>>>> upwards towards higher addresses instead of downwards towards lower
>>>> addresses, and with a guard page at the top of the space allocated to
>>>> the stack ?
>>>>
>>>> After all, when using virtual memory, the space allocated to the stack
>>>> isn't actually allocated from memory until its needed.
>>>
>>> I think:
>>>
>>> K stack
>>> E stack
>>> S stack
>>> U stack
>>> unused
>>> U heap
>>>
>>> is more logical than:
>>>
>>> stop
>>> unused
>>> U stack
>>> S stack
>>> E stack
>>> K stack
>>> unused
>>> U heap
>>>
>>> :-)
>>
>> You appear to be thinking in the above diagram that they are all part of
>> one big stack.
> 
> No. 4 items called stack means 4 stacks.
> 
> But they are all in P1 space - together with a lot of other stuff
> not shown - including DCL.
> 
>> That's not correct because the multiple stacks outside of user space
>> all have their own allocated address ranges with page protections to 
>> match.
> 
> KES stacks do have fixed size - similar to MT U stacks.
> 
> But they are still in P1 space.
> 
>> Even if they were contiguous, one stack couldn't grow into another stack
>> and there's no reason why the other non-user stacks couldn't grow upwards
>> within their own allocated address ranges either.
> 
> The KES stacks could be filled up from the bottom instead of from the top.
> 
> But I still think it would look weird to have P1 filled up from 0x4000000.

And there is the practical point of growing from the ends allowing the
division between P0 and P1 to adjust as needed.

Arne