From stevelisp@grape-krueger.com Wed Sep 1 04:51:54 2004 From: stevelisp@grape-krueger.com (Steve Krueger) Date: Tue, 31 Aug 2004 22:51:54 -0500 Subject: [LMH] Re: [LMH]bored? read pages 7,8,9 and explain In-Reply-To: <200408311317.i7VDHeSs024908@mwave.heeltoe.com> References: <200408311317.i7VDHeSs024908@mwave.heeltoe.com> Message-ID: <4135475A.9020309@sbcglobal.net> 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 , JUMP-XCT-NEXT , CALL , CALL-XCT-NEXT , 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 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-- From amoroso@mclink.it Thu Sep 2 01:10:02 2004 From: amoroso@mclink.it (Paolo Amoroso) Date: Thu Sep 2 00:10:02 2004 Subject: [LMH]CADR software/images? In-Reply-To: (Daniel Seagraves's message of "Fri, 27 Aug 2004 13:58:25 -0500 (CDT)") References: <20040805215244.1A1573C7A@spies.com> Message-ID: <87zn49t84p.fsf@plato.moon.paoloamoroso.it> Daniel Seagraves writes: > Does anyone know if anyone out there in net-land has CADR software? Ronald Burkey has written an outstanding emulator of the Apollo Guidance Computer (this makes the geekmeter go off-scale): Virtual AGC http://www.sandroid.org/Apollo/index.html The emulator is able to run the actual software used with the Apollo command and lunar modules. Ronald tells at his site about his Indiana Jones-like experience in the quest for AGC documentation and software: yaAGC Documentation Quest http://www.sandroid.org/Apollo/QuestForInfo.html Since the AGC was developed at MIT, his tips might be of some use also to those who are chasing MIT Lisp Machine material. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From cgd@theworld.com Sat Sep 11 09:19:01 2004 From: cgd@theworld.com (Daniels) Date: Sat Sep 11 08:19:01 2004 Subject: [LMH]CADR software/images? References: <200408301755.i7UHtUKa009833@mwave.heeltoe.com> Message-ID: <000201c49819$55bab400$6502a8c0@NEMO> My apologies to Mr. Parker and Mr. Swindells for confusing the source of Mr. Parker's satement Although I haven't had any contact with Mr. Shmidt, I must admire him for sticking with Symbolics. I have only a vague sense of A.T.'s intentions, but I did get the strong impression that he is in no way interested in letting anyone contract to port OpenGenera to other platforms, with payment being in licences to use the finished product. If you are a government contractor, you may have a better chance of getting the attention of Symbolics. From mcmax@lisp.it Wed Sep 22 07:34:00 2004 From: mcmax@lisp.it (Massimo Spataro) Date: Wed Sep 22 06:34:00 2004 Subject: [LMH]Lispmachine Emulator of old engine Message-ID: <02ac01c4a0b1$f877e8c0$ae00000a@ws001> This is a multi-part message in MIME format. ------=_NextPart_000_02A9_01C4A0C2.BBE0ADA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nuova pagina 1 I have find this work on progress more advance and userfully http://www.heeltoe.com/retro/lispm/l-machine.html This is another work for run oldLispEngine with free Emulator into Free = Ia32 platform Linux. mcmax ------=_NextPart_000_02A9_01C4A0C2.BBE0ADA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nuova pagina 1
 
 
I have find this work on progress more advance and userfully
 
http://www.hee= ltoe.com/retro/lispm/l-machine.html
 
This is another work for run oldLispEngine with free Emulator into = Free=20 Ia32 platform Linux.
 
mcmax
------=_NextPart_000_02A9_01C4A0C2.BBE0ADA0-- From aek@spies.com Wed Sep 22 13:08:01 2004 From: aek@spies.com (Al Kossow) Date: Wed Sep 22 12:08:01 2004 Subject: [LMH]Re: LispM-Hackers digest, Vol 1 #288 - 1 msg In-Reply-To: <20040922200102.27820.qmail@kappa.unlambda.com> Message-ID: <20040922200755.A7CEE3C63@spies.com> >http://www.heeltoe.com/retro/lispm/l-machine.html Brad is on the list. 3600 simulation is stuck due to Symbolics lack of interest in releasing the old code. Some progress is being made in finding CADR/LM-2 load bands. More news as it develops. From stevelisp@grape-krueger.com Wed Sep 1 04:51:54 2004 From: stevelisp@grape-krueger.com (Steve Krueger) Date: Tue, 31 Aug 2004 22:51:54 -0500 Subject: [LMH] Re: [LMH]bored? read pages 7,8,9 and explain In-Reply-To: <200408311317.i7VDHeSs024908@mwave.heeltoe.com> References: <200408311317.i7VDHeSs024908@mwave.heeltoe.com> Message-ID: <4135475A.9020309@sbcglobal.net> 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 , JUMP-XCT-NEXT , CALL , CALL-XCT-NEXT , 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 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--