[Info-vax] OT: obscure PDP11 OSes (even more dinosaury)

[Bill Gunshannon]

In article <mm99ta$mue$1 at iltempo.update.uu.se>,
	Johnny Billquist <bqt at softjar.se> writes:
> On 2015-06-22 16:46, Bill Gunshannon wrote:
>> In article <mm954o$766$1 at iltempo.update.uu.se>,
>> 	Johnny Billquist <bqt at softjar.se> writes:
>>> On 2015-06-15 15:47, Bill Gunshannon wrote:
>>>> In article <2f70d$557ed38b$5ed4324a$44068 at news.ziggo.nl>,
>>>> 	Dirk Munk <munk at home.nl> writes:
>>>>> Because one VAX could do the work of several PDP-11's?
>>>>
>>>> Maybe in later times, but the first VAX I worked on was a real dog
>>>> and I worked on several PDP-11's that outperformed it.  And, just
>>>> like the debates here over what Alpha might have become, IMHO the
>>>> PDP-11 could easily have kept up with the VAX.  All that would
>>>> have been needed, really, was a bigger address bus and being as
>>>> they had expanded it in the past, I don't think that was undoable.
>>>> As time went on they could have made a 32bit PDP-11 that maintained
>>>> 16bit compatability at the hardware level.  Intel did it twice,
>>>> 8088 to 80386 and 80386 to x86-64.  Things like Floating Point and
>>>> CIS could have been incorporated into the base architecture without
>>>> breaking anything.
>>>
>>> DEC sortof did that. It was called the VAX. The early VAXen did have the
>>> ability to run PDP-11 code in userspace.
>>
>> Yes, but with no new features.   To get new features you had to totally
>> rewrite your MACRO-11 program in MACRO-32.  Iw as merely saying that
>> rather than totally changing the architecture I see no reason why they
>> could not have continued the architecture with enhancements at each
>> step, just like other architectures did.
> 
> The new features were, by definition, not PDP-11 compatible, but to say 
> that the VAX didn't have any new features is a bit of an odd view. :-)

As usual, I think I am not being clear here.  Of course the VAX had new
features.  It WAS a new feature.  :-)  But, it was not a PDP-11 by any
stretch of the imagination.

> 
>>> And no, you would not have been able to extend the PDP-11 to 32 bits
>>> without making it incompatible with a PDP-11, except as a special mode,
>>> which is exactly what the VAX did.
>>
>> Not sure I agree with this.  I expect that if it was desired they
>> could have done incremental modifications while maintaining backwards
>> compatability.  But then, this is all academic, isn't it.
> 
> Try it, if you don't believe me. Suggest how you would extend the PDP-11 
> without breaking the backward compatibility.

Well, if I figure out how to use my Altera Board and how to program in
VHDL, I just might give it a try.  I think there already is a basic
PDP-11 available for it.  I could always try extending it.  

> 
>>> Adding a larger physical address space would have had very little value.
>>> Extending the virtual address space was crucial, and it could not be
>>> done without being incompatible. And if you go that way, you might as
>>> well make some general improvements anyway, which is exactly what DEC
>>> did with the VAX.
>>
>> The original x86 architecture had 64K segments.  It later added a mode
>> with a large flat address space while maintaining compatabiltiy with
>> "Small Model" programs.  It could be done.
> 
> They "maintained" backward compatibility in that you can grab an old 
> program and still run it on the new hardware. No different than what the 
> VAX did. You cannot take a new program and run it on the old hardware.

Umm...  Unless I greatly mis-remember my early VAX the reason they
could run was much closer to todays VAX emulation than the VAX actually
being a superset PDP-11.  I am fairly certain I can not run any kind
of PDP-11 code on any of my curretn VAXen as that was hardware speci-
fically put into the early VAX and removed after a very short time.
Current x86 machines (even x86-64) can still run code written for the
8088.

> 
>>>> Sorry, as much as I like the VAX, I think the PDP-11 was better.
>>>
>>> I prefer the PDP-11 too, but let's not try to deny the obvious.
>>>
>>>> Using the same argument we have heard here, what do yo think the
>>>> capabilites of a PDP-11 with no new features but made using current
>>>> technology for shrinks and clocking would be?  One screaming CPU.  :-)
>>>> How many RSTS/E users do you think could be supported on a 2.5Ghz
>>>> PDP-11/93 with 16GB of memory.  :-)
>>>
>>> You could easily, from a CPU performance point of view, support 64 users
>>> on an 11/9x today. At that point, it becomes a question of memory again.
>>> And it's not the physical memory that you start running out of first.
>>> It's virtual memory. Even the kernel have limitations based on this. In
>>> RSX, one crucial part is system pool. It all sits in the kernel virtual
>>> memory space, and thus cannot grow much larger than it currently is, no
>>> matter what you do. You need a larger virtual address space. Anything
>>> else essentially just means you are trying to do magic with your knees,
>>> and you spend more and more time running code to just try and move
>>> around the address space limitations.
>>
>> Or, a big flat address space.  :-)
> 
> Which would be incompatible with the PDP-11. 

While it would definitely be different I don't see how it is a compatability
issue at all.  I would expect a program written to run in a 64K PDP-11 to
have no problem running in a machine that has more memory.  Now, the other
way.......

>                                              Which is exactly what the 
> VAX did. You are merely suggesting exactly what DEC did with the VAX, 
> you just don't seem to realize that this is what you are saying. :-)

But the VAX is a totally different architecture.  Other than both being
(technically) CISC and made by DEC, just what do they have in common?

> 
>>>> And X-11, too.  :-)
>>>
>>> That would *not* happen without a larger virtual address space.
>>>
>>
>> Exactly.  :-)
>>
>> As I have stated in the past, one project I would love to do, just
>> for the fun of it, was port RSTS to other architectures, both large
>> and small.  I can envision RSTS/86 with X-11 and large dataspace so
>> things like Postgres and otehr cool toold cold be ported.  Does it
>> have some commercial value?  Even i seriously doubt it, but as one
>> who really liked RSTS back in  the day, it wold be a lot of fun
>> doing it.  And who know who else might have fun working on and
>> enhancing it.  Even Minix is still being worked on.
> 
> If you were to extend the address space of the PDP-11, it would not be 
> compatible, and thus you would have to rewrite RSTS/E as well, in order 
> to use the new hardware. 

Well, obviuosly, it RSTS or any other OS would have to be modified to
make use of any of the new features.  But a complete re-write?  Was
VMS completely re-written when it went from VAX to ALPHA and then to
Itanium?  Now, given the opportunity, I would likely re-write RSTS, yes.
But mostly to make it more portable and thus written in a higher level
language than MACRO-11.  But then, that has always been one of my stated
objectives given the source and the opportunity.

>                          And then, when you're at it, you might want to 
> change and enhance a number of things you have in RSTS/E, as you now 
> could, since some of the designs in RSTS/E were dictated by the hardware.
> And then you'd end up with something that in some ways looks like 
> RSTS/E, but in some ways are different. And then you'd have people 
> asking why you didn't just make a larger PDP-11 and run "pure" RSTS/E 
> instead of the monster you created. :-)

Well, as also stated previously, this is all academic.  I doubt there
would be anyone really interested, but who knows. I know people still
playing with Primos and just this morning in another group I got an
announcement about a DPS8 emulator running Multics that was being made
avaialble.

I guess there is just no way to explain the things we want to do for fun.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>