The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


[EMAIL PROTECTED] writes:
> The Prin of Operations, programming notes on using the TR with DAT on,
> state that there will be a performance hit if the second operand
> actually crosses the 4096 line.  This is because it will do a 'mock'
> execution first.
>
> Assuming DAT on, is the performance hit related to the possibility
> that the following 4096 page is not in virtual memory?

way back on 360/67 ... (actually all 360s) TR used to test start &
start+255 (end) address of the table ... which met that if it crossed a
4k page ... it would catch both ... aka page fault both pages ... before
starting instruction execution.

somewhere along the way ... something was raised that TR only uses that
much of the table that the input data-stream might used ... for
instance, if the translation input stream only had values 0-9 ... and
the table was within 256 bytes of the end of an addressable region
... then the instruction might fail (with start+256 precheck) ... even
tho it otherwise could succesfully execute. so the TR instruction was
"fixed" ... if the table start is within 256 bytes of the end of an
addressable boundary... it "pre-executes" the instruction to see if any
input stream bytes would index the table across the boundary.

this would also theoritically have been a problem with 2k key fetch
protect ... and the table was within 256 bytes of a 2k boundary (with
the next 2k, fetch protected) and the input data stream never indexed
anything (in the table) across the addressable boundary.

a past thread that also got into this subject:
http://www.garlic.com/~lynn/2005j.html#36 A second look at memory access 
alignment
http://www.garlic.com/~lynn/2005j.html#37 A second look at memory access 
alignment
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access 
alignment
http://www.garlic.com/~lynn/2005j.html#40 A second look at memory access 
alignment
http://www.garlic.com/~lynn/2005j.html#43 A second look at memory access 
alignment
http://www.garlic.com/~lynn/2005j.html#44 A second look at memory access 
alignment

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to