Re: Cycles per ASM instruction

"robertwessel2@[EMAIL PROTECTED]
" <robertwessel2@[EMAIL PROTECTED]
> writes:
> When you turned the option on, CP would basically look at channel
> programs to see if they looked like the ISAM ones that were self
> modifying, and would them simulate them separately.  This was none too
> secure, at least in early versions of VM, where real self-modification
> was allowed on a partially virtualized channel program.

ref:
http://www.garlic.com/~lynn/2007e.html#14
Cycles per ASM instruction

one of my first assignments after graduation and going to the science
center 
http://www.garlic.com/~lynn/subtopic.html#545tech

was a week onsite at a customer account trying to get ISAM sup****t
working ... rewritting parts of CCWTRANS ... module in cp67 that
scanned channel program and created "shadow" ... which was actually
executed.

most of ISAM self-modifying wasn't actually modifying the CCWs but the
seek arguments (arm position on the disk). CP67 in addition to translated
the CCWs ... in part to handle virtual->real addresses ... recent thread
in another n.g.
http://www.garlic.com/~lynn/2007e.html#17
A way to speed up level 1 caches

but also to convert the seek arguments for minidisks (i.e. minidisks
where virtual cylinder zero was actually at some other cylinder
position). Setting the "ISAM" option for a "full-pack" minidisk (i.e.
all the virtual arm/seek positions were identical to the real arm/seek
positions) ... would change CCWTRANS so that instead of using a
"shadow" seek argument ... it used the (untranslated) seek argument
located in the virtual address space (instead of translated/shadow
seek argument).

in the standard shadow CCW translation, the seek argument was copied
to a shadow location for use by the shadow seek CCW. When the ISAM
channel program read a new seek argument into its virtual address
space, a normal shadow channel program wouldn't see it; however an
ISAM option (full pack minidisk) shadow channel program would have all
the seek CCWs pointing at the seek arguments in the virtual address
space (rather than a shadow version) and so would pick-up the
dynamically read seek argument. There wasn't a "real" security issue
for full-pack minidisk ... since there was no place the arm could be
moved that would result in a position belonging to some other virtual
machine.

There was another feature for added for VTAM ... where VTAM was
modifying a "live" channel program, on-the-fly ... as part of dynamic
buffer allocation related to reading input from terminals ... where
VTAM would execute a diagnose instruction (after modifying the channel
program) as an indication for CP to retranslate the channel program,
updating the shadow channel program (which is the real live running
version). This characteristic was also somewhat referenced in the
thread about speeding up level 1 caches ... how to (dynamically)
handle an indeterminate amount of incoming data.

other posts in this thread:
http://www.garlic.com/~lynn/2007d.html#62
Cycles per ASM instruction
http://www.garlic.com/~lynn/2007d.html#63
Cycles per ASM instruction
http://www.garlic.com/~lynn/2007d.html#71
Cycles per ASM instruction

and other posts in the thread about speeding up level 1 caches
http://www.garlic.com/~lynn/2007e.html#7
A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#10
A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#11
A way to speed up level 1 caches