[Info-vax] Virtual memory 101 (was Re: Android development...)

[Stephen Hoffman]

On 2014-09-24 11:43:41 +0000,   VAXman-  @SendSpamHere.ORG said:

> In article <54222358$0$24420$c3e8da3$f6268168 at news.astraweb.com>, JF 
> Mezei <jfmezei.spamnot at vaxination.ca> writes:
>> On 14-09-23 21:30, Stephen Hoffman wrote:
>> 
>>> On VAX and Alpha, the change-mode operation — an instruction on VAX, a
>>> PALcode call on Alpha — triggers what is called an exception, and the
>>> exception is then received and processed by the system service
>>> dispatcher, which looks at how it was called, and (it's a dispatcher,
>>> after all) dispatches to the system service.
>> 
>> So basically, the mode switches from user to either exec or kernel only 
>> when the process executes a particular opcode that triggers that 
>> exception, and the exception is granted or rejected based on where the 
>> instruction is located in memory ?
>> 
>> Is this grant or reject decision  properties given to the page of 
>> memory containing that code ? Or is there a page range that defines 
>> system space, and that range is specified in hardware specific physical 
>> memory location ?
> 
> On VAX and Alpha, no.
> On VAX, the CHMx instruction creates a trap which causes the change of 
> access mode to that of 'x' (User, Super, Exec, Kernel)
> On Alpha, CHMx is a PAL code providing, essentially, the same thing.
> It does not matter where in the address space the CHMx or CALL PAL_CHMx 
> are located.

All of which was included in the architecture documentation previously 
referenced.

That same architecture documentation will help you (JF) to a better and 
more general understanding of the implementation of both VAX and Alpha, 
as well; of details well beyond those that you are requesting now.

If you're inclined and want to experiment, you can implement your own 
CHMU-related software on VMS, too.  See the architecture documentation 
and the SYS$DCLCMH system service.

Reading the manuals to somebody is pretty boring.  And slow.

> Hoff's URL containing Ruth's discussion of SSI also contains details of
> the system service dispatch mechanism of each of the architectures.  I'd
> highly suggest you read that article and then, if you still have problems
> comprehending the vehicle which gets one to inner access mode, read the
> associated Internals and Data Structures manuals.

And if you (JF) do decide to read the IDSM and the architecture 
manuals, you'll be asking better questions, and you won't need to ask 
obvious questions.

Better questions are far more interesting to most folks, too.

Carrying this forward to something that's slightly more relevant to VMS 
going forward, there are reference manuals for Intel x86-64 
architecture available for download, as well as small operating systems 
that can demonstrate how the various architectural features can be 
used.  Neither VAX, Alpha nor Itanium being major foci for new 
open-source OS development, after all.  The ARM materials are a little 
more effort to acquire but AFAIK are available, once you sign up over 
there.  The ARMv8 64-bit materials would probably be the most 
interesting in the context of potential future VMS, as back-porting to 
32-bits is more effort than it'd be worth, if (when?) VSI might decide 
to port VMS to that architecture.  If you want to practice with how 
call gates might or would work with VMS, these (architecture manuals, 
IDSM, source listings) are your reference materials.


-- 
Pure Personal Opinion | HoffmanLabs LLC