[LMH]GC Volatility
Steve Krueger
stevelisp@grape-krueger.com
Thu May 27 17:34:00 2004
--------------020402070808060700070307
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
One correction from my previous message. The map on Explorer-I always
looks at MD, except that just after a read or write is started it is
switched temporarily to map the contents of VMA instead. The chief
observable behavior is that you can write MD and then (after a small
delay) do a transporter dispatch (a sequence that does indeed occur if I
remember anything close to what's in the microcode).
My answer is below the question.
nyef@sc.am wrote:
>Now, for the GCVF stuff, the EXPT tests set up the level-2 map values,
>do a memory read (?), do the ((MD) SETM MD) thing just as for a write,
>set up the level-1 map values, and then dispatch. I'm assuming then that
>any read or write activity caches the level-2 map value from VMA and
>then the dispatch compares the GCV fields from the cached level-2 map
>and the level-1 map for the contents of MD at dispatch time to find the
>GCVF value. Does this model bear more than a passing resemblance to
>reality?
>
Actually, it doesn't sound familiar :-(
The GC volatility property is computed from 3 bits in the level 1 map
and 2 bits in the level 2 map.
When a memory access is started and VMA is temporarily mapped by the
level 1 and level 2 mapper, the level 2 GCV bits (LVL2[34:33]) are
latched. After the mapper flips back to mapping MD, logic computes the
GCV fault bit from the 2 latched LVL2 bits and the three bits from LVL1
(LVL1[9:7}).
Here is the only lines of the logic truth table that give a fault:
LVL1 BITS LVL2 BITS GCV FAULT
9 8 7 34 33
0 1 1 0 0 1
0 1 0 0 x 1
0 0 1 1 0 1
0 0 1 0 x 1
0 0 0 x x 1
Note that in LVL1, a code of 00 is the most volatile region while in
LVL2, a code of 11 is the most volatile region. The GVC fault test is
for the LVL1 volatility being greater than or equal to the LVL2 volatility.
GCV is tested on Explorer-I by setting microinstruction bit 10 in a
dispatch instruction. This bit OR's this GCV fault bit into the
dispatch address. Microinstruction bit 11 in a dispatch instruction
does the same with the oldspace bit.
The transporter dispatch for boxed data being read into the machine
tests the data type and the oldspace bit.
The GC-WRITE-TEST dispatch similarly is used to test the data type and
GCV fault bit. If a pointer is being written that points to a more
volatile region than the region to which it is being written, the GC
write test calls a routine to move the object to the less volatile
region and update the pointer in MD, then restart the write.
There are several variations of the transporter dispatch table
(D-TRANSPORT) to handle several situations. Value cells are read with a
slightly different transport dispatch because they can have EVCPs, for
example.
OK, I hope that gets you going again.
BTW, Explorer-II separated the map into two parts, one for address
generation and the other for the GC properties. The GC properties map
was call the address space map (AS Map). Because it only needed to map
region quanta (which are 32 kilowords), and because SRAM devices had
gotten larger, it was a complete map of the entire address space. This
improved performance by several percent as we found that the two level
map structure had a high map fault rate, in part because it needed to
map both the addresses and the region properties.
Because of these changes, the details are a bit different for Explorer
II but the concepts are almost exactly the same. Oh, and the maps
weren't contained in the Hummingbird chip, but rather were on the
processor board, built with standard SRAMS and PALs.
>
>
>>I just dashed this off. I hope it isn't too cryptic.
>>
>>
>
>Not at all. Exactly what I wanted to know, and some extra background
>information. Thank you.
>
>
Great!
-Steve
--------------020402070808060700070307
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<div class="moz-text-html" lang="x-western">One correction from my previous
message. The map on Explorer-I always looks at MD, except that just after
a read or write is started it is switched temporarily to map the contents
of VMA instead. The chief observable behavior is that you can write MD
and then (after a small delay) do a transporter dispatch (a sequence that
does indeed occur if I remember anything close to what's in the microcode).<br>
<br>
My answer is below the question.<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:nyef@sc.am">nyef@sc.am</a>
wrote:<br>
<blockquote type="cite" cite="mid20040526043134.GA8959@sc.am">
<pre wrap="">Now, for the GCVF stuff, the EXPT tests set up the level-2 map values,
do a memory read (?), do the ((MD) SETM MD) thing just as for a write,
set up the level-1 map values, and then dispatch. I'm assuming then that
any read or write activity caches the level-2 map value from VMA and
then the dispatch compares the GCV fields from the cached level-2 map
and the level-1 map for the contents of MD at dispatch time to find the
GCVF value. Does this model bear more than a passing resemblance to
reality?</pre>
</blockquote>
Actually, it doesn't sound familiar :-(<br>
<br>
The GC volatility property is computed from 3 bits in the level 1 map and
2 bits in the level 2 map.<br>
<br>
When a memory access is started and VMA is temporarily mapped by the level
1 and level 2 mapper, the level 2 GCV bits (LVL2[34:33]) are latched. After
the mapper flips back to mapping MD, logic computes the GCV fault bit from
the 2 latched LVL2 bits and the three bits from LVL1 (LVL1[9:7}).<br>
<br>
Here is the only lines of the logic truth table that give a fault:<br>
<br>
LVL1 BITS LVL2 BITS GCV FAULT<br>
9 8 7 34 33<br>
0 1 1 0 0 1<br>
0 1 0 0 x 1<br>
0 0 1 1 0 1<br>
0 0 1 0 x 1<br>
0 0 0 x x 1<br>
<br>
Note that in LVL1, a code of 00 is the most volatile region while in LVL2,
a code of 11 is the most volatile region. The GVC fault test is for the
LVL1 volatility being greater than or equal to the LVL2 volatility.<br>
<br>
GCV is tested on Explorer-I by setting microinstruction bit 10 in a dispatch
instruction. This bit OR's this GCV fault bit into the dispatch address.
Microinstruction bit 11 in a dispatch instruction does the same with the
oldspace bit.<br>
<br>
The transporter dispatch for boxed data being read into the machine tests
the data type and the oldspace bit.<br>
<br>
The GC-WRITE-TEST dispatch similarly is used to test the data type and
GCV fault bit. If a pointer is being written that points to a more volatile
region than the region to which it is being written, the GC write test calls
a routine to move the object to the less volatile region and update the pointer
in MD, then restart the write.<br>
<br>
There are several variations of the transporter dispatch table (D-TRANSPORT)
to handle several situations. Value cells are read with a slightly different
transport dispatch because they can have EVCPs, for example.<br>
<br>
OK, I hope that gets you going again.<br>
<br>
BTW, Explorer-II separated the map into two parts, one for address generation
and the other for the GC properties. The GC properties map was call the
address space map (AS Map). Because it only needed to map region quanta
(which are 32 kilowords), and because SRAM devices had gotten larger, it
was a complete map of the entire address space. This improved performance
by several percent as we found that the two level map structure had a high
map fault rate, in part because it needed to map both the addresses and the
region properties.<br>
<br>
Because of these changes, the details are a bit different for Explorer
II but the concepts are almost exactly the same. Oh, and the maps weren't
contained in the Hummingbird chip, but rather were on the processor board,
built with standard SRAMS and PALs.<br>
<br>
<blockquote type="cite" cite="mid20040526043134.GA8959@sc.am">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">I just dashed this off. I hope it isn't too cryptic.
</pre>
</blockquote>
<pre wrap=""><!---->
Not at all. Exactly what I wanted to know, and some extra background
information. Thank you.
</pre>
</blockquote>
Great!
<pre wrap=""> -Steve
</pre>
</div>
</body>
</html>
--------------020402070808060700070307--