[Info-vax] RMS and SSIO (again)

Arne Vajhøj arne at vajhoej.dk
Tue Jan 11 14:25:19 EST 2022


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.

Arne




More information about the Info-vax mailing list