[LMH] Re: [LMH]bored? read pages 7,8,9 and explain

Steve Krueger stevelisp@grape-krueger.com
Tue, 31 Aug 2004 22:51:54 -0500


This is a multi-part message in MIME format.
--------------060909010707020905020801
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Brad Parker wrote:

>Thanks for the reply!
>
>Unless you scream for mercy I have some more questions... :-)
>

That's fine.  I will copy the whole list as others might also benefit 
from the answers.  I'm not always timely in my answering.  Today, I'm 
able to get right on it.  Other times it might take a week or two.

>
>Steve Krueger wrote:
>  
>
>>Note too that fields can be counted from the left instead of the right 
>>by doing a bit of arithmetic on the position and width. 
>>    
>>
>
>Yes, I believe in the microcode the rotation is counted from the left.
>It seems to be true rototation also, i.e. top most bit comes around to
>bottom.
>

Yes, the rotation is to the left.  I was talking about extracting fields 
using big-endian field specifiers.  That was pretty much a non-sequitur, 
so please ignore.

>
>I think understand how 'pure' ldb and dpb work; it's how the microcode
>is supposed to work that confuses me.
>
>I am calculating the mask as described.  For ldb (mr=0,sr=1) I rotate
>the m-src value left rotatation-count (ir<4-0>) times and then apply the
>mask, like so:
>
>	pos = ir<4-0>
>
>	m_src_value = rotate_left(m_src_value, pos);
>
>	out_bus = (m_src_value & mask) | (a_src_value & ~mask);
>
>For dpb, however, I'm doing exactly the same thing, and I am having trouble
>believing that's correct.  But I can't see any other way.
>

AI Memo 528 makes it clear that the difference between LDB and DPB is 
the MR (mask rotate) bit.  For DPB, MR = 1 so that the mask is shifted 
up (to the left) by the rotation count.  Since the mask moves up by the 
same amount as the M-SRC does, this means that the field in the A-SRC 
that is replaced gets replaced by bits of the M-SRC that started at the 
bottom of the word.

>
>For selective-deposite (mr=1,sr=0), I skip the rotation and just apply the
>mask.  I can believe that is correct.
>

This is correct.  The M-SRC is not rotated but the mask is.

Following exactly the instructions for using the left mask and right 
mask tables on page 8 gets you a rotated mask or a non-rotated mask 
according to the MR bit.

The tables may now seem a clumsy way to generate the mask, but it took 
relatively little logic in late 70's TTL technology.

>
>
>  
>
>>Does this help or are there more questions?
>>    
>>
>
>heh. I think I understand all the ALU operations for IR8=0.  It's the
>multiply/dvide "helper functions" (IR8=1) which I don't get.
>
>Specifically,
>
>ir<7-3> = 0 multiply step
>ir<7-3> = 1 divide step
>ir<7-3> = 2 remainder correction
>ir<7-3> = 3 initial divide step
>
>I understand how to do bit-wise multiply and divide, so I think I can work it
>out from the microcode examples in the text, but I thought I'd ask :-)
>
>[aside: multiply step is described; the divide has me flummoxed; it might be
>that I have a cold :-)]
>
>what exactly do these functions do?
>  
>

OK.  I admit to spending a lot of time trying to understand these 20+ 
years ago.  I'll save this for another day in the interest of actually 
sending the rest of this tonight.  Multiplication is well explained in 
AI Memo 528, but division takes a while to understand and it will take 
me a while to boot strap it.

>
>Oh, and the last frontier for me is "dispatch".  All the copies of 528 I
>have are missing page 18.  I sent some email to some folks at MIT but
>the person in Barker says her copy is also missing page 18...
>

I have a hard copy of AI Memo 528.  I'll dig to see if it has all the pages.

Dispatch *IS* the CADR.  All the really interesting things that the 
microcode does use DISPATCH as a critical part of the algorithm: generic 
arithmetic, flavor support, the transporter, GC write test, 
macroinstruction support, and on and on...

Dispatch is most simply table-indirect goto, but the details aren't all 
that simple.  The selected table entry can JUMP <addr>, JUMP-XCT-NEXT 
<addr>, CALL <addr>, CALL-XCT-NEXT <addr>, RETURN, SKIP or NOP.  Entries 
are selected by a field specifier (as in an LDB) and IOR'ed into the 
table address in the D memory to get the entry.  Furthermore, a DISPATCH 
instruction with the SOA bit set will stack its own address if the entry 
is a call, rather than the address of the next microinstruction (or the 
one after that if -XCT-NEXT).

Other wrinkles add a bit to the entry selection from one of several 
sources, including the memory map and the LC (macroinstruction location 
counter).

>
>(btw: I've hacked up a brute-force cadr simulator; it's not intended to be
>pretty or fast, just accurate.  it's running the prom code from Al's CADR
>all the way to up to wanting to see LABL from the disk label, so with a little
>more work I may get it to load a microcode band.)
>

Good work!

>
>-brad
>
>  
>


--------------060909010707020905020801
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Brad Parker wrote:<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">Thanks for the reply!

Unless you scream for mercy I have some more questions... :-)</pre>
</blockquote>
<br>
That's fine.&nbsp; I will copy the whole list as others might also benefit
from the answers.&nbsp; I'm not always timely in my answering.&nbsp; Today, I'm
able to get right on it.&nbsp; Other times it might take a week or two.<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">

Steve Krueger wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Note too that fields can be counted from the left instead of the right 
by doing a bit of arithmetic on the position and width. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes, I believe in the microcode the rotation is counted from the left.
It seems to be true rototation also, i.e. top most bit comes around to
bottom.</pre>
</blockquote>
<br>
Yes, the rotation is to the left.&nbsp; I was talking about extracting
fields using big-endian field specifiers.&nbsp; That was pretty much a
non-sequitur, so please ignore.<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">

I think understand how 'pure' ldb and dpb work; it's how the microcode
is supposed to work that confuses me.

I am calculating the mask as described.  For ldb (mr=0,sr=1) I rotate
the m-src value left rotatation-count (ir&lt;4-0&gt;) times and then apply the
mask, like so:

	pos = ir&lt;4-0&gt;

	m_src_value = rotate_left(m_src_value, pos);

	out_bus = (m_src_value &amp; mask) | (a_src_value &amp; ~mask);

For dpb, however, I'm doing exactly the same thing, and I am having trouble
believing that's correct.  But I can't see any other way.</pre>
</blockquote>
<br>
AI Memo 528 makes it clear that the difference between LDB and DPB is
the MR (mask rotate) bit.&nbsp; For DPB, MR = 1 so that the mask is shifted
up (to the left) by the rotation count.&nbsp; Since the mask moves up by the
same amount as the M-SRC does, this means that the field in the A-SRC
that is replaced gets replaced by bits of the M-SRC that started at the
bottom of the word.<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">

For selective-deposite (mr=1,sr=0), I skip the rotation and just apply the
mask.  I can believe that is correct.</pre>
</blockquote>
<br>
This is correct.&nbsp; The M-SRC is not rotated but the mask is.<br>
<br>
Following exactly the instructions for using the left mask and right
mask tables on page 8 gets you a rotated mask or a non-rotated mask
according to the MR bit.<br>
<br>
The tables may now seem a clumsy way to generate the mask, but it took
relatively little logic in late 70's TTL technology.<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">


  </pre>
  <blockquote type="cite">
    <pre wrap="">Does this help or are there more questions?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
heh. I think I understand all the ALU operations for IR8=0.  It's the
multiply/dvide "helper functions" (IR8=1) which I don't get.

Specifically,

ir&lt;7-3&gt; = 0 multiply step
ir&lt;7-3&gt; = 1 divide step
ir&lt;7-3&gt; = 2 remainder correction
ir&lt;7-3&gt; = 3 initial divide step

I understand how to do bit-wise multiply and divide, so I think I can work it
out from the microcode examples in the text, but I thought I'd ask :-)

[aside: multiply step is described; the divide has me flummoxed; it might be
that I have a cold :-)]

what exactly do these functions do?
  </pre>
</blockquote>
<br>
OK.&nbsp; I admit to spending a lot of time trying to understand these 20+
years ago.&nbsp; I'll save this for another day in the interest of actually
sending the rest of this tonight.&nbsp; Multiplication is well explained in
AI Memo 528, but division takes a while to understand and it will take
me a while to boot strap it.<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">

Oh, and the last frontier for me is "dispatch".  All the copies of 528 I
have are missing page 18.  I sent some email to some folks at MIT but
the person in Barker says her copy is also missing page 18...</pre>
</blockquote>
<br>
I have a hard copy of AI Memo 528.&nbsp; I'll dig to see if it has all the
pages.<br>
<br>
Dispatch *IS* the CADR.&nbsp; All the really interesting things that the
microcode does use DISPATCH as a critical part of the algorithm:
generic arithmetic, flavor support, the transporter, GC write test,
macroinstruction support, and on and on...<br>
<br>
Dispatch is most simply table-indirect goto, but the details aren't all
that simple.&nbsp; The selected table entry can JUMP &lt;addr&gt;,
JUMP-XCT-NEXT &lt;addr&gt;, CALL &lt;addr&gt;, CALL-XCT-NEXT
&lt;addr&gt;, RETURN, SKIP or NOP.&nbsp; Entries are selected by a field
specifier (as in an LDB) and IOR'ed into the table address in the D
memory to get the entry.&nbsp; Furthermore, a DISPATCH instruction with the
SOA bit set will stack its own address if the entry is a call, rather
than the address of the next microinstruction (or the one after that if
-XCT-NEXT).<br>
<br>
Other wrinkles add a bit to the entry selection from one of several
sources, including the memory map and the LC (macroinstruction location
counter).<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">

(btw: I've hacked up a brute-force cadr simulator; it's not intended to be
pretty or fast, just accurate.  it's running the prom code from Al's CADR
all the way to up to wanting to see LABL from the disk label, so with a little
more work I may get it to load a microcode band.)</pre>
</blockquote>
<br>
Good work!<br>
<blockquote type="cite"
 cite="mid200408311317.i7VDHeSs024908@mwave.heeltoe.com">
  <pre wrap="">

-brad

  </pre>
</blockquote>
<br>
</body>
</html>

--------------060909010707020905020801--