| changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372141 is a reply to message #372056] |
Mon, 13 August 2018 15:48   |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <0897e059-0b26-4334-82ff-5c0b2253a89e@googlegroups.com>,
> Quadibloc <jsavard@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.)
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372145 is a reply to message #372132] |
Mon, 13 August 2018 17:23 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <5b71ce88.4681852@news.dslextreme.com> you write:
> Your so-called "categories" are arbitrary and mostly meaningless. Even before
> the advent of the 360, they were always "general purpose" computers. Meaning
> they could be used for any application, given the proper programming. The
> salient differences were in CPU speed, storage capacity, and data transfer
> rates. ...
Yes and no. The architecture of the binary word addressed 704x/709x
scientific machines was rather different from the decimal word 7070 or
the character addressed 705/7080. Sure, they were all Turing
complete, but the 7080 was bad at floating point arithmetic and the
7090 was bad at moving character strings around.
We all think it's obvious to have byte/word addressing where the word
addresses are byte addresses with the low bits zero, but it wasn't
obvious at all before IBM invented it for the 360. Once they had a
memory architecture that could work either way, building the
instruction set wasn't so hard.
> The big advantage of having a line of computers with a
> single architecture would be to ease moving from one machine to another that was
> faster and/or bigger. It also helped IBM, assuming they could consolidate their
> OS and system software development and support.
That too, although BOS, TOS, DOS, OS/PCP, OS/MFT, OS/MVT, CP/CMS, TSS,
and PS44 suggest that consolidating the system software didn't work
out so well.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: PDP-10, was PDP 11/40 system manual [message #372146 is a reply to message #372130] |
Mon, 13 August 2018 18:26 |
|
|
Originally posted by: Bob Eager
On Mon, 13 Aug 2018 17:20:18 +0000, John Levine wrote:
> In article <5b7139a6.12106368@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
|
|
|
|
| Re: PDP 11/40 system manual [message #372163 is a reply to message #371981] |
Mon, 13 August 2018 21:38 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2018-08-10, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> On Thursday, August 9, 2018 at 5:36:25 PM UTC-4, Peter Flass wrote:
>
>> Charles Richmond <numerist@aquaporin4.com> wrote:
>>
>>> *Not* that I disagree... but which other computers do you find elegant???
>> System/360.
>
> +1
+0.9 - I had to knock off a tenth because they went and used BXH and BXLE
instead of BXHE and BXL, which IMHO would have made a lot more sense.
The other machine that stands out in my mind is the PDP-11. I once
hand-disassembled the Dungeon machine code and was stunned by its
elegance. Making R7 the program counter and R6 the stack pointer,
plus predecrement and postincrement, made it possible to do all sorts
of nifty program control stuff with what at first looked like ordinary
data manipulation instructions. The Dungeon binary was threaded code
implemented in hardware.
--
/~\ 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
|
|
|
|
|
|
|
|
| Re: PDP 11/40 system manual [message #372166 is a reply to message #372100] |
Mon, 13 August 2018 22:26 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: PDP 11/40 system manual [message #372167 is a reply to message #371874] |
Mon, 13 August 2018 22:26 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2018-08-12, Huge <Huge@nowhere.much.invalid> wrote:
> On 2018-08-11, Bob Eager <news0073@eager.cx> wrote:
>
>> On Sat, 11 Aug 2018 09:51:18 +0000, Huge wrote:
>>
>>> On 2018-08-10, Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
>
> [39 lines snipped]
>
>>>> There will be a talk on ICL 1900 Series resurrection next month:
>>>>
>>>> Title: ICL 1900 Software Recovery Speaker: Bill Gallagher, Delwyn
>>>> Holroyd & Brian Spoor Date: Thursday 20th September 2018 Time: 14:30
>>>> Location: BCS, 5 Southampton St, London WC2E 7HA
>
> SFPBA. Can't go. Why is it that events on my otherwise sparse calender
> tend to cluster together?
I once heard a saying: "Time is nature's way of keeping everything from
happening at once." Too bad it's totally wrong.
> I learned RPG2 [gag, spit, cough] for a project at Associated Televison
> to migrate their payroll from a 1900 Autocoder system to a 2903 RPG2
> [nausea] one. I went on a 2 week course at ICL to learn RPG2 [Ghod, I
> think I'm actually going to vomit] for that.
I learned RPG2 at the beginning of my career. My attitude was a bit
more conciliatory: I found it pretty good at doing what it wasn intended
to do, i.e. generate report programs (although that 1P indicator nonsense
obviously came from someone who never learned how to properly handle page
overflows).
The one that made me gag was RPG3. That's when IBM forgot what RPG
stood for and started writing screen-based interactive programs with it.
--
/~\ 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
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372174 is a reply to message #372141] |
Mon, 13 August 2018 23:47 |
|
|
Originally posted by: terry-groups
On Monday, August 13, 2018 at 3:48:10 PM UTC-4, Rich Alderson wrote:
> 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 remember talking to a fellow system administrator at another university who said they were going to an entirely Unix-based environment. When I asked why, he replied "We will have a large choice of which vendor we want to be screwed by".
OTOH, if Jupiter had delivered, my understanding (from the far outside) is that it would have been rather late, unacceptably slow, and extremely non-price-competitive.
Wasn't Jupiter from the (approximately) same part of DEC that produced the VAX 86x0 (missed its performance goals, shipped late) and 8650 (fixing the few remaining problems that cause the 8600 to not operate at the design speed)? And the 8670, which should have been the "mid-life kicker" upgrade for the 8600, assuming it shipped at the design speed? And the same (approximate) group that brought us the VAX 9000 family (repeat mantra of late, slow, expensive)?
It would seem in retrospect that the best thing to do would be to give the Jupiter group some sort of award and stick them in another building where they couldn't do any harm, and then make a deal with one of the many non-DEC vendors that already had fast systems. I know the second part (make a deal with a non-DEC vendor) got at least to the discussion phase, as the meeting minutes are over on Bitsavers.
|
|
|
|
| Re: PDP 11/40 system manual [message #372176 is a reply to message #372163] |
Tue, 14 August 2018 05:08 |
|
|
Originally posted by: Johnny Billquist
On 2018-08-14 03:38, Charlie Gibbs wrote:
> The other machine that stands out in my mind is the PDP-11. I once
> hand-disassembled the Dungeon machine code and was stunned by its
> elegance. Making R7 the program counter and R6 the stack pointer,
> plus predecrement and postincrement, made it possible to do all sorts
> of nifty program control stuff with what at first looked like ordinary
> data manipulation instructions. The Dungeon binary was threaded code
> implemented in hardware.
You do know that Dungeon is written in FORTRAN? So you were
disassembling something produced by a compiler.
That said, as a reflection on all other comments on PDP-11 and other
machines around, I also happen to think that the basic PDP-11
instruction set is extremely nice. And yes, having the PC and SP just
being general registers do add to the elegance. (The VAX lost a bit of
that, since even though the PC was a general register, there are some
restrictions surrounding it, compared to other general registers.)
Yes, the PDP-10 is also a very nice machine, with some parts very
beautifully done.
The PDP-10 and PDP-11 are designed very differently in some ways, but
they are both very orthogonal. However, the PDP-11 is also very
symmetric, which the PDP-10 isn't. So depending on what tickles you the
most, I can certainly see either the PDP-10 or PDP-11 coming out on top.
The VAX, for all it's niftyness just went a little too far and lost some
of the elegance of the PDP-11.
And I'm not at all surprised that Rich Alderson would place the PDP-10
first.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
|
|
|
|
| Re: our friend the VAX, was PDP 11/40 system manual [message #372177 is a reply to message #372129] |
Tue, 14 August 2018 05:17 |
|
|
Originally posted by: Johnny Billquist
On 2018-08-13 19:07, John Levine wrote:
> In article <44627835.555851238.710215.peter_flass-yahoo.com@news.eternal-september.org>,
> Peter Flass <peter_flass@yahoo.com> wrote:
>>>> And the epitome of the CISC processor, the VAX-11.
>>>
>>> Sixteen addressing modes, single instructions to calculate CRCs and polynomials,
>>> string translation instructions... the VAX had just about everything except an
>>> opcode for "phase of the moon." Too many bells and whistles to be considered
>>> elegant, IMO.
>
> It suffered from a surprising degree of technical myopia. The VAX was
> designed to be implemented in serial microcode, and was quite painful
> to overlap or pipline. The instruction format was an opcode and a series
> of variable length operand descriptors which had to be decoded in order since
> one decriptor could modify the register used in a subsequent one, e.g.
>
> ADDW2 (R3)+,(R3)
Decoding is not the problem, and can be done without anything blocking
anything else.
Evaluation is where you get into "problems", as there can be
interdependencies. But that has no relevance for the decoding as such.
> It can't fetch the second operand until it's decoded the first one,
> since the first one modifies R3. There were also a lot of absurdly
> complex instructions like evaluate polynomial which would have made
> a lot more sense as subroutines, at least if they had a lighter
> weight subroutine call instruction.
The VAX do have more light weight subroutine calls than the generic
CALLS/CALLG. I don't know why people never seem to know this. There is
the JSB/RSB pair, which is just the simple push the return address and
jump and nothing more opcodes (and the return is obviously just a pop
the return address).
> I gather the later Vaxen did complex pipelines with interlocks but it
> was a lot of effort to solve a problem that they needn't have created
> in the first place. Compare it to the 360/370 which is carefully
> designed so that as soon as you've looked at the opcode you can
> evaluate all of the operands in parallel.
The pipelines VAX implementation happened already in 1984 with the VAX
8600. Yes, it did take some effort, but it was not as complicated as you
seem to imply. And all later VAXen was pipelined.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372178 is a reply to message #372141] |
Tue, 14 August 2018 05:29 |
|
|
Originally posted by: Johnny Billquist
On 2018-08-13 21:48, Rich Alderson wrote:
> John Levine <johnl@taugh.com> writes:
>
>> In article <0897e059-0b26-4334-82ff-5c0b2253a89e@googlegroups.com>,
>> Quadibloc <jsavard@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: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372179 is a reply to message #372174] |
Tue, 14 August 2018 05:43 |
|
|
Originally posted by: Johnny Billquist
On 2018-08-14 05:47, terry-groups@glaver.org wrote:
> On Monday, August 13, 2018 at 3:48:10 PM UTC-4, Rich Alderson wrote:
>> 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 remember talking to a fellow system administrator at another university who said they were going to an entirely Unix-based environment. When I asked why, he replied "We will have a large choice of which vendor we want to be screwed by".
Yeah, that sounds similar to what I heard/saw. They pretty universally
went with Unix. VMS never got a foot in the door anywhere at any of
those sites.
> OTOH, if Jupiter had delivered, my understanding (from the far outside) is that it would have been rather late, unacceptably slow, and extremely non-price-competitive.
That's the story, at least (as I remember it). Jupiter was having
problems with performance and was way late. It was sharing technology
with Venus (the 8600). And Venus was also late and had performance
problems. At one point they decided that the were going to rescue Venus
at the expense of Jupiter, so they pooled the people and resources in
order to solve the problems on one side at least.
> Wasn't Jupiter from the (approximately) same part of DEC that produced the VAX 86x0 (missed its performance goals, shipped late) and 8650 (fixing the few remaining problems that cause the 8600 to not operate at the design speed)? And the 8670, which should have been the "mid-life kicker" upgrade for the 8600, assuming it shipped at the design speed? And the same (approximate) group that brought us the VAX 9000 family (repeat mantra of late, slow, expensive)?
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.
That said though, since it was delayed so much, one could argue that the
bar should have been raised from the original plans.
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,
and the NVAX came out not long after with the same performance on a
chip, making the 9000 immediately obsolete.
That was one costly adventure...
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.
> It would seem in retrospect that the best thing to do would be to give the Jupiter group some sort of award and stick them in another building where they couldn't do any harm, and then make a deal with one of the many non-DEC vendors that already had fast systems. I know the second part (make a deal with a non-DEC vendor) got at least to the discussion phase, as the meeting minutes are over on Bitsavers.
Cancelling the PDP-10 was maybe a mistake in one sense, but at the same
time, it's hard to believe that the architecture had much of a future
anyway, even with all the nice bits.
Ultimately, I suspect it was the right decision to kill it. But DEC did
it in a really bad way. Making a deal with a non-DEC vendor would have
been a wise move for the short term.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372181 is a reply to message #372179] |
Tue, 14 August 2018 06:46 |
|
|
Originally posted by: terry-groups
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 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.
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.
> 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.
> 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.
> 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.
|
|
|
|
| Re: our friend the VAX, was PDP 11/40 system manual [message #372182 is a reply to message #372177] |
Tue, 14 August 2018 09:21 |
|
|
Originally posted by: Bob Eager
On Tue, 14 Aug 2018 11:17:31 +0200, Johnny Billquist wrote:
> The VAX do have more light weight subroutine calls than the generic
> CALLS/CALLG. I don't know why people never seem to know this. There is
> the JSB/RSB pair, which is just the simple push the return address and
> jump and nothing more opcodes (and the return is obviously just a pop
> the return address).
One could argue that BSB/RSB are even slightly lighter! :)
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372183 is a reply to message #372145] |
Tue, 14 August 2018 09:26 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <5b71ce88.4681852@news.dslextreme.com> you write:
>> Your so-called "categories" are arbitrary and mostly meaningless. Even before
>> the advent of the 360, they were always "general purpose" computers. Meaning
>> they could be used for any application, given the proper programming. The
>> salient differences were in CPU speed, storage capacity, and data transfer
>> rates. ...
>
> Yes and no. The architecture of the binary word addressed 704x/709x
> scientific machines was rather different from the decimal word 7070 or
> the character addressed 705/7080. Sure, they were all Turing
> complete, but the 7080 was bad at floating point arithmetic and the
> 7090 was bad at moving character strings around.
But even then, IBM didn't soley define the computer business.
>
> We all think it's obvious to have byte/word addressing where the word
> addresses are byte addresses with the low bits zero, but it wasn't
> obvious at all before IBM invented it for the 360.
Digit addressibility in the B3500 is quite similar, which considered
4 digits a word.
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372187 is a reply to message #372145] |
Tue, 14 August 2018 09:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> In article <5b71ce88.4681852@news.dslextreme.com> you write:
>> Your so-called "categories" are arbitrary and mostly meaningless. Even before
>> the advent of the 360, they were always "general purpose" computers. Meaning
>> they could be used for any application, given the proper programming. The
>> salient differences were in CPU speed, storage capacity, and data transfer
>> rates. ...
>
> Yes and no. The architecture of the binary word addressed 704x/709x
> scientific machines was rather different from the decimal word 7070 or
> the character addressed 705/7080. Sure, they were all Turing
> complete, but the 7080 was bad at floating point arithmetic and the
> 7090 was bad at moving character strings around.
>
> We all think it's obvious to have byte/word addressing where the word
> addresses are byte addresses with the low bits zero, but it wasn't
> obvious at all before IBM invented it for the 360. Once they had a
> memory architecture that could work either way, building the
> instruction set wasn't so hard.
Or maybe not so obvious. With word addresses you can address a lot more
memory with a given-length address field. A lot of machines, like the
PDP-10, solved this problem by having byte instructions use a byte pointer
that indicated the byte within the word, and this worked well.
>
>> The big advantage of having a line of computers with a
>> single architecture would be to ease moving from one machine to another that was
>> faster and/or bigger. It also helped IBM, assuming they could consolidate their
>> OS and system software development and support.
>
> That too, although BOS, TOS, DOS, OS/PCP, OS/MFT, OS/MVT, CP/CMS, TSS,
> and PS44 suggest that consolidating the system software didn't work
> out so well.
PS44, TSS, and CP/CMS were special cases. PS/44 was a special case, since
the /44 used the same platter disk as the 1130 (2315?), and no other 360
supported it. Also it was designed to be a real-time OS, whereas real-time
features were grafted on to OS/360 later. TSS, again, used special
hardware. CP/CMS was a "skunk works" project that took over the timesharing
space. All the rest other than OS were mistakes. IBM was unable to get
even PCP to fit on the smallest machines, so DOS, TOS, BOS were written as
"temporary" systems which became permanent. Technically, PCP, MFT, and MVT
were "options" of OS/360, and they did share most of the same code base. I
think BOS may have been a development system used to bootstrap OS, and the
others were just developed from it.
--
Pete
|
|
|
|
| Re: PDP 11/40 system manual [message #372188 is a reply to message #372163] |
Tue, 14 August 2018 09:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2018-08-10, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
>> On Thursday, August 9, 2018 at 5:36:25 PM UTC-4, Peter Flass wrote:
>>
>>> Charles Richmond <numerist@aquaporin4.com> wrote:
>>>
>>>> *Not* that I disagree... but which other computers do you find elegant???
>>> System/360.
>>
>> +1
>
> +0.9 - I had to knock off a tenth because they went and used BXH and BXLE
> instead of BXHE and BXL, which IMHO would have made a lot more sense.
>
> The other machine that stands out in my mind is the PDP-11. I once
> hand-disassembled the Dungeon machine code and was stunned by its
> elegance. Making R7 the program counter and R6 the stack pointer,
> plus predecrement and postincrement, made it possible to do all sorts
> of nifty program control stuff with what at first looked like ordinary
> data manipulation instructions. The Dungeon binary was threaded code
> implemented in hardware.
>
I don't consider this kind of coding "elegant". I like straightforward
instruction sets without lots of unexpected side-effects. It's neat, and
fun to write, but hell for someone else to pick up.
--
Pete
|
|
|
|
| Re: PDP 11/40 system manual [message #372189 is a reply to message #372167] |
Tue, 14 August 2018 09:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2018-08-12, Huge <Huge@nowhere.much.invalid> wrote:
>
>> On 2018-08-11, Bob Eager <news0073@eager.cx> wrote:
>>
>>> On Sat, 11 Aug 2018 09:51:18 +0000, Huge wrote:
>>>
>>>> On 2018-08-10, Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
>>
>> [39 lines snipped]
>>
>>>> > There will be a talk on ICL 1900 Series resurrection next month:
>>>> >
>>>> > Title: ICL 1900 Software Recovery Speaker: Bill Gallagher, Delwyn
>>>> > Holroyd & Brian Spoor Date: Thursday 20th September 2018 Time: 14:30
>>>> > Location: BCS, 5 Southampton St, London WC2E 7HA
>>
>> SFPBA. Can't go. Why is it that events on my otherwise sparse calender
>> tend to cluster together?
>
> I once heard a saying: "Time is nature's way of keeping everything from
> happening at once." Too bad it's totally wrong.
>
>> I learned RPG2 [gag, spit, cough] for a project at Associated Televison
>> to migrate their payroll from a 1900 Autocoder system to a 2903 RPG2
>> [nausea] one. I went on a 2 week course at ICL to learn RPG2 [Ghod, I
>> think I'm actually going to vomit] for that.
>
> I learned RPG2 at the beginning of my career. My attitude was a bit
> more conciliatory: I found it pretty good at doing what it wasn intended
> to do, i.e. generate report programs (although that 1P indicator nonsense
> obviously came from someone who never learned how to properly handle page
> overflows).
>
> The one that made me gag was RPG3. That's when IBM forgot what RPG
> stood for and started writing screen-based interactive programs with it.
>
At a great remove I guess RPG was in the same class as "4GLs", like MarkIV,
SPSS/SAS when used as report generators, Manage on Sigma systems, and lots
of similar stuff. RPG suffered by being card-column oriented, but otherwise
these all had the idea of a built-in loop to process records.
--
Pete
|
|
|
|
| Re: PDP 11/40 system manual [message #372190 is a reply to message #372176] |
Tue, 14 August 2018 11:01 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <pku662$vso$1@Iltempo.Update.UU.SE>,
Johnny Billquist <bqt@softjar.se> wrote:
> On 2018-08-14 03:38, Charlie Gibbs wrote:
>> data manipulation instructions. The Dungeon binary was threaded code
>> implemented in hardware.
>
> You do know that Dungeon is written in FORTRAN? So you were
> disassembling something produced by a compiler.
Sounds like the old fc compiler. When I was a grad student in the
late 1970s I made some minor changes to it so it could give you a
backtrace if something failed. If the threaded code pseudo PC was
R5, each of the threaded code routines ended with JMP @(R5)+ which
dispatched directly to the next one. It wasn't particularly fast
but the code was compact and you could do interesting stuff by
customizing the thread routines.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372191 is a reply to message #372187] |
Tue, 14 August 2018 11:40 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <1355830485.555945700.866949.peter_flass-yahoo.com@news.eternal-september.org>,
Peter Flass <peter_flass@yahoo.com> wrote:
>> We all think it's obvious to have byte/word addressing where the word
>> addresses are byte addresses with the low bits zero, but it wasn't
>> obvious at all before IBM invented it for the 360. Once they had a
>> memory architecture that could work either way, building the
>> instruction set wasn't so hard.
>
> Or maybe not so obvious. With word addresses you can address a lot more
> memory with a given-length address field. A lot of machines, like the
> PDP-10, solved this problem by having byte instructions use a byte pointer
> that indicated the byte within the word, and this worked well.
That's right. I know of a similar character addresssing kludge in the
GE 635. It was OK, but the profusion of byte instructions added to
the later models of -10 suggest that it didn't work that well.
The 360 design was clever that the addresses in the architecture were
big but base registers kept the instructions were small, so only the
registers had to be 32 bits.
>> That too, although BOS, TOS, DOS, OS/PCP, OS/MFT, OS/MVT, CP/CMS, TSS,
>> and PS44 suggest that consolidating the system software didn't work
>> out so well.
>
> PS44, TSS, and CP/CMS were special cases. PS/44 was a special case, since
> the /44 used the same platter disk as the 1130 (2315?), and no other 360
> supported it. Also it was designed to be a real-time OS, whereas real-time
> features were grafted on to OS/360 later.
More to the point, the /44 only implemented a subset of the 360's
instruction set, so even with different peripherals it couldn't run
any other OS.
> All the rest other than OS were mistakes. IBM was unable to get
> even PCP to fit on the smallest machines, so DOS, TOS, BOS were written as
> "temporary" systems which became permanent.
Yes. I never entirely understood the difference between BOS and DOS.
I realize that BOS could run in 8K and DOS needed 16K, but what else
did BOS leave out?
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372202 is a reply to message #372191] |
Tue, 14 August 2018 16:13 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article
> <1355830485.555945700.866949.peter_flass-yahoo.com@news.eternal-september.org>,
> Peter Flass <peter_flass@yahoo.com> wrote:
>> Or maybe not so obvious. With word addresses you can address a lot more
>> memory with a given-length address field. A lot of machines, like the
>> PDP-10, solved this problem by having byte instructions use a byte pointer
>> that indicated the byte within the word, and this worked well.
> That's right. I know of a similar character addresssing kludge in the
> GE 635. It was OK, but the profusion of byte instructions added to
> the later models of -10 suggest that it didn't work that well.
"Profusion of byte instructions"? Lemme see, LDB, DPB, ILDB, IDBP, IBP/ADJBP.
Or are you talking about the string instructions added by the VAX crowd who
got into the microcode? I honestly don't know of anyone anywhere who used any
of those--they were slower than hand coded loops using the original set.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: our friend the VAX, was PDP 11/40 system manual [message #372203 is a reply to message #372182] |
Tue, 14 August 2018 16:20 |
|
|
Originally posted by: Johnny Billquist
On 2018-08-14 15:21, Bob Eager wrote:
> On Tue, 14 Aug 2018 11:17:31 +0200, Johnny Billquist wrote:
>
>> The VAX do have more light weight subroutine calls than the generic
>> CALLS/CALLG. I don't know why people never seem to know this. There is
>> the JSB/RSB pair, which is just the simple push the return address and
>> jump and nothing more opcodes (and the return is obviously just a pop
>> the return address).
>
> One could argue that BSB/RSB are even slightly lighter! :)
Yes. You win. :-)
I'll blame it on a parity error in my brain.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372204 is a reply to message #372181] |
Tue, 14 August 2018 16:23 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
terry-groups@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.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372205 is a reply to message #372181] |
Tue, 14 August 2018 16:26 |
|
|
Originally posted by: Johnny Billquist
On 2018-08-14 12:46, terry-groups@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: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372207 is a reply to message #372202] |
Tue, 14 August 2018 17:29 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <mdd1sb0n1tl.fsf@panix5.panix.com>,
Rich Alderson <news@alderson.users.panix.com> wrote:
>> GE 635. It was OK, but the profusion of byte instructions added to
>> the later models of -10 suggest that it didn't work that well.
>
> "Profusion of byte instructions"? Lemme see, LDB, DPB, ILDB, IDBP, IBP/ADJBP.
> Or are you talking about the string instructions added by the VAX crowd who
> got into the microcode?
The latter. They do resemble the Vax instructions which resemble 360
instructions like ED and TRT.
> I honestly don't know of anyone anywhere who used any
> of those--they were slower than hand coded loops using the original set.
Yeah, complex microcode can be like that. By the time the -20 got all
that stuff, I was making BSD Unix work on an 11/750, which was another
story.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372214 is a reply to message #372145] |
Tue, 14 August 2018 19:15 |
Rob Doyle
Messages: 62
Registered: January 2012
Karma: 0
|
Member |
|
|
On 8/13/2018 2:23 PM, John Levine wrote:
> In article <5b71ce88.4681852@news.dslextreme.com> you write:
>> Your so-called "categories" are arbitrary and mostly meaningless. Even before
>> the advent of the 360, they were always "general purpose" computers. Meaning
>> they could be used for any application, given the proper programming. The
>> salient differences were in CPU speed, storage capacity, and data transfer
>> rates. ...
>
> Yes and no. The architecture of the binary word addressed 704x/709x
> scientific machines was rather different from the decimal word 7070 or
> the character addressed 705/7080. Sure, they were all Turing
> complete, but the 7080 was bad at floating point arithmetic and the
> 7090 was bad at moving character strings around.
>
> We all think it's obvious to have byte/word addressing where the word
> addresses are byte addresses with the low bits zero, but it wasn't
> obvious at all before IBM invented it for the 360. Once they had a
> memory architecture that could work either way, building the
> instruction set wasn't so hard.
.... and forgotten by the time that the DEC Alpha arrived on the scene.
The first few versions of the DEC Alpha couldn't load or store 8-bit or
16-bit data to/from memory. Those instructions were added (EV5) when
they realized how crazy that decision was. Oops.
[snip]
Rob.
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372215 is a reply to message #372214] |
Tue, 14 August 2018 19:42 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <pkvnqe$3ft$1@gioia.aioe.org>,
Rob Doyle <radioengr@gmail.com> wrote:
>> We all think it's obvious to have byte/word addressing where the word
>> addresses are byte addresses with the low bits zero, but it wasn't
>> obvious at all before IBM invented it for the 360. Once they had a
>> memory architecture that could work either way, building the
>> instruction set wasn't so hard.
>
> ... and forgotten by the time that the DEC Alpha arrived on the scene.
>
> The first few versions of the DEC Alpha couldn't load or store 8-bit or
> 16-bit data to/from memory. Those instructions were added (EV5) when
> they realized how crazy that decision was. Oops.
The IBM 801 did the same thing. The theory on the 801 was that they
would really do a RISC and strip everything out of the hardware that
they could do in software. At the time the logic to do byte stores to
word memory was complex enough that they figured (probably correctly
because they had better compiler people than anyone else) that they
could do it in software and make the machine faster over all.
As gates continued to get cheaper a lot of stuff has crept back in,
with misaligned and partial word loads and stores near the head of the
line.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372238 is a reply to message #372191] |
Wed, 15 August 2018 07:09 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> In article <1355830485.555945700.866949.peter_flass-yahoo.com@news.eternal-september.org>,
> Peter Flass <peter_flass@yahoo.com> wrote:
>>> We all think it's obvious to have byte/word addressing where the word
>>> addresses are byte addresses with the low bits zero, but it wasn't
>>> obvious at all before IBM invented it for the 360. Once they had a
>>> memory architecture that could work either way, building the
>>> instruction set wasn't so hard.
>>
>> Or maybe not so obvious. With word addresses you can address a lot more
>> memory with a given-length address field. A lot of machines, like the
>> PDP-10, solved this problem by having byte instructions use a byte pointer
>> that indicated the byte within the word, and this worked well.
>
> That's right. I know of a similar character addresssing kludge in the
> GE 635. It was OK, but the profusion of byte instructions added to
> the later models of -10 suggest that it didn't work that well.
>
> The 360 design was clever that the addresses in the architecture were
> big but base registers kept the instructions were small, so only the
> registers had to be 32 bits.
>
>>> That too, although BOS, TOS, DOS, OS/PCP, OS/MFT, OS/MVT, CP/CMS, TSS,
>>> and PS44 suggest that consolidating the system software didn't work
>>> out so well.
>>
>> PS44, TSS, and CP/CMS were special cases. PS/44 was a special case, since
>> the /44 used the same platter disk as the 1130 (2315?), and no other 360
>> supported it. Also it was designed to be a real-time OS, whereas real-time
>> features were grafted on to OS/360 later.
>
> More to the point, the /44 only implemented a subset of the 360's
> instruction set, so even with different peripherals it couldn't run
> any other OS.
I understand there was a later microcode update so it could run OS/360.
>
>> All the rest other than OS were mistakes. IBM was unable to get
>> even PCP to fit on the smallest machines, so DOS, TOS, BOS were written as
>> "temporary" systems which became permanent.
>
> Yes. I never entirely understood the difference between BOS and DOS.
> I realize that BOS could run in 8K and DOS needed 16K, but what else
> did BOS leave out?
>
I don't know that much about BOS either. I used to think it was a subset of
OS, but Bitsavers has some manuals and it appears it was a subset of DOS.
I'll have to read the manuals. I would assume it at least left out
multiprogramming. I think BOS could be run from cards.
--
Pete
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372239 is a reply to message #372204] |
Wed, 15 August 2018 07:09 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Rich Alderson <news@alderson.users.panix.com> wrote:
> terry-groups@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?
--
Pete
|
|
|
|
|
|
| Re: PDP 11/40 system manual [message #372246 is a reply to message #372176] |
Wed, 15 August 2018 10:14 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2018-08-14, Johnny Billquist <bqt@softjar.se> wrote:
> On 2018-08-14 03:38, Charlie Gibbs wrote:
>
>> The other machine that stands out in my mind is the PDP-11. I once
>> hand-disassembled the Dungeon machine code and was stunned by its
>> elegance. Making R7 the program counter and R6 the stack pointer,
>> plus predecrement and postincrement, made it possible to do all sorts
>> of nifty program control stuff with what at first looked like ordinary
>> data manipulation instructions. The Dungeon binary was threaded code
>> implemented in hardware.
>
> You do know that Dungeon is written in FORTRAN? So you were
> disassembling something produced by a compiler.
Yes, but all I had at the time was a copy of the binary. I actually
managed to write a program on a Univac 90/30 (an IBM 360 work-alike
which I had much more ready access to) that emulated PDP-11 machine
instructions, but the project foundered on the system calls, for
which I had no documentation.
A couple of years later I did get my hands on the source code -
all 14,000 lines of FORTRAN - and ported it. The hard part was
the terminal I/O - going from character-mode asynchronous terminals
to block-mode synchronous ones took some work. But I had already
done that for Adventure, so all I had to worry about were things
like translating the ASCII files (including encrypted ones) to
EBCDIC, writing functions for the bitwise logical operators which
Univac FORTRAN didn't support, and replacing all the RAD50 constants
with normal character constants. But at least I finally got to play
Dungeon right to the end.
--
/~\ 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
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372248 is a reply to message #372245] |
Wed, 15 August 2018 11:20 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> John Levine <johnl@taugh.com> writes:
>> In article <mdd1sb0n1tl.fsf@panix5.panix.com>,
>> Rich Alderson <news@alderson.users.panix.com> wrote:
>>>> GE 635. It was OK, but the profusion of byte instructions added to
>>>> the later models of -10 suggest that it didn't work that well.
>>>
>>> "Profusion of byte instructions"? Lemme see, LDB, DPB, ILDB, IDBP, IBP/ADJBP.
>>> Or are you talking about the string instructions added by the VAX crowd who
>>> got into the microcode?
>>
>> The latter. They do resemble the Vax instructions which resemble 360
>> instructions like ED and TRT.
>
> or EDT and TRN on the contemporaneous B-3500 (albeit not microcoded).
>
> http://vseries.lurndal.org/doku.php?id=instructions:edt
> http://vseries.lurndal.org/doku.php?id=instructions:trn
>
If you have a TR instruction, TRT is trivial to implement in hardware.
--
Pete
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372249 is a reply to message #372239] |
Wed, 15 August 2018 11:41 |
mausg
Messages: 2483
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On 2018-08-15, Peter Flass <peter_flass@yahoo.com> wrote:
> Rich Alderson <news@alderson.users.panix.com> wrote:
>> terry-groups@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?
--
Maus@ireland.com
Will Rant For Food
|
|
|
|
| Re: changing architectures [was Re: PDP-10 addressing, PDP 11/40 system manual] [message #372254 is a reply to message #372249] |
Wed, 15 August 2018 13:04 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
mausg@mail.com writes:
> On 2018-08-15, Peter Flass <peter_flass@yahoo.com> wrote:
>> Rich Alderson <news@alderson.users.panix.com> wrote:
>>> terry-groups@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_?
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372256 is a reply to message #372238] |
Wed, 15 August 2018 13:58 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <504928995.556023147.952672.peter_flass-yahoo.com@news.eternal-september.org>,
Peter Flass <peter_flass@yahoo.com> wrote:
>> More to the point, the /44 only implemented a subset of the 360's
>> instruction set, so even with different peripherals it couldn't run
>> any other OS.
>
> I understand there was a later microcode update so it could run OS/360.
So the IBM web site says, but I doubt it was very popular. Why get a
machine with strange realtime peripherals if you want to run OS?
>> Yes. I never entirely understood the difference between BOS and DOS.
>> I realize that BOS could run in 8K and DOS needed 16K, but what else
>> did BOS leave out?
>
> I don't know that much about BOS either. I used to think it was a subset of
> OS, but Bitsavers has some manuals and it appears it was a subset of DOS.
> I'll have to read the manuals. I would assume it at least left out
> multiprogramming. I think BOS could be run from cards.
I've read the manuals too. The card version of BOS was called BPS,
and none of BOS, DOS, or TOS, could do multiprogramming until much
later versions of DOS. It looks to me like the disk management was
even more primitive than DOS, with sets of disk tracks explicitly
assigned to files, and it didn't work with more than 32K which
suggests they used direct addressing and 16 bit adcons.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372257 is a reply to message #372256] |
Wed, 15 August 2018 14:39 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <504928995.556023147.952672.peter_flass-yahoo.com@news.eternal-september.org>,
> Peter Flass <peter_flass@yahoo.com> wrote:
>>> More to the point, the /44 only implemented a subset of the 360's
>>> instruction set, so even with different peripherals it couldn't run
>>> any other OS.
>>
>> I understand there was a later microcode update so it could run OS/360.
>
> So the IBM web site says, but I doubt it was very popular. Why get a
> machine with strange realtime peripherals if you want to run OS?
>
>>> Yes. I never entirely understood the difference between BOS and DOS.
>>> I realize that BOS could run in 8K and DOS needed 16K, but what else
>>> did BOS leave out?
>>
>> I don't know that much about BOS either. I used to think it was a subset of
>> OS, but Bitsavers has some manuals and it appears it was a subset of DOS.
>> I'll have to read the manuals. I would assume it at least left out
>> multiprogramming. I think BOS could be run from cards.
>
> I've read the manuals too. The card version of BOS was called BPS,
> and none of BOS, DOS, or TOS, could do multiprogramming until much
> later versions of DOS. It looks to me like the disk management was
> even more primitive than DOS, with sets of disk tracks explicitly
> assigned to files, and it didn't work with more than 32K which
> suggests they used direct addressing and 16 bit adcons.
I implemented a multiprogrammed online system on a very early
version of DOS, long before DOS/VS. I think ATTACH and friends
were pretty much there from the beginning.
Never saw BOS put to serious use, I think BOS gave you about a 4K
supervisor where DOS would be 10K or so.
--
Dan Espen
|
|
|
|
| Re: different architecture, was PDP 11/40 system manual [message #372258 is a reply to message #372238] |
Wed, 15 August 2018 14:58 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Wednesday, August 15, 2018 at 7:09:42 AM UTC-4, Peter Flass wrote:
>>> All the rest other than OS were mistakes. IBM was unable to get
>>> even PCP to fit on the smallest machines, so DOS, TOS, BOS were written as
>>> "temporary" systems which became permanent.
>>
>> Yes. I never entirely understood the difference between BOS and DOS.
>> I realize that BOS could run in 8K and DOS needed 16K, but what else
>> did BOS leave out?
>>
>
> I don't know that much about BOS either. I used to think it was a subset of
> OS, but Bitsavers has some manuals and it appears it was a subset of DOS.
> I'll have to read the manuals. I would assume it at least left out
> multiprogramming. I think BOS could be run from cards.
I think the IBM S/360 history says BOS was intended as an
emergency operating system rushed out so the users would have
something to use quickly. It could also be used in very small
systems--I believe S/360 was originally offered in only 8k (later
raised to 16k). DOS was also an emergency development, but
DOS managed to be permanent.
|
|
|
|
| Re: PDP 11/40 system manual [message #372259 is a reply to message #371990] |
Wed, 15 August 2018 15:03 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, August 10, 2018 at 6:10:47 PM UTC-4, John Levine wrote:
> The S/360 was a tour de force but it had plenty of uglies that people
> have been dealing with ever since, the worst of which was 24 bit
> addressing.
I think in the very early 1960s when they envisioned S/360, 24
bit (16 meg) was deemed more than adequate. Storage was very
expensive back then. I don't believe S/360 ever existed 16 meg,
indeed, I think it took a long time until S/370 even exceeded it.
Our 370-158 had all of 6 meg, serving a large organization and
500 terminals.
|
|
|
|
| Re: PDP 11/40 system manual [message #372261 is a reply to message #371985] |
Wed, 15 August 2018 15:32 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, August 10, 2018 at 3:01:10 PM UTC-4, Rich Alderson wrote:
> My first computer was the IBM 1401. *Not* an elegant architecture, but not
> without points of interest.
I have no idea of the "rating" of the 1401's architecture or
internal electronics. But Campbell-Kelly noted the big feature
of the 1401 was mechanical--its high quality and high speed
1403 printer (and high speed card reader).
The marketplace certainly loved 1401, giving it very high
sales, especially for that time.
|
|
|
|
Members
Search
Help
Register
Login
Home
