🚀 go-pugleaf

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?

-- 
To de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 
637F 896B C810 E199 7E5C A9E4 8E59 E248

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.

-- 
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 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???

-- 
numerist at aquaporin4 dot com

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???
> 

System/360.

-- 
Pete

On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:

> 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???
>> 
>> 
> System/360.

All that base register stuff...

For me, the ICL 2900 (largely designed by Manchester University).

One variable size accumulator. 
One B register.
One descriptor register.
One stack frame register and one stack front register.
Two off-stack bases for other data.
Segmentation and paging.

Performance good at front of stack due to caching. Better than trying to 
optimise register use.



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

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

On Thursday, August 9, 2018 at 3:54:51 PM UTC-6, Bob Eager wrote:
> On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:

> > System/360.

> All that base register stuff...

But surely that's unavoidable, if you want to have more than 64 K of memory?

John Savard

Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Thursday, August 9, 2018 at 3:54:51 PM UTC-6, Bob Eager wrote:
>> On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:
> 
>>> System/360.
> 
>> All that base register stuff...
> 
> But surely that's unavoidable, if you want to have more than 64 K of memory?
> 
> John Savard
> 

That's what makes it  elegant -it's a compromise between addressable memory
and instruction size.

-- 
Pete

On Thursday, August 9, 2018 at 5:36:25 PM UTC-4, Peter Flass wrote:
> 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???

 
> System/360.

+1

On Friday, August 10, 2018 at 9:57:39 AM UTC-4, Peter Flass wrote:
> Quadibloc <jsa...@ecn.ab.ca> wrote:
> > On Thursday, August 9, 2018 at 3:54:51 PM UTC-6, Bob Eager wrote:
> >> On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:
> > 
> >>> System/360.
> > 
> >> All that base register stuff...
> > 
> > But surely that's unavoidable, if you want to have more than 64 K of memory?
> > 
> > John Savard
> > 
> 
> That's what makes it  elegant -it's a compromise between addressable memory
> and instruction size.

IMHO, System/360 represented an elegant design because it
was able to use a single architecture to serve four different
categories of data processing (large/small/business/sci-eng).
Previously, most computers were designed to serve only one
of those categories.  Many companies required multiple 
computers if they had multiple needs.

While S/360 didn't totally eliminate multiple computers for
a single company (such as a S/360 in the business office
with some DECs in the labs), many were able to share their
business office needs and engineering needs on the same machine.

In article <1028478389.555543171.735...@news.eternal-september.org>,
Peter Flass  <peter...@yahoo.com> wrote:
>>>> 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???
>
>System/360.

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.

The PDP-8, on the other hand, was close to perfectly elegant.

-- 
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 Fri, 10 Aug 2018 22:10:46 +0000, John Levine wrote:

> In article
> <1028478389.555543171.735142.peter_flass-yahoo.com@news.eternal-
september.org>,
> Peter Flass  <peter...@yahoo.com> wrote:
>>>>> 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???
>>
>>System/360.
> 
> 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.
> 
> The PDP-8, on the other hand, was close to perfectly elegant.

I agree there, too. Simple enough for an introductory course on assembly 
language.

There's a reason I have two replica PDP-8s, and am building a third!



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

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

In article <c1165d5b-1d41-4f6b...@googlegroups.com>,
Quadibloc  <jsa...@ecn.ab.ca> wrote:
>On Thursday, August 9, 2018 at 3:54:51 PM UTC-6, Bob Eager wrote:
>> On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:
>
>> > System/360.
>
>> All that base register stuff...
>
>But surely that's unavoidable, if you want to have more than 64 K of memory?

The issue was that they wanted to have a single architecture that was
usable on a 16K 360/30 and a 4MB 360/70.  So it needed large addresses
in the architecture (should have been 32 bits but they wimped out and
limited it to 24 which was clearly a mistake), but they needed small
addresses in the instructions to make the instruction density high
enough.

Base+displacement addressing was a reasonable approach, but they made
two mistakes.  One is that code addressing should have been PC
relative rather than base relative so the RX and RS branch
instructions should have had 16 bit branch offsets.  This would have
allowed branches 64K in either direction (instructions are halfword
aligned so don't store the low zero bit) which is a lot of code.  They
fixed this much later by adding relative addressing to s/390.

The other was that they thought that base addressing gave them
position independent code, from what they said in the architecture
articles in the IBM SJ.  Branch addressing with BALR to set the base
register is position independent, but pointers stored in memory are
not.  This could have been addressed by disciplined programming (as it
was in TSS/360) but instructions like "load pointer and add base
register" would have given people a hint of how things were supposed
to work.

-- 
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 <1028478389.555543171.735...@news.eternal-september.org>,
> Peter Flass  <peter...@yahoo.com> wrote:
>>>>> 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???
>> 
>> System/360.
> 
> 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.

The /67 had full 32-bit addressing, which (IMHO) is the way they should
have gone with later models.

> 
> The PDP-8, on the other hand, was close to perfectly elegant.
> 



-- 
Pete

On 9 Aug 2018 21:54:48 GMT, Bob Eager <news...@eager.cx> wrote:
>On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:
>
>> 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???
>>> 
>>> 
>> System/360.
>
>All that base register stuff...

Indeed.  Base registers, register save sets, No stack instructions, and the
difficulty writing re-entrant code... yuck.  IBM = I buy memory

On Fri, 10 Aug 2018 10:50:00 -0700 (PDT), hanc...@bbs.cpcn.com wrote:
>On Friday, August 10, 2018 at 9:57:39 AM UTC-4, Peter Flass wrote:
>> Quadibloc <jsa...@ecn.ab.ca> wrote:
>> > On Thursday, August 9, 2018 at 3:54:51 PM UTC-6, Bob Eager wrote:
>> >> On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:
>> >>> System/360.
>> > 
>> >> All that base register stuff...
>> > 
>> > But surely that's unavoidable, if you want to have more than 64 K of memory?
>> 
>> That's what makes it  elegant -it's a compromise between addressable memory
>> and instruction size.
>
>IMHO, System/360 represented an elegant design because it
>was able to use a single architecture to serve four different
>categories of data processing (large/small/business/sci-eng).
>Previously, most computers were designed to serve only one
>of those categories.  Many companies required multiple 
>computers if they had multiple needs.

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.  Depending on the application, a small business might need a fast machine
that could handle a large volume of data; a large business might well make do
with a slower model.  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.


>While S/360 didn't totally eliminate multiple computers for
>a single company (such as a S/360 in the business office
>with some DECs in the labs), many were able to share their
>business office needs and engineering needs on the same machine.

There was nothing stopping them from doing so before, apart from having an
underpowered machine.

It sounds like you are just parroting IBM marketing rhetoric.

In article <5b71ce88...@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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 2018-08-10, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> On Thursday, August 9, 2018 at 5:36:25 PM UTC-4, Peter Flass wrote:
>
>> Charles Richmond <nume...@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

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: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

John Levine <jo...@taugh.com> writes:
>In article <5b71ce88...@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.

John Levine <jo...@taugh.com> wrote:
> In article <5b71ce88...@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

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2018-08-10, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:
> 
>> On Thursday, August 9, 2018 at 5:36:25 PM UTC-4, Peter Flass wrote:
>> 
>>> Charles Richmond <nume...@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

In article <pku662$vso$1...@Iltempo.Update.UU.SE>,
Johnny Billquist  <b...@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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <1355830485.555945700.866...@news.eternal-september.org>,
Peter Flass  <peter...@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, 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:

> In article
> <1355830485.555945700.866...@news.eternal-september.org>,
> Peter Flass <peter...@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					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

In article <mdd1sb0...@panix5.panix.com>,
Rich Alderson  <ne...@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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 8/13/2018 2:23 PM, John Levine wrote:
> In article <5b71ce88...@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.

In article <pkvnqe$3ft$1...@gioia.aioe.org>,
Rob Doyle  <radi...@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, 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 <1355830485.555945700.866...@news.eternal-september.org>,
> Peter Flass  <peter...@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

John Levine <jo...@taugh.com> writes:
>In article <mdd1sb0...@panix5.panix.com>,
>Rich Alderson  <ne...@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

On 2018-08-14, Johnny Billquist <b...@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

Scott Lurndal <scott@slp53.sl.home> wrote:
> John Levine <jo...@taugh.com> writes:
>> In article <mdd1sb0...@panix5.panix.com>,
>> Rich Alderson  <ne...@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

In article <504928995.556023147.9526...@news.eternal-september.org>,
Peter Flass  <peter...@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, 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:

> In article <504928995.556023147.9526...@news.eternal-september.org>,
> Peter Flass  <peter...@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

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.

On Monday, August 13, 2018 at 5:23:26 PM UTC-4, John Levine wrote:
> In article <5b71ce88...@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.

True.  Plenty of customers did use binary machines for business
and character machines for sci/eng, but it was inefficient.  
Computer time was very costly, so it had to be used carefully.

Here, we discussed how using an offline sorter was more cost
efficient in the early days than sorting by the computer itself.




> 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.

As mentioned, memory was extremely expensive, so a bigger machine
had extra cost in having longer instructions to support a larger
address space.  Note that the low-end 1401 was only 1,400 characters,
and I believe the original S/360 was offered as low as 8k.

It's hard to believe.




> 
> > 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.

Yes, the development and expectations for S/360 "OS" was a big
blunder.  I can't help but suspect IBM should have known better
that _both_ their performance goals and development schedule
were far too ambitious.   Didn't they have big software development
experience with SAGE (although contracted out), and SABRE?

In my humble opinion, I think IBM wasted very scarce resources
at the time developing PL/I and TSS.  COBOL and FORTRAN were 
adequate, they didn't need PL/I.  I can't help but suspect that
TSS was developed as a result of _perceived_ pressures, not
actual market demands--I don't think there was that much
demand for it in the early 1960s--most users were batch
oriented.

In other words, I'm pretty sure Watson wanted S/360 to be
a true universal computer for every possible customer,
when in fact there were some specialty uses best left
to others, an idea Watson couldn't stomach.

IMHO, IBM should've concentrated on getting the basic batch
versions of S/360 out the door first, then worked on enhancing
the software to exploit the hardware's advanced features.
In other words, walk before running.

IBM was correct that a unified product line would help them
on peripherals.  AFAIK, most major S/360 peripherals were
usable without modification throughout the product line.
I believe before S/360, each peripheral had to be customized
for a particular model of computer.  

I think most people know that IBM's 1959 technology--SMS circuit
cards--found even bigger use in S/360 peripherals.

hanc...@bbs.cpcn.com writes:

> 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.

An 8K S/360 would have been useless, OTOH,
lots of 8K 1401s worked very well.

IBM managed to design something so complex
that it needed an OS, and IBM couldn't shoehorn
the OS into 8K, let alone any applications.

An existing 8K 1401 shop would need a S330/30
with 64K.  Lots of places tried 32K, that never
worked well.

-- 
Dan Espen

John Levine <jo...@taugh.com> wrote:
> In article <504928995.556023147.9526...@news.eternal-september.org>,
> Peter Flass  <peter...@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, 

That's how DOS worked, although I think the've improved it since. SYSPROGs
used to have all charts showing disk map of each pack.

> and it didn't work with more than 32K which
> suggests they used direct addressing and 16 bit adcons.
> 
> 



-- 
Pete

Dan Espen <dan1...@gmail.com> wrote:
> John Levine <jo...@taugh.com> writes:
> 
>> In article <504928995.556023147.9526...@news.eternal-september.org>,
>> Peter Flass  <peter...@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.

DOS used to have a max of three partitions: BG, F1, and F2, with no
multitasking within a partition, so no ATTACH. 

> 
> Never saw BOS put to serious use, I think BOS gave you about a 4K
> supervisor where DOS would be 10K or so.
> 

6K or 8K. I remember working through the "storage estimates" manual to
figure out what I could include and what had to be left out. "Let's see,
this feature requires 32 bytes, can I specify this?"I think 6K was BG only.


-- 
Pete

Dan Espen <dan1...@gmail.com> wrote:
> hanc...@bbs.cpcn.com writes:
> 
>> 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.
> 
> An 8K S/360 would have been useless, OTOH,
> lots of 8K 1401s worked very well.
> 
> IBM managed to design something so complex
> that it needed an OS, and IBM couldn't shoehorn
> the OS into 8K, let alone any applications.
> 
> An existing 8K 1401 shop would need a S330/30
> with 64K.  Lots of places tried 32K, that never
> worked well.
> 

Most of my early career was developing software for customers with 32K
360/30s, and that seemed to work out quite well. Obviously basic batch
applications: personnel, payroll, accounts receivable/payable, inventory,
etc.

-- 
Pete

In article <pl1s0k$on8$1...@dont-email.me>,
Dan Espen  <dan1...@gmail.com> wrote:
>> 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. ...

>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.

Oh, sure.  DOS always had asynchronous I/O if you wanted to roll your
own multithreaded application.  But it took them several years to add
the foreground/background stuff that let you run three programs at
once.

-- 
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'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.

re:
http://www.garlic.com/~lynn/2018e.html#66 something like a 360, was PDP 11/40 system manual

There was something like 80-100 card stand-alone BPS loader. It was used
by CP/67 kernel.
https://en.wikipedia.org/wiki/IBM_Basic_Programming_Support

BPS was developed by IBM's General Products Division in Endicott, New
York. The package included "assemblers, IOCS, compilers, sorts, and
utilities but no governing control program." BPS components were
introduced in a series of product announcements between 1964 and
1965.[1]:pp.319-321

BPS came in two versions -- a strictly card system and a tape based
system which, contrary to the stated goals, kept a small supervisor
permanently resident.[2]:p.14

Programming languages available were Assembler, RPG, and FORTRAN IV
(subset). Tape FORTRAN required 16 KiB of memory.[2]:p.5 There were also
two versions of the BPS assembler, with the tape version having enhanced
capabilities.

BPS also had a "disk" counterpart called BOS. It also required 8 KiB of
memory and supported disks such as the IBM 2311.

The group responsible for BPS/BOS went on to develop DOS/360 and TOS/360
as a supposed "interim" solution when it became evident that OS/360
would be too large to run on 16 KiB systems.

... snip ...

references BPS/BOS documents
http://bitsavers.org/pdf/ibm/360/bos_bps/

When CP/67 was installed at univ. jan1968, all the source was on
os/360. Assemble updates/changes on os/360 ... generating TXT deck for
each source. Default was do diagnal stripe across top of each TXT deck
with module identifier. TXT Cards were kept in card tray ... slightly
over box of cards. BPS loader at the front, followed by PSA (page zero
storage definition, interrupt handlers, and misc. other code). Last TXT
deck was CPINIT ... default BPS behavior was transfer to the last
module/program loaded (or entry specified by LDT loader control
card). That entry would write memory image to disk which would have IPL
restart into CPINIT address that would reverse the process and start
CP/67.

In summer of 1967, I made several (lower-used) CP/67 kernel routines
"pageable" ... broken into 4k segments, but would execute non-virtual
... so couldn't cross page boundary and had to use SVC call interrupt
that would handle translating original address to its new page location
(and if required, first bring the page into storage). Objective was
to reduce CP67 fixed kernel requirements, especially for running
on 256kbyte 360/67 (getting fixed kernel down to almost 60kbyte).

CP/67 console routine was something over 20k bytes, command would be
decoded and then transfer to the specific command function. I broke the
command functions into 4k segments with external entry for each command
... that could be called by the kernel command decoder.

Turns out BPS loader had limit of 255 external entry symbols ... and
breaking up console went over the limit. I then had to do hack that
there was single entry for each 4k page group of console commands with
internal branch routine to the specific command.

Next distribution of CP67 (spring 1968) had (finally) moved all the
source to CMS ... and made update/changes much simpler.

After graduating and transfer to science center ... past posts
http://www.garlic.com/~lynn/subtopic.html#545tech 

I found a copy of BPS source in card file cabinent in the storage area
in the storage area that occupied part of the top floor of 545 tech sq.
I updated the source to handle more than 255 entries. I also found
out that BPS loader passed address of its table of enternal entries.
I then modified CPINIT to copy the BPS external entry table to the
end of pageable area ... so it was saved on the disk along with
the rest of kernel image.

None of this was included in CP67 customer product distribution, but
VM370 did adopt a subset of the pageable functions for its first
release.

mentionin CP67 pageable kernel support, some older posts
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003f.html#12 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#23 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors

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

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

> Dan Espen <dan1...@gmail.com> wrote:
>> hanc...@bbs.cpcn.com writes:
>> 
>>> 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.
>> 
>> An 8K S/360 would have been useless, OTOH,
>> lots of 8K 1401s worked very well.
>> 
>> IBM managed to design something so complex
>> that it needed an OS, and IBM couldn't shoehorn
>> the OS into 8K, let alone any applications.
>> 
>> An existing 8K 1401 shop would need a S330/30
>> with 64K.  Lots of places tried 32K, that never
>> worked well.
>
> Most of my early career was developing software for customers with 32K
> 360/30s, and that seemed to work out quite well. Obviously basic batch
> applications: personnel, payroll, accounts receivable/payable, inventory,
> etc.

As soon as you wanted to try an online application or a spooler,
you had issues.   Large COBOL applications could easily blow
the 32K limit.  I saw more than one COBOL application with overlays.
Internal sorts would be a problem.

-- 
Dan Espen

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

> Dan Espen <dan1...@gmail.com> wrote:
>> John Levine <jo...@taugh.com> writes:
>> 
>>> In article <504928995.556023147.9526...@news.eternal-september.org>,
>>> Peter Flass  <peter...@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.
>
> DOS used to have a max of three partitions: BG, F1, and F2, with no
> multitasking within a partition, so no ATTACH. 

Not sure when that was but I did online 2260s with attach in F1 in
1969.

>> Never saw BOS put to serious use, I think BOS gave you about a 4K
>> supervisor where DOS would be 10K or so.
>
> 6K or 8K. I remember working through the "storage estimates" manual to
> figure out what I could include and what had to be left out. "Let's see,
> this feature requires 32 bytes, can I specify this?"I think 6K was BG only.

Yep.  I think I might have gotten one DOS down to 8K but as time went
on, 10K and 12K became more common.

-- 
Dan Espen

Dan Espen <dan1...@gmail.com> wrote:
> Peter Flass <peter...@yahoo.com> writes:
> 
>> Dan Espen <dan1...@gmail.com> wrote:
>>> hanc...@bbs.cpcn.com writes:
>>> 
>>>> 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.
>>> 
>>> An 8K S/360 would have been useless, OTOH,
>>> lots of 8K 1401s worked very well.
>>> 
>>> IBM managed to design something so complex
>>> that it needed an OS, and IBM couldn't shoehorn
>>> the OS into 8K, let alone any applications.
>>> 
>>> An existing 8K 1401 shop would need a S330/30
>>> with 64K.  Lots of places tried 32K, that never
>>> worked well.
>> 
>> Most of my early career was developing software for customers with 32K
>> 360/30s, and that seemed to work out quite well. Obviously basic batch
>> applications: personnel, payroll, accounts receivable/payable, inventory,
>> etc.
> 
> As soon as you wanted to try an online application or a spooler,
> you had issues.   Large COBOL applications could easily blow
> the 32K limit.  I saw more than one COBOL application with overlays.
> Internal sorts would be a problem.
> 

:-)

-- 
Pete

On 2018-08-15 16:14, Charlie Gibbs wrote:
> On 2018-08-14, Johnny Billquist <b...@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.

I can see that would be a bit trickier...

> 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.

That's what I call dedicated. :-)

   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 8/16/2018 10:56 AM, Johnny Billquist wrote:
> On 2018-08-15 16:14, Charlie Gibbs wrote:
>
 >     [snip...]          [snip...]          [snip...]
> 
>> 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.
> 
> That's what I call dedicated. :-)
> 

That's crazy dedication!  Now we know how bad Charlie Gibbs wanted it!


-- 
numerist at aquaporin4 dot com

On 15 Aug 2018 14:14:19 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

>  But at least I finally got to play
> Dungeon right to the end.

	OK now honestly which was more fun playing Dungeon or arranging
that you could ?

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Wednesday, August 15, 2018 at 5:42:28 PM UTC-4, Peter Flass wrote:
> Dan Espen <dan1...@gmail.com> wrote:
> > John Levine <jo...@taugh.com> writes:
> > 
> >> In article <504928995.556023147.9526...@news.eternal-september.org>,
> >> Peter Flass  <peter...@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.
> 
> DOS used to have a max of three partitions: BG, F1, and F2, with no
> multitasking within a partition, so no ATTACH. 

Originally, on our S/360-40, we just used the background partian
for batch jobs.  Then we added a spooler ("power") to F1.  It
improved our throughput tremendously (we could tell it would do
so since the CPU wait light was almost always on when we ran
most jobs.)  

Then, we put a mini-CICS ("MTCS"?) in F2 and hung a few 3270s
off the machine.  That worked ok, too.  All of this in 192K,
and IIRC, DOS occupied all of 16k.  (Of course, the spooler,
running separately, used its own memory space.)







> 
> > 
> > Never saw BOS put to serious use, I think BOS gave you about a 4K
> > supervisor where DOS would be 10K or so.
> > 
> 
> 6K or 8K. I remember working through the "storage estimates" manual to
> figure out what I could include and what had to be left out. "Let's see,
> this feature requires 32 bytes, can I specify this?"I think 6K was BG only.

On Wednesday, August 15, 2018 at 5:42:29 PM UTC-4, Peter Flass wrote:
> Dan Espen <dan1...@gmail.com> wrote:
> > hanc...@bbs.cpcn.com writes:
> > 
> >> 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.
> > 
> > An 8K S/360 would have been useless, OTOH,
> > lots of 8K 1401s worked very well.
> > 
> > IBM managed to design something so complex
> > that it needed an OS, and IBM couldn't shoehorn
> > the OS into 8K, let alone any applications.
> > 
> > An existing 8K 1401 shop would need a S330/30
> > with 64K.  Lots of places tried 32K, that never
> > worked well.
> > 
> 
> Most of my early career was developing software for customers with 32K
> 360/30s, and that seemed to work out quite well. Obviously basic batch
> applications: personnel, payroll, accounts receivable/payable, inventory,
> etc.

We had 128k.  I think most of our COBOL programs needed _roughly_
about 64k, though a few complex 3,000 line programs could use as 
much as 100k (on a 128k machine).  

I know some sites used COBOL segmentation to save space.  

Many sites in the early days used only assembler since that used
less space than COBOL, especially with a skilled programmer who
knew the memory saving tricks.

On 2018-08-16, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On 15 Aug 2018 14:14:19 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>>  But at least I finally got to play
>> Dungeon right to the end.
>
> 	OK now honestly which was more fun playing Dungeon or arranging
> that you could ?

Well...

"You are in a maze of little twisty function calls, all different."

-- 
/~\  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