50 cores
in [Design]
|
From: John Larkin on 14 Jun 2010 15:41 On Mon, 14 Jun 2010 11:03:57 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >On Jun 14, 8:15�am, John Larkin ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> On Mon, 14 Jun 2010 06:57:17 -0700 (PDT), MooseFET >> >> >> >> <kensm...(a)rahul.net> wrote: >> >On Jun 14, 9:52 pm, John Larkin >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> >> On Sun, 13 Jun 2010 23:52:25 -0700 (PDT), MooseFET >> >> >> <kensm...(a)rahul.net> wrote: >> >> >On Jun 14, 2:19 am, John Larkin >> >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> >> >> On Sun, 13 Jun 2010 09:03:27 -0700 (PDT), MooseFET >> >> >> >> <kensm...(a)rahul.net> wrote: >> >> >> >On Jun 13, 11:28 pm, John Larkin >> >> >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> >> >> >> On Sun, 13 Jun 2010 07:52:12 -0700 (PDT), MooseFET >> >> >> >> >> <kensm...(a)rahul.net> wrote: >> >> >> >> >On Jun 13, 2:09 am, Paul Keinanen <keina...(a)sci.fi> wrote: >> >> >> >> >> On Sat, 12 Jun 2010 09:56:27 -0700 (PDT), MooseFET >> >> >> >> >> >> <kensm...(a)rahul.net> wrote: >> >> >> >> >> >Way back in the tape drive days, seismic systems wrote their data >> >> >> >> >> >onto tape. �They servoed the speed of the drive so that the ADC >> >> >> >> >> >output would be matched so that ony a very little buffering was >> >> >> >> >> >needed. �For marine surveys, the length of time a ship could stay >> >> >> >> >> >at sea was set by the number of tapes the ship could carry a crew >> >> >> >> >> >of perhaps 3 people would spend all day and night changing the >> >> >> >> >> >tapes. �The machine would cycle between 2 or 3 drives. >> >> >> >> >> >> I have never used 1200 BPI tapes, but at least the 800 BPI systems >> >> >> >> >> were extremely picky about keeping the read/write heads perpendicular >> >> >> >> >> to the tape motion. >> >> >> >> >> >> With multiple writing drives, you really had to keep the heads aligned >> >> >> >> >> the same way on all drives, unless you wanted to realign the read head >> >> >> >> >> after each tape :-) >> >> >> >> >> >> At 1600 BPI, each tape channel was individually clocked, so there was >> >> >> >> >> not so much need to keep the R/W head aligned. >> >> >> >> >> >There were lots of odd sorts of drives in the early days: >> >> >> >> >> >There were also the drives called "incremental" drives where the tape >> >> >> >> >was moved by a stepper. �Each bit group was recorded on command. >> >> >> >> >> >There are "analog" drives that where basically audio tape recorders. >> >> >> >> >Some of these were FM where the signal was modulated onto a carrier. >> >> >> >> >Some used other modulations. >> >> >> >> >> >There were tapes with strange numbers of tracks like 13 and 25. >> >> >> >> >> DECtape was cool. Bidirectional, block-structured, fun to watch. >> >> >> >> >I still have a tape. �It was used on a PDP-12. �The PDP-12 was a >> >> >> >machine >> >> >> >with 2 instruction sets. �I was a PDP-8 and also a machine called a >> >> >> >Link. >> >> >> >An I/O operation would flip it over to a Link Mode and back. >> >> >> >> Yeah that was weird. The 8 was a 2's complement machine, and Linc was >> >> >> sign-magnitude! >> >> >> >Yes, the Link ALU was complete with the end around carry. >> >> >IIRC, the Link addressed 2K word pages instead of the 4K >> >> >"fields" of the PDP-8 part. >> >> >> >The OS such as it was had exactly one error message "no". >> >> >> ?0.00 DON'T DO THAT >> >> >The display was a vector graphics on a scope. �The word "no" would >> >appear about mid screen. �The only thing that gave a clue about the >> >error was that the size of the word "no" seemed to vary with what the >> >error was. �The command line was just the name of the program from the >> >tape to be run and the two arguments for it. �You couldn't make a huge >> >number of different errors. >> >> FOCAL printed an error code that was a hash of the program counter at >> the point of error, like �?4.71 �. Every release, all of the error >> codes changed. > >Did it do just one error and then stop? Yes. If so, a recursive decent >parser sounds like the reason. When in doubt call your self. >On error, clear/reload the stack. If they cleared the stack by >popping, the popped value would be the return address. The PDP-8 had no stack. It did a JSR by writing the return address at the first word of the subroutine, and then executing the next word. So an error call was a 1-word JSR to the error handler. It fetched its own first word and printed that as the error code. Subs were not inherently reentrant nor recursive. FOCAL-8 was a combo editor and iterpreter, with floating point and all the usual math functions, that did useful work on a 4K PDP-8. Rick Merrill sythesized stacks and reentrancy and such on top of the barbaric PDP-8 architecture. Its internals influenced the PDP-11 architecture, which in turn affected the 680x and 68K designs. Too bad about Intel. John
From: krw on 14 Jun 2010 18:36 On Sun, 13 Jun 2010 23:52:25 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >On Jun 14, 2:19 am, John Larkin ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> On Sun, 13 Jun 2010 09:03:27 -0700 (PDT), MooseFET >> >> >> >> <kensm...(a)rahul.net> wrote: >> >On Jun 13, 11:28 pm, John Larkin >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> >> On Sun, 13 Jun 2010 07:52:12 -0700 (PDT), MooseFET >> >> >> <kensm...(a)rahul.net> wrote: >> >> >On Jun 13, 2:09 am, Paul Keinanen <keina...(a)sci.fi> wrote: >> >> >> On Sat, 12 Jun 2010 09:56:27 -0700 (PDT), MooseFET >> >> >> >> <kensm...(a)rahul.net> wrote: >> >> >> >Way back in the tape drive days, seismic systems wrote their data >> >> >> >onto tape. They servoed the speed of the drive so that the ADC >> >> >> >output would be matched so that ony a very little buffering was >> >> >> >needed. For marine surveys, the length of time a ship could stay >> >> >> >at sea was set by the number of tapes the ship could carry a crew >> >> >> >of perhaps 3 people would spend all day and night changing the >> >> >> >tapes. The machine would cycle between 2 or 3 drives. >> >> >> >> I have never used 1200 BPI tapes, but at least the 800 BPI systems >> >> >> were extremely picky about keeping the read/write heads perpendicular >> >> >> to the tape motion. >> >> >> >> With multiple writing drives, you really had to keep the heads aligned >> >> >> the same way on all drives, unless you wanted to realign the read head >> >> >> after each tape :-) >> >> >> >> At 1600 BPI, each tape channel was individually clocked, so there was >> >> >> not so much need to keep the R/W head aligned. >> >> >> >There were lots of odd sorts of drives in the early days: >> >> >> >There were also the drives called "incremental" drives where the tape >> >> >was moved by a stepper. Each bit group was recorded on command. >> >> >> >There are "analog" drives that where basically audio tape recorders. >> >> >Some of these were FM where the signal was modulated onto a carrier. >> >> >Some used other modulations. >> >> >> >There were tapes with strange numbers of tracks like 13 and 25. >> >> >> DECtape was cool. Bidirectional, block-structured, fun to watch. >> >> >I still have a tape. It was used on a PDP-12. The PDP-12 was a >> >machine >> >with 2 instruction sets. I was a PDP-8 and also a machine called a >> >Link. >> >An I/O operation would flip it over to a Link Mode and back. >> >> Yeah that was weird. The 8 was a 2's complement machine, and Linc was >> sign-magnitude! > >Yes, the Link ALU was complete with the end around carry. End-around carry? Was it '1's complement or sign-magnitude? End-around carry implies '1's complement. >IIRC, the Link addressed 2K word pages instead of the 4K >"fields" of the PDP-8 part. > >The OS such as it was had exactly one error message "no". >
From: MooseFET on 14 Jun 2010 21:37
On Jun 15, 3:41 am, John Larkin <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 14 Jun 2010 11:03:57 -0700 (PDT), MooseFET > > > > <kensm...(a)rahul.net> wrote: > >On Jun 14, 8:15 am, John Larkin > ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > >> On Mon, 14 Jun 2010 06:57:17 -0700 (PDT), MooseFET > > >> <kensm...(a)rahul.net> wrote: > >> >On Jun 14, 9:52 pm, John Larkin > >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >> On Sun, 13 Jun 2010 23:52:25 -0700 (PDT), MooseFET > > >> >> <kensm...(a)rahul.net> wrote: > >> >> >On Jun 14, 2:19 am, John Larkin > >> >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >> >> On Sun, 13 Jun 2010 09:03:27 -0700 (PDT), MooseFET > > >> >> >> <kensm...(a)rahul.net> wrote: > >> >> >> >On Jun 13, 11:28 pm, John Larkin > >> >> >> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >> >> >> On Sun, 13 Jun 2010 07:52:12 -0700 (PDT), MooseFET > > >> >> >> >> <kensm...(a)rahul.net> wrote: > >> >> >> >> >On Jun 13, 2:09 am, Paul Keinanen <keina...(a)sci.fi> wrote: > >> >> >> >> >> On Sat, 12 Jun 2010 09:56:27 -0700 (PDT), MooseFET > > >> >> >> >> >> <kensm...(a)rahul.net> wrote: > >> >> >> >> >> >Way back in the tape drive days, seismic systems wrote their data > >> >> >> >> >> >onto tape. They servoed the speed of the drive so that the ADC > >> >> >> >> >> >output would be matched so that ony a very little buffering was > >> >> >> >> >> >needed. For marine surveys, the length of time a ship could stay > >> >> >> >> >> >at sea was set by the number of tapes the ship could carry a crew > >> >> >> >> >> >of perhaps 3 people would spend all day and night changing the > >> >> >> >> >> >tapes. The machine would cycle between 2 or 3 drives. > > >> >> >> >> >> I have never used 1200 BPI tapes, but at least the 800 BPI systems > >> >> >> >> >> were extremely picky about keeping the read/write heads perpendicular > >> >> >> >> >> to the tape motion. > > >> >> >> >> >> With multiple writing drives, you really had to keep the heads aligned > >> >> >> >> >> the same way on all drives, unless you wanted to realign the read head > >> >> >> >> >> after each tape :-) > > >> >> >> >> >> At 1600 BPI, each tape channel was individually clocked, so there was > >> >> >> >> >> not so much need to keep the R/W head aligned. > > >> >> >> >> >There were lots of odd sorts of drives in the early days: > > >> >> >> >> >There were also the drives called "incremental" drives where the tape > >> >> >> >> >was moved by a stepper. Each bit group was recorded on command. > > >> >> >> >> >There are "analog" drives that where basically audio tape recorders. > >> >> >> >> >Some of these were FM where the signal was modulated onto a carrier. > >> >> >> >> >Some used other modulations. > > >> >> >> >> >There were tapes with strange numbers of tracks like 13 and 25. > > >> >> >> >> DECtape was cool. Bidirectional, block-structured, fun to watch. > > >> >> >> >I still have a tape. It was used on a PDP-12. The PDP-12 was a > >> >> >> >machine > >> >> >> >with 2 instruction sets. I was a PDP-8 and also a machine called a > >> >> >> >Link. > >> >> >> >An I/O operation would flip it over to a Link Mode and back. > > >> >> >> Yeah that was weird. The 8 was a 2's complement machine, and Linc was > >> >> >> sign-magnitude! > > >> >> >Yes, the Link ALU was complete with the end around carry. > >> >> >IIRC, the Link addressed 2K word pages instead of the 4K > >> >> >"fields" of the PDP-8 part. > > >> >> >The OS such as it was had exactly one error message "no". > > >> >> ?0.00 DON'T DO THAT > > >> >The display was a vector graphics on a scope. The word "no" would > >> >appear about mid screen. The only thing that gave a clue about the > >> >error was that the size of the word "no" seemed to vary with what the > >> >error was. The command line was just the name of the program from the > >> >tape to be run and the two arguments for it. You couldn't make a huge > >> >number of different errors. > > >> FOCAL printed an error code that was a hash of the program counter at > >> the point of error, like ?4.71 . Every release, all of the error > >> codes changed. > > >Did it do just one error and then stop? > > Yes. > > If so, a recursive decent > > >parser sounds like the reason. When in doubt call your self. > >On error, clear/reload the stack. If they cleared the stack by > >popping, the popped value would be the return address. > > The PDP-8 had no stack. It did a JSR by writing the return address at > the first word of the subroutine, and then executing the next word. So > an error call was a 1-word JSR to the error handler. It fetched its > own first word and printed that as the error code. Subs were not > inherently reentrant nor recursive. You can still implement the method even one a machine that doesn't naturally do recursive calls. It is a method of design as well as a method of coding. > FOCAL-8 was a combo editor and iterpreter, with floating point and all > the usual math functions, that did useful work on a 4K PDP-8. Rick > Merrill sythesized stacks and reentrancy and such on top of the > barbaric PDP-8 architecture. I would call the PDP-8 minimalist not barbaric. It was designed while counting transistors. If you want barbaric, look at the CPD1802 or more common 8086. There the goal seems to be to have a large instruction set to boast about without the bother of making the things programmers really need. |