> How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses. Also FWIW, I would vote for @Tony's variant, where you could ask not only about a single byte, but about a block of some specified length. Programming note 2 would have to say "the results are only valid at the instant of execution." Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dan Greiner Sent: Saturday, March 5, 2022 11:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
