🚀 go-pugleaf

Rich Alderson <ne...@alderson.users.panix.com> wrote in
news:mddh8...@panix5.panix.com: 

> When introduced to the PDP-10, 8 years later, I found it annoying:  No
> base register, only a single index register per instruction, so some of
> my favorite tricks simply did not work.  No condition codes; what's
> with all these SKIPx and JUMPx and Txxx (test) instructions?  And then
> a miracle happened. 
> 
> I still think in EBCDIC, nearly 50 years later, rather than ASCII,
> which I sort of learned less than 40 years ago, and I still have a
> fondness for the 360 instruction architecture, but the orthogonality of
> the PDP-10 instruction set, the uniform use of bits 7-8 to indicate
> no-modification/immediate/memory/self on all the data movement
> instructions, the elegance of single instructions to conditionalize the
> execution path rather than a sequence in which you have to be careful
> of changes to the condition codes you're checking, even the word 
> addressing rather than byte addressing, have forever spoiled me for
> lesser systems.

I loved the -10 for its orthogonal instruction set.  It could be displayed 
on a single page of the programming card.  It didn't take long to learn.
I had started out on the IBM 1620, and then wrote extensively in assembler 
for the PDP-9 and when I came to the PDP-10 the family resemblance made it 
familiar but oh! so much better.

I never did much with the 360, but when I did, I was always having to look 
up instruction descriptions to understand what they actually did.  I never 
developed any affection for it.

The Data General Nova instruction set was (sort of) admirable for its cut-
down simplicity.  The DG Eclipse had to be admired for the way they added a 
lot of useful instructions, while still being 100% compatible with the Nova, 
but pretty it was not.  Even more so with the 32-bit MV series.

I did a little coding for the CDC 6xxx.  There were some clever things in 
that design, but I never thought it was elegant.

On Friday, August 10, 2018 at 7:10:03 PM UTC-4, Alfred Falk wrote:
> The Data General Nova instruction set was (sort of) admirable for its cut-
> down simplicity.  The DG Eclipse had to be admired for the way they added a 
> lot of useful instructions, while still being 100% compatible with the Nova, 
> but pretty it was not.  Even more so with the 32-bit MV series.

The Nova was an interesting beast and elegant in its own way - quite a step up from the sparseness of the PDP-8, but not all of the bells and whistles (and "special" memory locations) of the PDP-11.

I was a developer on one non-DG operating system for the Nova, and a maintainer for another. Some time later, Data General sent me a stack of my STRs (bug reports) for RDOS and Extended BASIC back, along with a large pile of other people's STRs and source tapes for both, with a note that essentially said "Congratulations! You're now the maintainer." To be fair, I did give them an XBASIC STR that was fundamentally unsolveable (ask if you want the details).

The Eclipse ("Real" Eclipse, not "Big Bird") was pretty clean, too. The Nova 3 and Eclipse S/200 were essentially the same product ('181 ALUs) but the Eclipse had more microcode. Likewise for the Nova 4 and Eclipse S/140 (29K-series ALUs). This all pre-dated studies on instruction set complexity vs. speed (like when DEC found out that a good percentage of the VAX instruction set could be replaced by emulator traps and emulated by the remaining instructions without penalty). As part of maintaining RDOS, I built all of the zillion xRDOS flavors and they all ran about the same speed on my test S/230. So, whenever I was working in a piece of code that had conditionals for different processors, I would optimize out a lot of those special cases.

Don't get me started on Big Bird. It kept the DG from hitting the skids earlier than it did, but it was too little, too late, too expensive (as in "not enough cheaper than a VAX-11/780 to justify going with those oddballs from DG").

Very little is made of the M/600 which was its own kettle of fish, a mini trying to steal market share from the lower end of the IBM 370 product line (mostly Models 115 and 125).

And then there was the mN601. I'd call that an interesting first effort, but the low price of the chip was offset by the rather complicated support circuitry, and if you actually wanted to run regular DG peripherals and software, the price savings over a discrete CPU were small and the performance loss was big.

Rich Alderson <ne...@alderson.users.panix.com> writes:

> Charles Richmond <nume...@aquaporin4.com> writes:
>
>> On 8/9/2018 1:45 PM, Rich Alderson wrote:
>>> Elliott Roper <nos...@yrl.co.uk> writes:
>
>>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):
>
>>>>> Bitsavers uploaded the system manual for the PDP 11/40.
>
>>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_manual.pdf
>
>>>>> 358 pages, undated.
>
>>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>>> PDP-11?
>
>>> Yes, many.
>
>> *Not* that I disagree...  but which other computers do you find elegant???
>
> My first computer was the IBM 1401.  *Not* an elegant architecture, but not
> without points of interest.

1401 was my first also.  One could do quite a bit in a small amount of
storage.  The A and B registers would tell you about the data the
previous instruction processed.  (Usually where the word mark was.)
Word marks were like the trailing null with C strings without the bother.

A shame none of that carried over to the S/360.
We could have had a 7 bit character with one bit reserved for the word mark.

> The first I fell in love with was the IBM System/360, thanks to a high school
> graduation gift from a sweetheart, Germain's _Programming the IBM 360_.  One of
> these days I'm going to put his simulator on Hercules and go through the
> exercises just for giggles.

Likewise, my next system was S/360 and I accumulated extensive
experience with the machine.  My first impression was that the machine
was over-complicated, on purpose.  The lack of sector addressing on
the disks is my best example.  After using disks for years on a 1440,
disks became more complicated than I thought they should be.
3270s are another example.  A simple thing like screen addressing
couldn't be done with row/column numbers in bytes?

The 24 bit addressing was more a failure in the programming department
than in hardware design.  Why any programmer would attempt to use
the high order byte for data instead of just assuming it would be
part of the address some day is a mystery.  IBM stepped in it big
putting a 3 byte address right in the DCB.  A DCB without a version
number or other reliable marker.  Still a problem to this day,

I've done huge amounts of assembly programming and the instructions
get the job done.  Issues with the base registers are easy to deal with
once you figure out that each subroutine should have it's own base
register, don't attempt to make all code addressible at once.

-- 
Dan Espen

On Sat, 11 Aug 2018 10:25:14 -0400, Dan Espen wrote:

> 1401 was my first also.  One could do quite a bit in a small amount of
> storage.  The A and B registers would tell you about the data the
> previous instruction processed.  (Usually where the word mark was.)
> Word marks were like the trailing null with C strings without the
> bother.

I was given this by an ex-student this week (not sure if I posted this 
link already, so apologies for any duplication):

 http://amzn.eu/iaBtlkb 

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

terry-...@glaver.org writes:

> To be fair, I did give them an XBASIC STR that was fundamentally
> unsolveable (ask if you want the details).

There's nothing like a good debugging war story -- go on, then!

I've been learning PDP-10 assembler lately (through playing with ITS);
it's a really interesting architecture from the perspective of someone
who grew up with 80s micros. The combination of regularity and multiple
ways to do similar operations means there's a very satisfying
puzzle-solving aspect to it...

-- 
Adam Sampson <a...@offog.org>                         <http://offog.org/>

On Sat, 11 Aug 2018 22:16:46 +0100, Adam Sampson wrote:

> terry-...@glaver.org writes:
> 
>> To be fair, I did give them an XBASIC STR that was fundamentally
>> unsolveable (ask if you want the details).
> 
> There's nothing like a good debugging war story -- go on, then!
> 
> I've been learning PDP-10 assembler lately (through playing with ITS);
> it's a really interesting architecture from the perspective of someone
> who grew up with 80s micros. The combination of regularity and multiple
> ways to do similar operations means there's a very satisfying
> puzzle-solving aspect to it...

Especially when you find that JUMP and SKIP are no-ops.

Hi, Adam!

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Dan Espen <dan1...@gmail.com> wrote:
> I've done huge amounts of assembly programming and the instructions
> get the job done.  Issues with the base registers are easy to deal with
> once you figure out that each subroutine should have it's own base
> register, don't attempt to make all code addressible at once.
> 

My copy of Pugh is packed, but I think this was the intention. 4K can be a
bit small for a subroutine, but I think the designers expected programmers
to divide their programs into smallish subroutines. I don't think I've
written a lot of programs that needed multiple base registers. On the other
hand it's more complicated than it needs to be to save a base register and
load a new one - especially if you want to write reentrant code, where the
recommended technique requires OS intervention to get a free the savearea.
A hardware stack would have helped. and maybe one instruction to push a
register and load it with the address of the next instruction.


-- 
Pete

On Sat, 11 Aug 2018 22:16:46 +0100, Adam Sampson wrote:

> terry-...@glaver.org writes:
> 
>> To be fair, I did give them an XBASIC STR that was fundamentally
>> unsolveable (ask if you want the details).
> 
> There's nothing like a good debugging war story -- go on, then!

Here's another, although Adam at least may know it:

Our ICL 2960 had a homebrew operating system that was very reliable (far 
more than VME/K ever was).

And then one day it all began to fall apart. The machine just stopped. No 
crash, nothing. The engineer's panel indicated that the microcode had 
halted. We re-IPLed the system, and an hour or two later it stopped 
again. Eventually we called the engineers, and they ran tests. Lots of 
them. They pronounced that there was nothing wrong.

Then the 'crashes' stopped, for a couple of weeks. Then they started 
again. We couldn't get a handle on what was wrong at all. It was 
eventually decided that, the next time it happened, I should use the 
engineer's panel, for as long as it took, to investigate the state of the 
machine. In the event, I simply dumped out all the target machine 
registers, and the microcode PC.

Our engineers obligingly left a microcode training manual lying around, 
together with a microfiche listing of the microcode. Oh, and some circuit 
diagrams. I retired to a darkened room for much of that day; and the 
next. Eventually I emerged with the reason for the crashes. Without going 
into too much technical detail, it seemed that the microcode and the 
hardware handed off tasks to each other; in particular, a part of the 
hardware called the 'scheduler' was responsible for validating the type 
field in the descriptor register during the execution of any instruction 
that used a descriptor to access an operand. Any invalid type was 
trapped, and sent back to the microcode to force an exception (known as a 
'contingency'). All other type values were considered valid, and passed 
back to the microcode to be used in accessing a jump table, thence 
invoking the right bit of microcode for that descriptor type.

So, what was going wrong? It turned out that there was what can only be 
described as a hardware design error. The scheduler didn't detect one 
particular invalid type code, so it handed it back to the microcode, 
which accessed the jump table with it. This of course accessed an entry 
marked 'can never happen', and the microcode halted. We later discovered 
that a physicist's errant FORTRAN program was overwriting a descriptor, 
and generating the bad type value. If the machine stopped, he just 
submitted the job again until he got fed up and went off for a week or 
two. Then he tried again, never noticing the causal connection.

We contacted ICL, but we never seemed to reach anyone who either 
understood what the problem was, or had the power or inclination to get 
it fixed (which would not have been a quick job, in any case).

So I decided I had better fix this another way. Back to the microcode 
listing. I found an empty patch area, and hand assembled a new bit of (60 
bit wide) microcode which I linked to the right jump table entry. All 
this did was generate a 'descriptor error' contingency with a hitherto 
unused subtype code. I then wrote a tool to extract the microcode from 
the system disk, patch it, and put it back again. We IPLed the system, 
and tested it (by this time I had a test program). Success - it correctly 
triggered the new contingency and the microcode didn't halt!

The only thing left to do was to modify the various components of the 
operating system to do the right thing, culminating in a change to the 
FORTRAN run-time system to generate a suitable message. That only took me 
a few minutes.

We had no more microcode halts and the users were happy. 

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Peter Flass <peter...@yahoo.com> writes:

> Dan Espen <dan1...@gmail.com> wrote:
>> I've done huge amounts of assembly programming and the instructions
>> get the job done.  Issues with the base registers are easy to deal with
>> once you figure out that each subroutine should have it's own base
>> register, don't attempt to make all code addressible at once.
>> 
>
> My copy of Pugh is packed, but I think this was the intention. 4K can be a
> bit small for a subroutine, but I think the designers expected programmers
> to divide their programs into smallish subroutines. I don't think I've
> written a lot of programs that needed multiple base registers. On the other
> hand it's more complicated than it needs to be to save a base register and
> load a new one - especially if you want to write reentrant code, where the
> recommended technique requires OS intervention to get a free the savearea.
> A hardware stack would have helped. and maybe one instruction to push a
> register and load it with the address of the next instruction.

Not really that hard:

 LARL R11,SUB1   R11 <- subroutine address and base
 BALR R14,R11   Go to subroutine

...

SUB1 DS 0H
 USING R11,*
 STM   R2,R14,SUB1_SAVE
do something
 LM    R2,R14,SUB1_SAVE
 BR  R14
 DROP R11

Of course, there are always macros for the LARL/BALR and subroutine
entry and exit so it looks like:

 XBAL SUB1

...

SUB1 ENT
 do something
 LEAVE

The macros push the subroutine name
into a macro array for later automatic save area generation.

I'm never clear on what happens when you exceed
the limits of a hardware stack.

-- 
Dan Espen

In article <ft933kF...@mid.individual.net>,
Bob Eager  <news...@eager.cx> wrote:
>Especially when you find that JUMP and SKIP are no-ops.

Anyone who thought that SKIP was a no-op wasn't paying attention.

I agree that it didn't skip.

R's,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <pkpgkg$grv$1...@dont-email.me>,
Dan Espen  <dan1...@gmail.com> wrote:
>Not really that hard:
>
> LARL R11,SUB1   R11 <- subroutine address and base
> BALR R14,R11   Go to subroutine

LARL?  No 360 I ever used had that instruction.

Also, the standard calling sequence put the entry point in R15.

Pedantically,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

"Huge"  wrote in message news:ftagv1FqhqfU2@mid.individual.net... 

>Eventually, they sent a guru. He spent all of about 30 seconds in the
>machine room; he ejected the 8" floppy disk containing the machine's
>microcode, looked at the label on the disk and said "This is the wrong
>microcode for this machine - this is for a FPU machine and you don't
>have an FPU", got back in his taxi and left. A new floppy came, we
>booted from it and all was well.

  You got all the way to Stage 5 of Field Service Support escalation!

http://nemesis.lonestar.org/stories/stages.html

  At my first job, we got that far twice.

--

Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net

Dan Espen <dan1...@gmail.com> wrote:
> Peter Flass <peter...@yahoo.com> writes:
> 
>> Dan Espen <dan1...@gmail.com> wrote:
>>> I've done huge amounts of assembly programming and the instructions
>>> get the job done.  Issues with the base registers are easy to deal with
>>> once you figure out that each subroutine should have it's own base
>>> register, don't attempt to make all code addressible at once.
>>> 
>> 
>> My copy of Pugh is packed, but I think this was the intention. 4K can be a
>> bit small for a subroutine, but I think the designers expected programmers
>> to divide their programs into smallish subroutines. I don't think I've
>> written a lot of programs that needed multiple base registers. On the other
>> hand it's more complicated than it needs to be to save a base register and
>> load a new one - especially if you want to write reentrant code, where the
>> recommended technique requires OS intervention to get a free the savearea.
>> A hardware stack would have helped. and maybe one instruction to push a
>> register and load it with the address of the next instruction.
> 
> Not really that hard:
> 
>  LARL R11,SUB1   R11 <- subroutine address and base
>  BALR R14,R11   Go to subroutine
> 
> ...
> 
> SUB1 DS 0H
>  USING R11,*
>  STM   R2,R14,SUB1_SAVE
> do something
>  LM    R2,R14,SUB1_SAVE
>  BR  R14
>  DROP R11
> 
> Of course, there are always macros for the LARL/BALR and subroutine
> entry and exit so it looks like:
> 
>  XBAL SUB1
> 
> ...
> 
> SUB1 ENT
>  do something
>  LEAVE
> 
> The macros push the subroutine name
> into a macro array for later automatic save area generation.
> 
> I'm never clear on what happens when you exceed
> the limits of a hardware stack.
> 

Sure, now you have LARL. You can also preallocate a largeish storage area
as a stack to grab saveareas off, to avoid GETMAIN/FREEMAIN.

-- 
Pete

"Lee Gleason"  wrote in message news:TnZbD.45969$nX1.25571@fx11.iad...
>  You got all the way to Stage 5 of Field Service Support escalation!

>http://nemesis.lonestar.org/stories/stages.html

>  At my first job, we got that far twice.

  I just realized that the above link to the "Six Stages of Field Service 
Support" has gone dead (regrettably, due to Frank Durda passing away).

  Here is a link to it in the archives.

web.archive.org/web/20170825202933/http://nemesis.lonestar.org/stories/stages.html

--

Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net 

John Levine <jo...@taugh.com> writes:

> In article <pkpgkg$grv$1...@dont-email.me>,
> Dan Espen  <dan1...@gmail.com> wrote:
>>Not really that hard:
>>
>> LARL R11,SUB1   R11 <- subroutine address and base
>> BALR R14,R11   Go to subroutine
>
> LARL?  No 360 I ever used had that instruction.

Right, the macro for this originally did:

 L  R11,=A(SUB1)

But I guessed we were talking S/360 and it's descendants.

> Also, the standard calling sequence put the entry point in R15.
> Pedantically,

Yes, the code could use R15 but then R15 would have to be loaded
somewhere else or it would be sure to be destroyed before the subroutine
got very far.  Better to just use some safe register from the beginning.

-- 
Dan Espen

Peter Flass <peter...@yahoo.com> writes:

> Dan Espen <dan1...@gmail.com> wrote:
>> Peter Flass <peter...@yahoo.com> writes:
>> 
>>> Dan Espen <dan1...@gmail.com> wrote:
>>>> I've done huge amounts of assembly programming and the instructions
>>>> get the job done.  Issues with the base registers are easy to deal with
>>>> once you figure out that each subroutine should have it's own base
>>>> register, don't attempt to make all code addressible at once.
>>>> 
>>> 
>>> My copy of Pugh is packed, but I think this was the intention. 4K can be a
>>> bit small for a subroutine, but I think the designers expected programmers
>>> to divide their programs into smallish subroutines. I don't think I've
>>> written a lot of programs that needed multiple base registers. On the other
>>> hand it's more complicated than it needs to be to save a base register and
>>> load a new one - especially if you want to write reentrant code, where the
>>> recommended technique requires OS intervention to get a free the savearea.
>>> A hardware stack would have helped. and maybe one instruction to push a
>>> register and load it with the address of the next instruction.
>> 
>> Not really that hard:
>> 
>>  LARL R11,SUB1   R11 <- subroutine address and base
>>  BALR R14,R11   Go to subroutine
>> 
>> ...
>> 
>> SUB1 DS 0H
>>  USING R11,*
>>  STM   R2,R14,SUB1_SAVE
>> do something
>>  LM    R2,R14,SUB1_SAVE
>>  BR  R14
>>  DROP R11
>> 
>> Of course, there are always macros for the LARL/BALR and subroutine
>> entry and exit so it looks like:
>> 
>>  XBAL SUB1
>> 
>> ...
>> 
>> SUB1 ENT
>>  do something
>>  LEAVE
>> 
>> The macros push the subroutine name
>> into a macro array for later automatic save area generation.
>> 
>> I'm never clear on what happens when you exceed
>> the limits of a hardware stack.
>> 
>
> Sure, now you have LARL.

Not required, the actual macro I'm thinking of originally
used an ADCON for the subroutine address.

> You can also preallocate a largeish storage area
> as a stack to grab saveareas off, to avoid GETMAIN/FREEMAIN.

Yes, the actual macro set included:

 STACKBEG
 STACKEND

The STACKBEG macro looked at all the subroutine names stored in
an array and generated the save areas.

Another way to do this is to mark each subroutine with a depth:

SUB1 ENT DEPTH=2

Then all subroutines at calling depth 2 share the same save area.

So, a program needed 1 base register for it's code, (no matter how
much code), one or more base registers for the stack and one or more
base registers for constants.  This covered most cases pretty well.

-- 
Dan Espen

On Sun, 12 Aug 2018 16:51:56 -0500, "Lee Gleason"
<lee.g...@comcast.net> wrote:

>
>
>"Lee Gleason"  wrote in message news:TnZbD.45969$nX1.25571@fx11.iad...
>>  You got all the way to Stage 5 of Field Service Support escalation!
>
>>http://nemesis.lonestar.org/stories/stages.html
>
>>  At my first job, we got that far twice.
>
>  I just realized that the above link to the "Six Stages of Field Service 
>Support" has gone dead (regrettably, due to Frank Durda passing away).
>
>  Here is a link to it in the archives.
>
>web.archive.org/web/20170825202933/http://nemesis.lonestar.org/stories/stages.html

That was quite good.

I was never cut out for tech support.  My objective in going on a
service call was not to "follow procedures", it was to fix the damned
machine.  

I do remember one time getting a call from a consulting firm which had
a system installed nearby.  They had seen my name on the Microsoft
Partner list and asked if I was willing to go look at it.  I did.  I
had been there five minutes when the consulting firm calls with
Microsoft on the phone.  The next 8 hours were Hell.  I was trying to
work the problem without telling the Microsoft guy to STFU and let me
work.  Finally found the problem, it was some minor configuration
issue if I recall correctly that I could have found in ten minutes
without Microsoft yammering in my ear.

On Saturday, August 11, 2018 at 5:30:04 PM UTC-4, Adam Sampson wrote:
> There's nothing like a good debugging war story -- go on, then!

Over at St. Potato's College (that's a different story, told here: https://www.glaver.org/blog/?p=926 ), we evolved into being DG's largest XBASIC customer. They probably got the hint when they got a STR from me that said "XBASIC SYSGEN allows any 32 terminals to be controlled by that XBASIC instance, as long as they're the first 32. We have 96 and would like to use the other 64."

They fixed that one, and a followup regarding interactions with our in-house-developed F2 and F3 partitions (this was on RDOS, which only provided BG and FG - background and foreground). They pretty much asked "what the heck are you people doing over there?" and I replied that we were running 96 XBASIC terminals, 32 in each of FG, F2, and F3 and that we had an in-house system (written by yours truly) running in BG that allowed any of the 96 BASIC terminals to edit jobs in other languages (DG supplied FORTRAN IV and something vaguely Algol-66-like which eventually morphed into DG/L - kind of the DG equivalent of DEC's BLISS - a system implementation language). We got Pascal and (IIRC) COBOL from somewhere else. I built a batch job scheduler that ran sequential jobs in the background and returned them to the submitting user. It was possible to SYSGEN XBASIC with custom user-written assembly language code, invoked by "Call <digit>" in a BASIC program. So the users had the ability to see where in the queue they were, kill a queued or running job of theirs if they discovered a problem, or flush the job from either the slow- or high-speed lineprinter queue if they had an output runaway. The operator could also use any of those requests against any job - for students they could only request them against their own jobs. Bear in mind, this was running on an Eclipse S/200 ('181 ALUs, like a PDP-11/34 or 11/44) with 256Kb of memory. It did have a separate comm chassis that I'd installed, so the com ports were a single DMA peripheral, not a bunch of individial interrupt-per-port cards. We had a 6061 192MB system drive (closest DEC equivalent would be an RP06) and an 8MB fixed-head drive that was normally used as the paging device on the higher-end AOS/VS systems. That was the subject of a different STR - "paging disk not considered bootable for RDOS residence", which was also fixed by DG with a grumble.

But, as Alro Guthrie once famously said, "That's not what I came here to tell you about".

DG XBASIC used a bunch of clever tricks to service up to 32 terminals from what the CPU considered a single process. It was internally threaded, riddled with coroutines with undocumented dependencies, and so on.

One thread was responsible for parsing human-readable programs into the internal representation that the interpreter used. There were similar threads for the reverse:

LOAD - read internal representation from disk into program memory
ENTER - read human representation from disk into program memory
SAVE - write internal representation from program memory to disk
LIST - write human representation from program memory to terminal or lineprinter
STORE - write human representation from program memory to disk

The culprits here are ENTER and STORE. A user had developed a massive application (serious research on eye movements called saccades) and needed to analyze the data on the computer. As I recall, it was some 40,000 lines long on a system that only allowed line numbers up to 9999.

Based on my familiarity with the system, I said that if he constructed his program as a series of separate overlays, all using the same series of line numbers (for example, 5000 through 6990 by 10's) he could STORE out that overlay and then activate it in his main program by saying '1000 ENTER "some-overlay-name"' where 1000 was a line number in the base (non-overlayed) part of the program. Enter performed a merge of whatever was in memory at the line numbers contained in the new code, so any new code would replace the old code of the same line number. As long as there was rigid compliance to line numbering (always being increments of 10, etc.) this worked quite well, the researcher went away to do other researcher-y stuff, and the student he sent over to do the grun work of processing the data easily got the hang of the system.

The next semester, this had proven so popular that there were TWO students running the data analysis program. The minute the second one would start using the program, both programs would fail will all sorts of bizarre errors - doing a "LIST" would show not only pieces of other overlays, but strings of gibberish, including control characters, pieces of other address space, etc. Pretty much like what happens in the movie "The Fly", but more gruesome.

After a bunch of local analysis, I decided that the single thread that processed
ENTER statements was getting confused if more than one terminal thread requested an ENTER at the same time.

DG eventually agreed, sent back my STR with the source tapes, and said "you're welcome to fix it if you want to". I looked at the code, which was very tightly written, probably by a single person, and was pretty impenetrable.

I suggested the program be modified to write data to intermediary files and use CHAIN to launch the next piece (former overlay). It was a lot less efficient, as it was common to flip overlays back and forth for each line since the overhead was so low.

That department insisted we keep that S/200 in operation for many, many years after it went out of support, since the did not want to move their application to either PDP-11 RSTS/E or VAX/VMS. I think it hung around until 1987 or so before I could no longer maintain it and it was donated.

On Thu, 9 Aug 2018 15:31:31 -0500, Charles Richmond <nume...@aquaporin4.com>
wrote:
>On 8/9/2018 1:45 PM, Rich Alderson wrote:
>> Elliott Roper <nos...@yrl.co.uk> writes:
>> 
>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):
>> 
>>>> Bitsavers uploaded the system manual for the PDP 11/40.
>> 
>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_
>>>> manual.pdf
>> 
>>>> 358 pages, undated.
>> 
>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>> PDP-11?
>> 
>> Yes, many.
>> 
>
>*Not* that I disagree...  but which other computers do you find elegant???

The PDP-10, of course.

On Sat, 11 Aug 2018 15:23:07 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>In article <1173318279.555679658.757...@news.eternal-september.org>,
>Peter Flass  <peter...@yahoo.com> wrote:
>>Yes, I loved the -10 too, although I didn't program it extensively. I was
>>sorry when it was canceled, although I suspect it would have been difficult
>>to expand the architecture to larger memory sizes.
>
>We don't have to guess.  They did expand the addressing for the DEC-20
>and it was pretty ugly.  The extra address bits were called the
>section number, with some addressing being within the current section
>and some being global.  TOPS-20 supported it but I don't recall many
>programs using it.

It wasn't that ugly, IMO, but I never really tried to use it myself.

TOPS-20 itself used it, but without looking at my references (currently in
boxes) I cannot recall the exact details.  If memory serves, most or all monitor
code was in section zero; a couple of non-zero sections were used for data
and/or buffers.

1022 (database program) would have been an obvious candidate for using sections,
and I think it might have.  (I've cross-posted this to alt.sys.pdp10.)

I think that any reasonably coded programs of the day would have fit in section
zero, with non-zero sections used for data.  Given a good design one might not
have to actually move data in order to process it -- just change the memory map
tables with the appropriate system calls.

One thing on my todo list that I never tried was to see if the PMAP bug also
applied to SMAP.  (PMAP page A to page B; PMAP page B to page A.  Any reference
to either page causes the microcode to loop forever trying to resolve the
address.  When the front-end PDP-11 fails to get any response from the PDP-10
after a certain interval, it generates a "keep alive" halt and forces a reboot.)

I can't even remember how many bits in an extended address, so I'm not sure how
well it would work given today's memory sizes.  One must remember that PDP-10
addresses point to 36-bit words, not 8-bit bytes.

On Sun, 12 Aug 2018 14:51:48 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>In article <ft933kF...@mid.individual.net>,
>Bob Eager  <news...@eager.cx> wrote:
>>Especially when you find that JUMP and SKIP are no-ops.
>
>Anyone who thought that SKIP was a no-op wasn't paying attention.

It was if the AC field was zero.

Does JUMP set any flags?  I can't remember...


>I agree that it didn't skip.

On Sat, 11 Aug 2018 22:16:46 +0100, Adam Sampson <a...@offog.org> wrote:
>terry-...@glaver.org writes:
>
>> To be fair, I did give them an XBASIC STR that was fundamentally
>> unsolveable (ask if you want the details).
>
>There's nothing like a good debugging war story -- go on, then!
>
>I've been learning PDP-10 assembler lately (through playing with ITS);
>it's a really interesting architecture from the perspective of someone
>who grew up with 80s micros. The combination of regularity and multiple
>ways to do similar operations means there's a very satisfying
>puzzle-solving aspect to it...

One amusing pastime is to list *all* the different instructions that can be used
to zero an accumulator...

On 2018-08-13 09:56, Questor wrote:
> On Sat, 11 Aug 2018 15:23:07 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>> In article <1173318279.555679658.757...@news.eternal-september.org>,
>> Peter Flass  <peter...@yahoo.com> wrote:
>>> Yes, I loved the -10 too, although I didn't program it extensively. I was
>>> sorry when it was canceled, although I suspect it would have been difficult
>>> to expand the architecture to larger memory sizes.
>>
>> We don't have to guess.  They did expand the addressing for the DEC-20
>> and it was pretty ugly.  The extra address bits were called the
>> section number, with some addressing being within the current section
>> and some being global.  TOPS-20 supported it but I don't recall many
>> programs using it.
> 
> It wasn't that ugly, IMO, but I never really tried to use it myself.
> 
> TOPS-20 itself used it, but without looking at my references (currently in
> boxes) I cannot recall the exact details.  If memory serves, most or all monitor
> code was in section zero; a couple of non-zero sections were used for data
> and/or buffers.
> 
> 1022 (database program) would have been an obvious candidate for using sections,
> and I think it might have.  (I've cross-posted this to alt.sys.pdp10.)
> 
> I think that any reasonably coded programs of the day would have fit in section
> zero, with non-zero sections used for data.  Given a good design one might not
> have to actually move data in order to process it -- just change the memory map
> tables with the appropriate system calls.
> 
> One thing on my todo list that I never tried was to see if the PMAP bug also
> applied to SMAP.  (PMAP page A to page B; PMAP page B to page A.  Any reference
> to either page causes the microcode to loop forever trying to resolve the
> address.  When the front-end PDP-11 fails to get any response from the PDP-10
> after a certain interval, it generates a "keep alive" halt and forces a reboot.)
> 
> I can't even remember how many bits in an extended address, so I'm not sure how
> well it would work given today's memory sizes.  One must remember that PDP-10
> addresses point to 36-bit words, not 8-bit bytes.

The KL10 added 5 bits to addressing, giving you 32 sections, or 23 bit 
addresses. The architecture itself allowed up to 30 bits for addresses, 
giving you 12 bits for sections, or 4096 sections.

Which would have been a fairly large addressing space, but starting to 
be small by todays standards. (We're talking about roughly the same as a 
32-bit address in 8-bit byte addressable machines.)

And the change to the basic architecture is fairly unintrusive, if I 
remember right. In a "pointer", most of the left halfword is unused. You 
have the indirect bit, and not much else. The architecture grabbed 12 
bits there for the section, but said that a zero means your current 
section. Also, all direct addressing is always referring to the current 
section. So pretty much all existing programs would continue to run 
without changes. However, you could easily move data or routines to 
another section, and just call them there, and not much else needed 
changing. Just remember to get the correct section into pointers if you 
did start to spread out over several sections.

All with the caveat that I never did much PDP-10 programming myself 
either, and this is recollections from many years ago, when I last 
studied it.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Dan Espen <dan1...@gmail.com> wrote:
> John Levine <jo...@taugh.com> writes:
> 
>> In article <pkpgkg$grv$1...@dont-email.me>,
>> Dan Espen  <dan1...@gmail.com> wrote:
>>> Not really that hard:
>>> 
>>> LARL R11,SUB1   R11 <- subroutine address and base
>>> BALR R14,R11   Go to subroutine
>> 
>> LARL?  No 360 I ever used had that instruction.
> 
> Right, the macro for this originally did:
> 
>  L  R11,=A(SUB1)

But, LARL loads a PC-relative address, but your L generates an ADCON.

> 
> But I guessed we were talking S/360 and it's descendants.
> 
>> Also, the standard calling sequence put the entry point in R15.
>> Pedantically,
> 
> Yes, the code could use R15 but then R15 would have to be loaded
> somewhere else or it would be sure to be destroyed before the subroutine
> got very far.  Better to just use some safe register from the beginning.
> 

As long as you don't call anything that uses standard linkage conventions.


-- 
Pete

Quadibloc <jsa...@ecn.ab.ca> writes:
>On Saturday, August 11, 2018 at 9:23:08 AM UTC-6, John Levine wrote:
>> In article <1173318279.555679658.757...@news.eternal-september.org>,
>> Peter Flass  <peter...@yahoo.com> wrote:
>> >I was
>> >sorry when it was canceled, although I suspect it would have been difficult
>> >to expand the architecture to larger memory sizes.
>
>> We don't have to guess.  They did expand the addressing for the DEC-20
>> and it was pretty ugly.  The extra address bits were called the
>> section number, with some addressing being within the current section
>> and some being global.  TOPS-20 supported it but I don't recall many
>> programs using it.
>
>The Sigma 9 from Xerox/SDS also took an existing architecture with a full-length 
>address in the instruction, and modified it to use more memory than that address 
>could support.

So did the later generations of the Burroughs B-3500.   Originally,
it had a 6 BCD digit address in the instruction, and the high-order
digit contained the data type and indexing bits (for data, for code
only the indexing bits).  So direct data addresses could only address
100,000 digits; branches could reach 300,000.   Use of an index register
allowed access to the full 1,000,000 digits.

About 1980, work started to extended the architecture to allow a program
to access much more than the 1,000,000 digits by creating a segmentation
scheme and adding seven more base-limit registers (allowing direct access
to 8,000,000 digits via an index register base-selection digit).  The
VEN (Virtual Enter) instruction could either remain in the current
"environment" or could switch to a different environment by reloading
the base-limit registers from a page-table like structure managed by the
MCP; allowing effectively unlimited addressibility, and instructions
were provided to move data between environments.

100% backward compatable with programs compiled for the B-3500.

Peter Flass <peter...@yahoo.com> writes:

> Dan Espen <dan1...@gmail.com> wrote:
>> John Levine <jo...@taugh.com> writes:
>> 
>>> In article <pkpgkg$grv$1...@dont-email.me>,
>>> Dan Espen  <dan1...@gmail.com> wrote:
>>>> Not really that hard:
>>>> 
>>>> LARL R11,SUB1   R11 <- subroutine address and base
>>>> BALR R14,R11   Go to subroutine
>>> 
>>> LARL?  No 360 I ever used had that instruction.
>> 
>> Right, the macro for this originally did:
>> 
>>  L  R11,=A(SUB1)
>
> But, LARL loads a PC-relative address, but your L generates an ADCON.

Both instructions put the address of the subroutine into the register.

On older machines a load of an adcon is used because "LA" isn't
going to work if the subroutine is more than 4K away from the calling routine.

On newer machines LARL is preferred because ADCONS take storage
and add to load time.

>> But I guessed we were talking S/360 and it's descendants.
>> 
>>> Also, the standard calling sequence put the entry point in R15.
>>> Pedantically,
>> 
>> Yes, the code could use R15 but then R15 would have to be loaded
>> somewhere else or it would be sure to be destroyed before the subroutine
>> got very far.  Better to just use some safe register from the beginning.
>
> As long as you don't call anything that uses standard linkage conventions.

Of course.

One could use standard linkage for subroutine calls, but it's just
not efficient.  I don't think any IBM compiler does so.

-- 
Dan Espen

In article <pkrloc$ttj$1...@Iltempo.Update.UU.SE>,
Johnny Billquist  <b...@softjar.se> wrote:
>The KL10 added 5 bits to addressing, giving you 32 sections, or 23 bit 
>addresses. The architecture itself allowed up to 30 bits for addresses, 
>giving you 12 bits for sections, or 4096 sections.
>
>Which would have been a fairly large addressing space, but starting to 
>be small by todays standards. (We're talking about roughly the same as a 
>32-bit address in 8-bit byte addressable machines.)

The 23 bit address would have been small but the 32 bits would take
you to 4GB which would have been good for at least another decade after
the -10 died in 1983.

>And the change to the basic architecture is fairly unintrusive, if I 
>remember right. In a "pointer", most of the left halfword is unused. You 
>have the indirect bit, and not much else. The architecture grabbed 12 
>bits there for the section, but said that a zero means your current 
>section. Also, all direct addressing is always referring to the current 
>section. So pretty much all existing programs would continue to run 
>without changes. However, you could easily move data or routines to 
>another section, and just call them there, and not much else needed 
>changing. Just remember to get the correct section into pointers if you 
>did start to spread out over several sections.

Well, sort of.  There's no need to guess, the reference manual is in
bitsavers.  Programs running in section 0 had 18 bit addressing.
Programs running in any other section had mixed 18 or long adddesses
depending on the instruction and in a few stack instructions, on the
contents of the high bits of the pointer.  It was a lot like near and
far addresses on a 286 which were a pain to keep track of.

There was a lot of PDP-10 code that depended on the fact that you
could store addresses in the high or low half of a word, and use
halfword instructions to manipulate them.  With longer addresses you
had to change your data structures which meant you had to change your
code, so either you did what someone suggested in a previous message,
keep your program in section 1 and treat everything else as a data
space, or you had to rewrite your code, at which point you might as
well rewrite it for the nice flat address space of a Vax.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <5b7139a6...@news.dslextreme.com>,
Questor <usenet@only.tnx> wrote:
>>>Especially when you find that JUMP and SKIP are no-ops.
>>
>>Anyone who thought that SKIP was a no-op wasn't paying attention.
>
>It was if the AC field was zero.
>
>Does JUMP set any flags?  I can't remember...

No, it's a true no-op.  So is CAI.



-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <pks7k7$jf0$1...@dont-email.me>,
Dan Espen  <dan1...@gmail.com> wrote:
>>>>> LARL R11,SUB1   R11 <- subroutine address and base
>>>>> BALR R14,R11   Go to subroutine
>>>> 
>>>> LARL?  No 360 I ever used had that instruction.
>>> 
>>> Right, the macro for this originally did:
>>> 
>>>  L  R11,=A(SUB1)
>>
>> But, LARL loads a PC-relative address, but your L generates an ADCON.

Right, and LARL is position independent while adcons are not.

If you're on a machine that has LARL, you can skip the base register
for your code, use relative addressing in all your code and just call
it with BRAS.

>> As long as you don't call anything that uses standard linkage conventions.
>
>Of course.
>
>One could use standard linkage for subroutine calls, but it's just
>not efficient.  I don't think any IBM compiler does so.

I can assure you that Fortran G, H, and X and PL/I F and X certainly
did.  That's why you could call a subroutine written in one language
from another.

On Linux systems that use ELF objects there's another calling sequence
that handles the PLT and GOT needed for position independent code.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <jo...@taugh.com> writes:
> I can assure you that Fortran G, H, and X and PL/I F and X certainly
> did.  That's why you could call a subroutine written in one language
> from another.
>
> On Linux systems that use ELF objects there's another calling sequence
> that handles the PLT and GOT needed for position independent code.

I've periodically complained about difficulty in doing position
independent code for CMS ... because CMS leveraged OS/360 compilers and
lots of applications ... by providing OS/360 simulation ... we use to
joke that the 64kbytes of OS/360 system services simulation was much
more efficient than the MVS 8mbytes of OS/360 system services
simulation.

While TSS/360 had lots of significant performance problems and
inefficiencies ... it did at least support position independent
paradigm.
http://www.bitsavers.org/pdf/ibm/360/tss/

past/archived posts on problems doing position independent code in CMS
(first with CP67/CMS and later with VM370/CMS)
http://www.garlic.com/~lynn/submain.html#adcon

-- 
virtualization experience starting Jan1968, online at home since Mar1970

John Levine <jo...@taugh.com> writes:

> In article
> <1173318279.555679658.757...@news.eternal-september.org>,
> Peter Flass <peter...@yahoo.com> wrote:

>> Yes, I loved the -10 too, although I didn't program it extensively. I was
>> sorry when it was canceled, although I suspect it would have been difficult
>> to expand the architecture to larger memory sizes.

> We don't have to guess.  They did expand the addressing for the DEC-20
> and it was pretty ugly.  The extra address bits were called the
> section number, with some addressing being within the current section
> and some being global.  TOPS-20 supported it but I don't recall many
> programs using it.

Tops-10 7.xx as well as TOPS-20 4.x onwards used extended addressing.  The
GALAXY subsystem (unrelated to VAX clustering) also adopted extended addressing
so that's pretty much all of the operating system.

Fortran v11 (and possibly v10 and v7, I don't remember for certain) used
extended addressing.

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

On Mon, 13 Aug 2018 17:20:18 +0000, John Levine wrote:

> In article <5b7139a6...@news.dslextreme.com>,
> Questor <usenet@only.tnx> wrote:
>>>>Especially when you find that JUMP and SKIP are no-ops.
>>>
>>>Anyone who thought that SKIP was a no-op wasn't paying attention.
>>
>>It was if the AC field was zero.
>>
>>Does JUMP set any flags?  I can't remember...
> 
> No, it's a true no-op.  So is CAI.

On the KA10, CAIA was supposed to be the fastest skip. I believe that 
JRST 0 was also supposed to be the fastest jump!

On the KI10, TRNA was the fastest skip. I don't remember any more.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

On 2018-08-12, Lee Gleason <lee.g...@comcast.net> wrote:

> "Lee Gleason"  wrote in message news:TnZbD.45969$nX1.25571@fx11.iad...
>
>>  You got all the way to Stage 5 of Field Service Support escalation!
>
>> http://nemesis.lonestar.org/stories/stages.html
>
>>  At my first job, we got that far twice.
>
>   I just realized that the above link to the "Six Stages of Field Service 
> Support" has gone dead (regrettably, due to Frank Durda passing away).
>
>   Here is a link to it in the archives.
>
> web.archive.org/web/20170825202933/http://nemesis.lonestar.org/stories/stages.html

Thank you for the repaired link.  I'm saving that one.

After one of our own Stage 5 escalations, which the guru fixed at about
quitting time, we sat in an unused office for a while just shooting the
bull with the guru.  While carrying on a conversation with us, the guru
was continually scrambling and unscrambling a Rubik's cube.  That's the
kind of mind we're dealing with here.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On 2018-08-12, Dan Espen <dan1...@gmail.com> wrote:

> I'm never clear on what happens when you exceed
> the limits of a hardware stack.

That depends on whether the hardware has a stack limit register
and can trap the stack overflow.  Otherwise, very bad things happen.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On 2018-08-13, Questor <usenet@only.tnx> wrote:

> One amusing pastime is to list *all* the different instructions that can
> be used to zero an accumulator...

If your program counter, instruction register, and data registers are in
low-order memory, there are a lot of fun ways to code a one-instruction
loop.  Decrementing the program counter by the length of the instruction
is just the beginning.  Or you can decrement the program counter by twice
the length of the instruction and make your program run backwards.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On 2018-08-13 21:48, Rich Alderson wrote:
> John Levine <jo...@taugh.com> writes:
> 
>> In article <0897e059-0b26-4334...@googlegroups.com>,
>> Quadibloc  <jsa...@ecn.ab.ca> wrote:
> 
>>> I think it was ugly too; but I suppose that it could still be said that if
>>> the memory expansion method actually used was a kludge, that doesn't prove
>>> th at something better might not be possible.
> 
>> The people who did it were pretty smart.  An obvious alternative would be a
>> mode bit, like 16 vs 32 bit segments on the 386, and different instruction
>> formats, but if it's not backward compatible with 18 bit code, you might as
>> well switch to a Vax, which is what everyone did.
> 
> Speaking from personal experience here, no, that's not what they did.
> 
> Most PDP-10 customers (where that's a cover term for the entire line) were so
> pissed at Digital for the Jupiter cancellation that when they moved off of the
> 36-bit architecture, they went with anything available which wasn't a Digital
> product.
> 
> I can say this as the former sales support manager for the manufacturer of an
> extended clone of the KL-10 processor in the DECSYSTEM-20.  When we brought the
> XKL Toad-1 System to market in 1996, the VP of sales and I did a phone survey
> of every potential customer he had ever spoken to, and learned just how many
> systems had been decommissioned in the preceding 12 months in favor of one or
> another high-end Unix offering or IBM system.  Almost none of them had gone to
> VMS or OSF/1 on Alpha (by then, Digital's only hardware offering).
> 
> (NB:  Translating titles above, I was the entire customer/sales support
>   organization at the time, and he was the entire sales force.  We expected to
>   grow.)

While I think you are right, in general I think the reflection and 
reaction wasn't hitting the VAX itself that much. But VMS.
I think that DECs attempt at pushing the PDP-10 customers to switch to 
VMS was a total failure, and where people just told DEC to piss off.
I don't know if some might have gone with VAXen, but they most certainly 
did not go with VMS. That was a group of customers who pretty much 
universally went to Unix.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On 2018-08-14 12:46, terry-...@glaver.org wrote:
> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
>> Yes. Although, the 8600 didn't miss the performance goals, as far as I
>> can remember, but it was *way* late. But as far as I can remember, the
>> goal was 4x 11/780, and that is what they achieved.
> 
> It shipped with some internal optimizations disabled, some of which were fixed by the regular shipment of microcode updates. I think the serial sense bus (that gathered data from each pin of each macrocell array) and wrote it to a state dump file on the console RL02 was more a statement about how nervous they were about the machine's reliability than the declared reason of letting them know exactly which board to bring when a system failed.

The dumps are pretty impressive. I guess they were also good for 
troubleshooting and analyzing if things went wrong. But I must say that 
the 86x0 machines were (are) impressively reliable. Lots of redundancy 
meaning they will normally keep running even when some stuff is broken.

> The only difference between an up-to-rev-level 8600 and an 8650 are the clock and mbox cache control boards. Every other board in the system is the same, if up to an acceptable rev level. I think that shows pretty clearly that the 8600 didn't meet its internal design goal. The marketing material may have said "4 times a 780" but that came along at a later date. The planned (and dropped) 8670 would have been a more major board swap (think 11/780 to 11/785 upgrade). But by then the writing on the wall was quite clear that "complete" VAX systems (w/ PDP11 mode, full instruction set support in microcode, etc,) were on the way out.

Yeah. It was the dawn of the VLSI VAXen. Suddenly production exploded 
and new VAX models were being introduced every few weeks. Reworking the 
86x0 at that point was probably very obviously not attractive anymore.

> An undocumented CE mode let you change the fundamental clock in the 86x0, presumably for margin tests when running diagnostics. But some customers found they could run jobs 20% faster.

Not undocumented. If you typed HELP on the console, you'd find all about 
how to play with it.
I can post the HELP information, if anyone is curious.

>> 8670 don't ring any bells in my head right now, so I can't comment. The
>> 9000 was done by the same group though, yes. And while it was fast, and
>> I don't know if it was late or not, it was certainly way too expensive,
> 
> It used to be fun to read the listing fiche (or the equivalent STARLET library) to find out the names of un-announced products. Unfortunately Charlie Matco exposing these caused DEC to change them to filler codes.

:-)

> The 9000 family was DEC acquiring every company they could find that had something remotely useful, in the theory that DEC could pull off a major architectural triumph (pun semi-intended) the way IBM did with their new packaging on 3090-class CPUs. DEC never did seem to understand that they weren't IBM.

True. And this was at the time when DEC really tried to become IBM.

>> and the NVAX came out not long after with the same performance on a
>> chip, making the 9000 immediately obsolete.
> 
> And making Ken's head explode, once he finally understood.

Yes. :-)

>> My brain keeps saying "LCG", for Large systems computer group, as the
>> ones being responsible for those machines, along with PDP-10s. Not sure
>> if I'm misremembering something, though.
> 
> LSG (Large Systems Group), I think.

Possible. Maybe someone around here was involved and can tell for sure.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On 2018-08-15, Peter Flass <peter...@yahoo.com> wrote:
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> terry-...@glaver.org writes:
>> 
>>> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
>> 
>>>> My brain keeps saying "LCG", for Large systems computer group, as the
>>>> ones being responsible for those machines, along with PDP-10s. Not sure
>>>> if I'm misremembering something, though.
>> 
>>> LSG (Large Systems Group), I think.
>> 
>> No, Johnny is correct:  LCG = "Large Computer Group" was the 10/20/Venus crowd.
>> 
>
> Where is Barb when you need her?
>

Still at the Tulip festival?


-- 
Ma...@ireland.com
Will Rant For Food

ma...@mail.com writes:
>On 2018-08-15, Peter Flass <peter...@yahoo.com> wrote:
>> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>>> terry-...@glaver.org writes:
>>> 
>>>> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
>>> 
>>>>> My brain keeps saying "LCG", for Large systems computer group, as the
>>>>> ones being responsible for those machines, along with PDP-10s. Not sure
>>>>> if I'm misremembering something, though.
>>> 
>>>> LSG (Large Systems Group), I think.
>>> 
>>> No, Johnny is correct:  LCG = "Large Computer Group" was the 10/20/Venus crowd.
>>> 
>>
>> Where is Barb when you need her?
>>
>
>Still at the Tulip festival?
>

Listening to the Beach Boys version of the song  _Barbara-Ann_?

On Saturday, August 11, 2018 at 10:25:17 AM UTC-4, Dan Espen wrote:

> 1401 was my first also.  One could do quite a bit in a small amount of
> storage.  The A and B registers would tell you about the data the
> previous instruction processed.  (Usually where the word mark was.)
> Word marks were like the trailing null with C strings without the bother.
> 
> A shame none of that carried over to the S/360.
> We could have had a 7 bit character with one bit reserved for the word mark.

Lots of 1401 customers simply continued with that under emulation
with their S/360, or even subsequent models for decades.

Some in IBM were opposed to S/360 and wanted to build on 1401.
Haanstra built a "super" 1401 using SLT chips.  IBM mgmt. was
annoyed by that.

Ironically, despite IBM's big hopes that S/360 would be a universal
machine for all customers, even the smallest models were too
expensive for low-end users.  IBM ended up introducing the low
cost 1130 and System/3, both were very popular.

Maybe making a cheap 1401 wouldn't have been a bad idea.

I wonder how many S/3 users programmed it in Assembler.  The
manual is out on bisavers.  FWIW, almost every S/3 and et al 
shop I knew of used RPG-n.  

Anyone ever use assembler on a S/3 et al machine?






> 
> > The first I fell in love with was the IBM System/360, thanks to a high school
> > graduation gift from a sweetheart, Germain's _Programming the IBM 360_.  One of
> > these days I'm going to put his simulator on Hercules and go through the
> > exercises just for giggles.
> 
> Likewise, my next system was S/360 and I accumulated extensive
> experience with the machine.  My first impression was that the machine
> was over-complicated, on purpose.  The lack of sector addressing on
> the disks is my best example.  After using disks for years on a 1440,
> disks became more complicated than I thought they should be.
> 3270s are another example.  A simple thing like screen addressing
> couldn't be done with row/column numbers in bytes?
> 
> The 24 bit addressing was more a failure in the programming department
> than in hardware design.  Why any programmer would attempt to use
> the high order byte for data instead of just assuming it would be
> part of the address some day is a mystery.  IBM stepped in it big
> putting a 3 byte address right in the DCB.  A DCB without a version
> number or other reliable marker.  Still a problem to this day,
> 
> I've done huge amounts of assembly programming and the instructions
> get the job done.  Issues with the base registers are easy to deal with
> once you figure out that each subroutine should have it's own base
> register, don't attempt to make all code addressible at once.
> 
> -- 
> Dan Espen

On Wed, 15 Aug 2018 07:09:42 -0400, Peter Flass <peter...@yahoo.com> wrote:
>Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> terry-...@glaver.org writes:
>> 
>>> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
>> 
>>>> My brain keeps saying "LCG", for Large systems computer group, as the
>>>> ones being responsible for those machines, along with PDP-10s. Not sure
>>>> if I'm misremembering something, though.
>> 
>>> LSG (Large Systems Group), I think.
>> 
>> No, Johnny is correct:  LCG = "Large Computer Group" was the 10/20/Venus crowd.
>
>Where is Barb when you need her?

Don't need her.  Rich and Johnny are correct; it was the Large Computer Group.

dOn 14 Aug 2018 02:26:22 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>On 2018-08-13, Questor <usenet@only.tnx> wrote:
>
>> One amusing pastime is to list *all* the different instructions that can
>> be used to zero an accumulator...
>
>If your program counter, instruction register, and data registers are in
>low-order memory, there are a lot of fun ways to code a one-instruction
>loop.  Decrementing the program counter by the length of the instruction
>is just the beginning.  Or you can decrement the program counter by twice
>the length of the instruction and make your program run backwards.

Most of the ways to zero an accumulator on the PDP-10 aren't loops, although
there are a couple.  Depending the contents of the register, they may take a
while.  (grin)

The PDP-10 PC isn't stored in a general purpose register.  However, its sixteen
accumulators *are* mapped to the first sixteen memory locations, thus specific
register-to-register instructions aren't needed.  This flexibility, coupled with
the orthogonal instruction set, results in more than two dozen instructions
that will zero a register.

On 14 Aug 2018 02:26:21 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>On 2018-08-12, Dan Espen <dan1...@gmail.com> wrote:
>
>> I'm never clear on what happens when you exceed
>> the limits of a hardware stack.
>
>That depends on whether the hardware has a stack limit register
>and can trap the stack overflow.  Otherwise, very bad things happen.

A PDP-10 stack pointer has the stack address in the right halfword and the
negative stack count in the left halfword.  Every time something is pushed on
the stack, one is added to each halfword.  When the left halfword is zero, the
stack is full.  Detecting stack overflow is easy and done in hardware.

On 8/15/2018 12:04 PM, Scott Lurndal wrote:
> ma...@mail.com writes:
>> On 2018-08-15, Peter Flass <peter...@yahoo.com> wrote:
>>> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>>>> terry-...@glaver.org writes:
>>>>
>>>>> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
>>>>
>>>>>> My brain keeps saying "LCG", for Large systems computer group, as the
>>>>>> ones being responsible for those machines, along with PDP-10s. Not sure
>>>>>> if I'm misremembering something, though.
>>>>
>>>>> LSG (Large Systems Group), I think.
>>>>
>>>> No, Johnny is correct:  LCG = "Large Computer Group" was the 10/20/Venus crowd.
>>>>
>>>
>>> Where is Barb when you need her?
>>>
>>
>> Still at the Tulip festival?
>>
> 
> Listening to the Beach Boys version of the song  _Barbara-Ann_?
> 

She;s q\away ... eating her curds and Hui ... zinga!

-- 
numerist at aquaporin4 dot com

On Wednesday, August 15, 2018 at 1:39:08 PM UTC-6, han...@bbs.cpcn.com wrote:

> Ironically, despite IBM's big hopes that S/360 would be a universal
> machine for all customers, even the smallest models were too
> expensive for low-end users.  IBM ended up introducing the low
> cost 1130 and System/3, both were very popular.

> Maybe making a cheap 1401 wouldn't have been a bad idea.

And don't forget that the 360/20 wasn't compatible either.

Yes, it seems like Haanstra was right. But understandably, upper management did 
not want to compromise or distract from its vision... especially when System/360 
was a "you bet your company" effort. An SLT 1401 would have made many in IBM's 
sales force happy, which was what motivated Haanstra, but IBM as a whole needed 
to do everything in its power to maximize System/360 uptake.

John Savard

In article <f4077026-2b80-47e0...@googlegroups.com>,
Quadibloc  <jsa...@ecn.ab.ca> wrote:
>> Maybe making a cheap 1401 wouldn't have been a bad idea.
>
>And don't forget that the 360/20 wasn't compatible either.

The instruction set was different (mostly upward compatible with a
real 360 which as far as I can tell, never mattered) but most of the
peripherals were the same.

The 2560 MFCM card read/punch/interpret/sort/crumple device and the
internal modems were unique to the /20 but the 1403 printer, 2415 tape,
and everything else were regular 360 devices.  The 2311 disk was the
same physical drive and pack, but the disks used fixed sectors so you
couldn't read or write them on anything but another /20.



-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <jo...@taugh.com> wrote:
> In article <f4077026-2b80-47e0...@googlegroups.com>,
> Quadibloc  <jsa...@ecn.ab.ca> wrote:
>>> Maybe making a cheap 1401 wouldn't have been a bad idea.
>> 
>> And don't forget that the 360/20 wasn't compatible either.
> 
> The instruction set was different (mostly upward compatible with a
> real 360 which as far as I can tell, never mattered) but most of the
> peripherals were the same.
> 
> The 2560 MFCM card read/punch/interpret/sort/crumple device and the
> internal modems were unique to the /20 but the 1403 printer, 2415 tape,
> and everything else were regular 360 devices.  The 2311 disk was the
> same physical drive and pack, but the disks used fixed sectors so you
> couldn't read or write them on anything but another /20.
> 

True? I thought you could read, but not write them, because the sectors
looked like CKD blocks, but maybe I'm thinking of another system.

-- 
Pete

In article <1333283745.556223976.095...@news.eternal-september.org>,
Peter Flass  <peter...@yahoo.com> wrote:
>> and everything else were regular 360 devices.  The 2311 disk was the
>> same physical drive and pack, but the disks used fixed sectors so you
>> couldn't read or write them on anything but another /20.

>True? I thought you could read, but not write them, because the sectors
>looked like CKD blocks, but maybe I'm thinking of another system.

The manual says not but I never had one to try.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, August 17, 2018 at 2:36:15 PM UTC-4, John Levine wrote:
> The 2560 MFCM card read/punch/interpret/sort/crumple device and the
> internal modems were unique to the /20 but the 1403 printer, 2415 tape,
> and everything else were regular 360 devices.

The 2560 Mother-Friendly Card Mangler (a piece of hardware known for having 2 input hoppers, 5 output hoppers and a few U-turns and flip-overs in between, all operating in a non-deterministic manner*) managed to make life miserable for people well into the 370 era. I had the misfortune of having one on a 370/125 (the same 125 that MAI cut a 4" square hole into to run a bazillion wires through for their Brand X add-on memory). I was actually there when the "engineer" took a Sawzall to the chassis. Anyway, the 3125 CPU's Integrated Mumble Adapter supported the 2560.

* As an example of the kind of fun you can have, which input hopper fed the read station and which one fed the punch station depended on what partition your job landed in under DOS/VS POWER. As you can imagine, in an academic environment, merriment ensued as students punched their output on other student job decks innocently waiting in the (alleged) read hopper.

<terry-...@glaver.org> wrote:
> On Friday, August 17, 2018 at 2:36:15 PM UTC-4, John Levine wrote:
>> The 2560 MFCM card read/punch/interpret/sort/crumple device and the
>> internal modems were unique to the /20 but the 1403 printer, 2415 tape,
>> and everything else were regular 360 devices.
> 
> The 2560 Mother-Friendly Card Mangler (a piece of hardware known for
> having 2 input hoppers, 5 output hoppers and a few U-turns and flip-overs
> in between, all operating in a non-deterministic manner*) managed to make
> life miserable for people well into the 370 era. I had the misfortune of
> having one on a 370/125 (the same 125 that MAI cut a 4" square hole into
> to run a bazillion wires through for their Brand X add-on memory). I was
> actually there when the "engineer" took a Sawzall to the chassis. Anyway,
> the 3125 CPU's Integrated Mumble Adapter supported the 2560.
> 
> * As an example of the kind of fun you can have, which input hopper fed
> the read station and which one fed the punch station depended on what
> partition your job landed in under DOS/VS POWER. As you can imagine, in
> an academic environment, merriment ensued as students punched their
> output on other student job decks innocently waiting in the (alleged) read hopper.
> 

Those kinds of card devices and spoolers don't play well  together. That's
probably why only the low-end models of 360 and 370 could attach them. I
don't believe POWER or HASP supported the 2540 punch-feed-read feature
either. You could stacker-select the output using carriage control.

-- 
Pete